Phorme Training

Put a workout on a 1:1 client's day

coach_client_workout

Use this when a Phorme coach has written a workout for one of their 1:1 clients and wants it on the client's plan. It writes it as a real session on that day, marked from the coach, with loads filled from the client's maxes where the coach gave none; the client can undo it in the app. replace true rewrites the workout the coach already put on that day. Send the workout exactly as the coach wrote it. Set confirmation to true only after the coach said yes to this workout for this client.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "brain_id": "<brain_id>",
      "client_id": "<client_id>",
      "title": "<title>",
      "exercises": "<exercises>",
      "confirmation": "<confirmation>"
    },
    "name": "coach_client_workout"
  }
}

Input Schema

Name	Required	Description
`date`	No	The day, YYYY-MM-DD. Today when left out.
`title`	Yes	A short name, for example "Lower A".
`replace`	No	True to rewrite the workout the coach already put on that day.
`brain_id`	Yes	The brain id of the coach's own build, for example "cameron".
`client_id`	Yes	The client_id of one of the coach's 1:1 clients, from coach_clients.
`exercises`	Yes
`confirmation`	Yes	True only after the coach said yes to this workout for this client.

Output Schema

Name	Required	Description	Default
`date`	No
`next`	No
`title`	No
`result`	No
`written`	Yes
`brain_id`	No
`client_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 1, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations it discloses the material behaviors: it creates a real session dated to the day, is attributed to the coach, auto-fills loads from the client's maxes where none were given, and is undoable by the client in the app. It also defines replace semantics and gates the write behind an explicit coach confirmation.

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?

Five short sentences, front-loaded with the when-to-use condition, and each carries a distinct rule. The replace sentence largely duplicates the schema's own wording, which is the only wasted line.

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?

For a mutation tool with 7 parameters and an output schema, the description covers the trigger, side effects, reversibility, overwrite behavior and the confirmation precondition. Nothing an agent needs to decide or invoke correctly is missing.

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

Parameters3/5

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

Schema description coverage is 86%, so the schema already explains date, replace, client_id and most exercise fields. The description restates replace almost verbatim and adds only indirect hints (loads filled from maxes, send the workout exactly as written) rather than new per-parameter meaning.

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?

States a specific verb and resource (write a workout as a real session onto a 1:1 client's day) and scopes it to the coach's own 1:1 clients, which separates it from save_workout_to_phorme and save_program_to_my_coaching_brain. The title reinforces the same scope.

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

Usage Guidelines4/5

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

"Use this when a Phorme coach has written a workout for one of their 1:1 clients and wants it on the client's plan" gives a clear trigger condition. It does not name an alternative tool or state when not to use it, so it stops short of explicit routing.

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

All Phorme Training 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.