Every Simma Connector Tool, and What to Ask For

The Simma connector puts your coaching data inside your AI assistant. Once it's connected, you don't call tools by name and you don't write queries — you ask for what you want in your own words, and the assistant picks the tools it needs.

This guide assumes the connector is already installed and signed in — if it isn't, start with the setup page for your assistant: Claude or Antigravity. It's about the part that comes after: what's actually available, what to ask for, and where the assistant will stop and check with you.

It's written for coaches. An athlete who connects gets a different, smaller set of tools about their own training — the same ideas, without the squad.

The shape of it

Twenty-four tools. Thirteen read your data; eleven write to it.

The connector signs in as you. Every request carries your own login, so it reaches exactly what you'd see in the Simma web app — your athletes, your messages, your profile — and nothing else. Asking about an athlete you don't coach returns an authorisation error, not data.

The other thing worth knowing up front: Simma's numbers are already computed against each athlete's own history. Training status, form scores, load trends, session shapes — these are Simma's model, not something the assistant works out from raw sessions. A good assistant will read them and interpret them, not recalculate them. If you ever see it doing long arithmetic on lap times, redirect it: "use Simma's training status rather than working it out yourself."

Where to start: your squad

list_athletes is the entry point for almost everything. It returns your athletes with current training status, last activity, active goals and unread message count — and it's how the assistant gets the athlete IDs every other tool needs. The status labels are worth knowing:

• overreaching — load has outrun recovery
• monitor — something's drifting, worth a look
• disengaged — they've stopped
• quiet — past their own usual gap between sessions with nothing this week; due, not yet gone
• welcome-back — returning after a break
• recovering — coming down off a load block

get_coach_inbox answers "who's waiting on me?" across the whole roster in one call — every conversation with at least one message, most recent first, with the last message and unread count.

get_coach_profile reads your own record: name, business name, public slug, invite code, and the voice settings Simma writes with (tone of voice, coaching instructions, sign-off).

Try asking:

"Who in my squad needs attention this week?"

"Who's gone quiet?"

"Anyone waiting on a reply from me?"

Understanding one athlete

get_athlete_context is the richest single view and the right starting point before writing anything. Three weeks of activity bucketed by week with per-sport volume, training load with 7-day deltas and trend, per-sport training status, goals with days-to-event, the linked training plan, and pre-computed notable flags.

Those flags matter. Each one carries a severity, the sentence a coach would say, the values behind it — and sometimes a context line that changes the reading entirely. A load spike that's a return from a break reads very differently from a load spike that's overreaching, and Simma says which it is. If your assistant characterises a flag without that nuance, ask it to check the context line.

get_training_status is the per-sport view: form score and zone, trend, detected pattern, days since last activity, session count and flags.

get_athlete_stats is the longer window — fitness, fatigue and form history over weeks (default twelve), plus active goals. Use it for trends, not individual sessions.

get_athlete_profile is who the athlete is rather than how they're going: name, contact, preferred units, pool length, self-rated ability by sport, and the threshold values Simma's load model scores against. It also returns any linked training plan and a twelve-week activity summary.

Try asking:

"Give me the full picture on Sarah before I write to her."

"How's Marcus tracking on the bike compared to three weeks ago?"

"What's changed for Priya in the last fortnight?"

Digging into sessions

list_athlete_activities lists sessions newest first, trimmed to summary fields. It takes a date window — weeks, months or days — and an optional sport filter. Ask for a window rather than a page count; "the last six weeks" works better than "the last fifty sessions."

get_activity_detail is the full breakdown of one session, including every lap and the split structure. GPS traces, heart-rate and pace graphs and stroke analytics come back summarised rather than inlined, so a single session can't swallow the whole conversation.

One unit note: detail comes back metric. If you work in miles, say so — "I use imperial" — and the assistant will convert. It can also read your preferred units from your profile, but saying it is faster.

find_sessions_by_shape is the one coaches don't expect and then use constantly. It returns every session in a window with its pacing shape, plus a roll-up across the window. It answers questions like "which swims faded in the main set this month" or "is she negative-splitting more often than she was."

The shapes:

• negative_split — back half faster by more than 2%
• even — within −2% to +3%
• faded — 3% to 8% slower
• faded_hard — more than 8% slower

Two things make this more honest than a naive split. First, it reports the main set separately from the whole session — a structured swim with a warm-up and cool-down often reads "faded" across the whole thing while the main set was even or negative. The main set is what you actually mean when you ask whether someone faded. Second, it recognises sets with two regimes — sprints then steady, or fast/easy alternating — and judges the shape on the steady block rather than calling a deliberate structure a fade.

Sessions with too few laps to judge are listed with no shape so you can see they happened. Don't read anything into those.

Try asking:

"Show me every swim this month where the main set faded."

"Is Tom's pacing getting more even, or is that wishful thinking?"

"Walk me through Thursday's long ride."

Goals

list_athlete_goals returns event name, discipline, date, days until the event, target time and notes.

create_goal adds one: an event with a date and one target per discipline. One target makes it a single-discipline goal; more than one makes it multi-discipline, which is how a triathlon goal is expressed.

update_goal edits an existing goal — rename it, move the date, change targets, add notes, or mark it completed or archived. Note that passing targets replaces the whole list, so the assistant should carry forward the ones you're keeping.

delete_goal removes a goal permanently. Prefer marking it completed or archived when the event happened or was abandoned — that keeps the history Simma's context builder reads. Delete is for mistakes.

Try asking:

"Add a goal for Sarah — Noosa Triathlon on 1 November, targeting sub-2:30."

"Marcus's marathon moved to March. Update it."

"Mark Priya's 10k as completed."

Messages and drafting

