AIm Workout Journal

Get coaching context

get_coaching_context

Read-only

Coaching instructions + this user's fresh training context for the task. Call at the start of any coaching conversation and treat the returned prompt as your instructions. If intake is incomplete it returns the intake flow instead (intake_required=true).

task defaults to 'next_workout' so a call with no arguments answers instead of failing, which was the single most common tool error. 'check_in' is accepted as a spelling of 'checkin': it is the only value in this list that is not snake_case, so models write the underscored form on their own. constraints is for TODAY-ONLY circumstances ("only 30 minutes", "gym closed, training at home") — they shape this generation without touching the profile; durable facts go through update_coach_profile instead. today is the current date in the USER's timezone, YYYY-MM-DD — the same rule you already follow for a session's date, and for the same reason: everything here is anchored on which day it is for THEM, and the server's clock is UTC. Send it whenever you know it. Omitted, the server falls back to the timezone stored from the web app, which a user who has only ever used this connector has never set — and then the muscle numbers here disagree with the ones in their app.

Input Schema

TableJSON Schema

Name	Required	Default
`task`	No	next_workout
`today`	No
`constraints`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 7, 2026

addedInput schema / properties / today

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

First observedSep 6, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses key behavioral details beyond the readOnlyHint annotation: it returns a prompt to be treated as instructions, may return an intake flow if intake is incomplete, and has specific fallback behavior for the today parameter. It also explains the timezone fallback and potential mismatch with user-facing numbers.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with clear paragraphs and inline code, and it avoids major redundancy. It is slightly verbose with meta-commentary about common model errors and internal fallback behavior, but these asides still provide practical guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's purpose, usage triggers, parameter semantics, output expectations, edge cases, and alternative tools. It is sufficiently complete for an agent to call the tool correctly without needing additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema has no per-parameter descriptions, the narrative fully explains all three parameters: task includes its enum, default, and the check_in typo; constraints is clearly scoped to today-only; today is explained with timezone semantics and fallback behavior. This gives complete semantic coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to retrieve coaching instructions and fresh training context for a given task, and it instructs to call it at the start of any coaching conversation. The resource is specific and distinct from sibling tools like get_program or get_session.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says when to use the tool ('Call at the start of any coaching conversation'), explains defaults and error behavior for omitted arguments, and points to update_coach_profile as the alternative for durable facts. It also clarifies the intended scope of constraints as today-only.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All AIm Workout Journal tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.