Skip to main content
Glama

Save workout to Phorme

save_workout_to_phorme
Idempotent

Use this when the user has seen a workout preview and clearly said to save it. It saves that preview to the connected Phorme account as a private workout and returns a link that opens it in Phorme. It needs a connected Phorme account with the training:write permission. Retrying with the same idempotency_key returns the same saved workout and does not create a second copy.

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": {
      "preview_id": "<preview_id>",
      "confirmation": "<confirmation>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "save_workout_to_phorme"
  }
}

Input Schema

NameRequiredDescriptionDefault
preview_idYesThe preview_id of the preview being saved.
confirmationYesSet to true only after the user clearly confirmed this save in the conversation.
idempotency_keyYesA unique string for this save. Reuse the same value when retrying so no second copy is created.

Output Schema

NameRequiredDescriptionDefault
statusYes
open_urlYesLink that opens the saved training in Phorme.
training_idYes
training_kindYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / preview_id / description
      Previous value: -"The preview_id returned by preview_workout_import."New value: +"The preview_id of the preview being saved."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description adds substantive context: the saved workout is private, a link is returned, a connected Phorme account with training:write permission is required, and idempotent retries return the same workout rather than duplicating it. This is exactly the extra disclosure the annotations cannot carry.

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

Conciseness5/5

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

Four tight sentences with the usage trigger front-loaded, then behavior, then prerequisites, then retry semantics. No filler or restatement of the title.

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?

Covers trigger, effect, permission prerequisite, idempotency, and outcome; an output schema exists so return values need not be enumerated. Nothing needed to invoke this write tool correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: it explains the retry semantics of idempotency_key ('reuse the same value so no second copy is created') and frames confirmation as gated on explicit user consent. It stops short of 5 since the parameters themselves are already well documented in the schema.

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+resource ('saves that preview to the connected Phorme account as a private workout') and scopes it to a previously seen preview, which cleanly separates it from preview_workout_import and save_program_to_phorme. An agent can identify the correct tool without opening the schema.

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?

Gives an explicit trigger ('when the user has seen a workout preview and clearly said to save it'), establishing both the precondition and the confirmation requirement. It does not name alternative siblings (e.g. preview_workout_import, save_program_to_phorme) as explicit alternatives, so it stops short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.