This is where the connector earns its keep, and where it's most careful.

get_messages reads the recent coach/athlete thread, newest first. Worth reading before drafting anything new — it's what's already been said.

save_draft stores a message you've written together as a draft. Nothing is sent. The draft appears in Simma where you can read, edit and send it in the normal way, and it's what send_draft takes. A good assistant reads your coach profile first, so the draft sounds like you rather than like a chatbot, and grounds the content in get_athlete_context rather than its own reading of raw numbers.

send_draft sends a saved draft as a real email, immediately. It cannot be undone or recalled, and it arrives under your name.

discard_draft deletes an unsent draft. Drafts only — a sent message can't be deleted, and shouldn't be: removing it wouldn't unsend the email, but it would break the routing that delivers the athlete's reply back into the thread.

check_send_safety reports which safety gates are actually working in your particular client. More on that below.

Try asking:

"Draft this week's summary for Sarah — she's had a big block and I want to flag the fatigue without spooking her."

"Read the thread with Marcus and draft a reply."

"Bin that draft, I'll write it myself."

The send gates

Sending is the only irreversible thing here, so it has two independent gates.

The strong one is a direct confirmation prompt addressed to you, not to the model. Mid-call, before anything goes out, your client shows you the full subject and body and asks you to approve. The text you see is read back from the Simma server — not from what the model typed — so you're reading exactly what will be delivered, and the recipient's name comes from the server too. The model can't answer that prompt on your behalf. Declining leaves the draft untouched.

The fallback, for clients that can't show that prompt, is that the exact subject and body have to be passed back and matched against the stored draft. A stale reference can't send a different message than the one you approved.

Not every client supports the strong gate. The connector can't know until your client connects, and a client can claim it can prompt you and then fail to. That's why check_send_safety exists — and why it takes a probe option that raises a harmless test prompt to prove the thing actually renders. Ask for that after any client update rather than assuming:

"Check whether the send confirmation actually works in this client — run the probe."

If the gate is broken, the connector refuses to send rather than delivering an email nobody read.

Also worth saying plainly: sending goes back through Simma rather than out through your assistant's own mail. That's deliberate. Simma mints the reply address that routes the athlete's response back into the thread, sets the threading headers so it lands in the right email conversation, and keeps the message as the history the next draft reads. A message sent from anywhere else fragments all three.

Settings and thresholds

update_athlete_profile sets an athlete's thresholds, ability levels, units, pool length, name or body mass. Speak in normal units — pace as 4:30, speed in km/h — and Simma converts.

Thresholds deserve a warning. They're what every training-load number is scored against, so changing one reshapes that athlete's whole history. The assistant is instructed to read the current value, tell you the old and new number, and confirm before writing. If it changes one without showing you both numbers, that's worth pushing back on.

Cycling is the fiddly case. Threshold power comes from a power meter — 95% of best 20-minute power is the usual estimate. Threshold speed is the fallback for riders without one, and it's the entire basis of their load, so set it deliberately rather than leaving a placeholder. Body mass only affects the climbing term of the speed-based estimate. And ftpLocked stops Simma's own auto-estimation from overwriting a threshold you set on purpose.

update_athlete_notes sets your private notes on an athlete, or the specialty you work with them on. Notes are your own memory — injuries, life context, what they respond to — and they're included in the coaching context, so what goes here shapes future drafts. Notes replace the whole text, so the assistant should read the existing ones and carry forward what should stay. "Add to Sarah's notes" is a better instruction than "set Sarah's notes."

update_coach_profile edits your own business name, public slug and voice settings. The voice settings shape every draft Simma writes for you from then on, so this is a considered change rather than a casual one. The sign-off is rendered verbatim at the end of each email.

Try asking:

"Sarah's swim threshold should be 1:38 per hundred, not 1:45. Show me what that changes before you set it."

"Add to Marcus's notes that he's travelling for work through October."

"My drafts are too formal. Adjust my tone of voice to something warmer."

Training plans

link_training_plan attaches a Google Doc or Sheet as an athlete's training plan. Simma reads it — read-only — when building coaching context, which is what makes plan-versus-actual comparison possible in a draft.

The document has to be shared with Simma's service account first. If it isn't, the tool returns the address to share it with; your assistant should hand you that address rather than retrying.

unlink_training_plan detaches it. Simma stops reading the plan; the document itself is untouched.

Try asking:

"Link this as Priya's plan: [paste the Google Doc URL]"

"How did Marcus's actual week compare to what was planned?"

Getting good answers

A few habits that make a real difference:

Name the athlete in plain English. You never need an ID. "Sarah" is enough — the assistant looks it up.

One athlete at a time for anything that writes. Reading across the squad is fine and fast. Drafting is better done per athlete, and sends should never be batched from a single approval.

Ask for the reasoning, not just the answer. "Why do you say she's overreaching?" pulls the underlying flags and values into view, and it's how you catch an assistant that's confidently wrong.

Give it what Simma doesn't have. The whole point of having this in your assistant rather than in a dashboard is that you can combine it with everything else — your calendar, a race schedule, a conversation you had poolside on Tuesday. "Sarah's load looks high but she told me she's got exams in two weeks — how should I pitch this week?" is a question no dashboard can answer.

Push back when it re-derives. If it starts averaging lap times to work out whether someone's tired, stop it. Simma already did that work against the athlete's own history, and the assistant's version won't be better.

What it can't do

The connector is scoped to coaching. It has no access to billing, no access to other coaches' athletes, and no way to change your password or account security. It can't create or remove athletes, or accept invitations on your behalf. It can't delete a sent message. And it has no separate privileged access of its own — everything it does, it does as you.

For what happens to the data itself, see the privacy policy.