get_context
THE WHOLE PICTURE IN ONE CALL — start a conversation with this. Returns the athlete's date and weekday (so you do not also need get_today), then everything the Blocks app itself puts in front of its own assistant on every turn: the plan from yesterday to +7 days with a done / NOT-done verdict ALREADY COMPUTED per planned session, today's readiness with its baselines and confounders, thresholds and the resolved zone tops (watts, pace and bpm, so you never compute one), recent activities with the athlete's own notes, 14 days of planned-vs-done, 12 weeks of weekly load, upcoming events, what their own twelve weeks say about how they respond, the facts they have recorded, what either assistant changed in their plan lately and why (recent_plan_changes), and their last few exchanges with the in-app Blocks assistant — continue from those instead of starting over. Pass question — the athlete's own words, in any language — and the knowledge base is ALSO searched for you before you answer, so the evidence is in your hands without you having to guess the right query; it does not answer the question, it only decides what to retrieve, and without question nothing is searched. WHEN TO CALL: as the first tool call of a conversation, and again only after a long gap or when the athlete says something has changed since (a ride synced, a check-in logged, a threshold set). A second call in the same conversation almost always returns what you are already holding — use get_plan, list_activities, get_readiness_today, list_facts or search_knowledge for the one thing it did not cover. Read-only: it writes nothing.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| question | No | what the athlete just asked, in their own words, in any language — used ONLY to search the knowledge base for you. Omit it and no search runs. |