Skip to main content
Glama

Phorme Training

by me.phor
OverviewDiscussionsAdmin

Find a Phorme coaching brain

find_coaching_brain
Read-only

Use this when the user wants a way to train for a goal or sport, for example "I want to get more explosive for basketball", "build muscle three days a week" or "train for a half marathon", or wants to train with a named coach, for example "train with Cameron Goodson", and has not picked a programme, or has a coach code someone gave them, for example K7Q2-XR4D. Phorme coaching brains are curated training methods: a coach, the principles the method trains by, and a coach-built programme. It returns up to three brains that fit, best first, each with its coach, focus, how it trains and its programmes with weeks and days a week; with a coach named, only that coach's brains; with a code, the one brain it belongs to and its page. It reads only and changes nothing. Do not use it for injury rehab or nutrition.

Input Schema

NameRequiredDescriptionDefault
codeNoA Phorme coach code exactly as the user gave it, for example "K7Q2-XR4D", or a phor.me/c/ link. Only when they gave one.
goalNoWhat the user wants from training, in their words, for example "jump higher" or "first HYROX race". Needed unless a code is given.
coachNoA coach the user named, for example "Cameron Goodson". Only that coach's brains are returned.
sportNoThe sport or position, only if the user named one.
days_per_weekNoTraining days a week, only if the user said.

Output Schema

NameRequiredDescriptionDefault
codeNoThe coach code that was looked up, when one was given.
goalYes
brainsYesBest fit first: id, name, coach, coach_title, focus, how_it_trains, image_url and image_alt (Phorme's own picture of the brain, its programme cover or its coach's room: show it, never a web photo), programmes (name, summary, weeks, days_per_week, image_url) and why it fits.
limitsYesWhat this does not cover. Tell the user.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / code
      Added value: +{
+  "description": "A Phorme coach code exactly as the user gave it, for example \"K7Q2-XR4D\", or a phor.me/c/ link. Only when they gave one.",
+  "maxLength": 80,
+  "type": "string"
+}
    • changedInput schema / properties / goal / description
      Previous value: -"What the user wants from training, in their words, for example \"jump higher\" or \"first HYROX race\"."New value: +"What the user wants from training, in their words, for example \"jump higher\" or \"first HYROX race\". Needed unless a code is given."
    • removedInput schema / required
      Removed value: -[
-  "goal"
-]
    • addedOutput schema / properties / code
      Added value: +{
+  "description": "The coach code that was looked up, when one was given.",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / coach
      Added value: +{
+  "description": "A coach the user named, for example \"Cameron Goodson\". Only that coach's brains are returned.",
+  "maxLength": 80,
+  "type": "string"
+}
  3. Changed1 schema field changed
    • changedOutput schema / properties / brains / description
      Previous value: -"Best fit first: id, name, coach, coach_title, focus, how_it_trains, image_url and image_alt (the coach's room in Phorme: show it as the brain's picture, never a web photo), programmes (name, summary, weeks, days_per_week, image_url) and why it fits."New value: +"Best fit first: id, name, coach, coach_title, focus, how_it_trains, image_url and image_alt (Phorme's own picture of the brain, its programme cover or its coach's room: show it, never a web photo), programmes (name, summary, weeks, days_per_week, image_url) and why it fits."
  4. Changed1 schema field changed
    • changedOutput schema / properties / brains / description
      Previous value: -"Best fit first: id, name, coach, coach_title, focus, how_it_trains, image_url and image_alt (Phorme's own picture of the brain), programmes (name, summary, weeks, days_per_week, image_url) and why it fits."New value: +"Best fit first: id, name, coach, coach_title, focus, how_it_trains, image_url and image_alt (the coach's room in Phorme: show it as the brain's picture, never a web photo), programmes (name, summary, weeks, days_per_week, image_url) and why it fits."
  5. Changed1 schema field changed
    • changedOutput schema / properties / brains / description
      Previous value: -"Best fit first: id, name, coach, coach_title, focus, how_it_trains, programmes (name, summary, weeks, days_per_week) and why it fits."New value: +"Best fit first: id, name, coach, coach_title, focus, how_it_trains, image_url and image_alt (Phorme's own picture of the brain), programmes (name, summary, weeks, days_per_week, image_url) and why it fits."
  6. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces with 'reads only and changes nothing'. Beyond that it discloses return cardinality and ordering ('up to three brains that fit, best first'), the fields returned, and that a code narrows to exactly one brain plus its page. It doesn't cover the zero-result case, which would fully close the loop.

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?

Front-loaded with the triggering condition and examples before the definition, then behavior, then exclusions. Dense but every sentence carries routing or behavioral information; the definition sentence is slightly long but earns its place by disambiguating 'brain'.

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

Completeness4/5

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

With five optional parameters, rich annotations and an output schema, the description covers usage modes, return shape and scope exclusions, so an agent can call it correctly. The only gap is behavior on no-match results, a minor omission given the output schema exists.

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 the schema alone earns a baseline 3. The description adds genuine conditional semantics the schema cannot express: goal is 'needed unless a code is given', coach filters to that coach only, and sport/days_per_week should only be supplied if the user said so, which constrains opportunistic parameter filling.

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 (find) and resource (Phorme coaching brain), then defines the resource concretely as 'a coach, the principles the method trains by, and a coach-built programme'. Concrete example utterances and the sibling-ish alternatives (named coach, coach code) make it distinguishable from search_phorme_programs and find_personal_coach.

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?

Gives explicit when-to-use triggers with user-voice examples, plus three mode variants (goal, named coach, code). It also states when NOT to use it: 'Do not use it for injury rehab or nutrition', and implies the pre-condition that the user hasn't picked a programme yet.

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

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

Resources