Skip to main content
Glama

executive-performance

Assess Performance Profile

fitness.assess_performance_profile
Read-only

Use this when a user wants a structured read on their training, nutrition, and recovery, or asks where they should focus first. Returns three pillar scores (Bulletproof Body, Fuel with Freedom, Recharge and Restore), the single biggest lever, and up to three prioritised actions. Do NOT use for medical diagnosis, injury treatment, or nutrition therapy. Do not use when the user is asking only about general fitness information, exercise form, or a single exercise's technique — answer those directly instead. This is coaching assessment, not clinical assessment.

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": {
      "trainingYears": "<trainingYears>",
      "sessionsPerWeek": "<sessionsPerWeek>",
      "movementControl": "<movementControl>",
      "painFree": "<painFree>",
      "nutritionConsistency": "<nutritionConsistency>",
      "proteinAdequacy": "<proteinAdequacy>",
      "mealTimingConsistency": "<mealTimingConsistency>",
      "sleepHours": "<sleepHours>",
      "stressLevel": "<stressLevel>",
      "recoveryPractices": "<recoveryPractices>",
      "goal": "<goal>"
    },
    "name": "fitness.assess_performance_profile"
  }
}

Input Schema

NameRequiredDescriptionDefault
goalYesThe primary outcome the user wants to prioritise right now.
painFreeYes0-10. How often are you free of aches or pains that limit your training?
sleepHoursYesTypical hours of sleep per night (4-10).
stressLevelYes1-10. Current chronic stress level, where 10 is maximum.
trainingYearsYesHow many years have you trained seriously and consistently?
movementControlYes0-10. How much of a full, controlled range of motion can you own?
proteinAdequacyYes0-10. Do you get enough protein without excessive effort?
sessionsPerWeekYesHow many training sessions per week do you currently complete?
recoveryPracticesYes0-10. How consistent are your deliberate recovery practices?
nutritionConsistencyYes0-10. How reliably do you hit your nutrition targets?
mealTimingConsistencyYes0-10. How consistent is your eating schedule?

Output Schema

NameRequiredDescriptionDefault
overallYes
pillarsYes
disclaimerYes
primaryLeverYes
recommendationsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds meaningful context beyond them: the coaching-vs-clinical scope boundary and the shape of the deliverable. It doesn't say the 11 inputs must be gathered from the user before calling, which is the main operational gap.

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 trigger, then the return shape, then the exclusions — good ordering. The closing sentence "This is coaching assessment, not clinical assessment" largely restates the earlier do-not clause and is the one line that doesn't fully earn its place.

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?

An output schema exists, so return values needn't be spelled out, yet the description still summarises them usefully. For a read-only 11-parameter assessment tool, the trigger, exclusions, and scope boundary cover everything an agent needs to decide whether to call it.

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 100%, with ranges, enums, and plain-language prompts for every one of the 11 fields, so the schema carries the parameter burden. The description adds no field-level meaning beyond naming the three pillar domains, so the baseline 3 applies.

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 ("structured read on their training, nutrition, and recovery") and even enumerates what comes back: three pillar scores, the single biggest lever, and up to three prioritised actions. That output preview distinguishes it from the sibling plan-builder tools without requiring the agent to open 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 Guidelines5/5

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

Gives an explicit trigger ("when a user wants a structured read... or asks where they should focus first") plus two explicit exclusions: no medical diagnosis/injury treatment/nutrition therapy, and no use for general fitness info, exercise form, or a single exercise's technique. It even tells the agent what to do instead ("answer those directly"), which is the strongest form of routing guidance.

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.