fitfly-engine
Server Details
Deterministic fitness coaching engine: adaptive programs, progression math, readiness autoregulation
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.8/5 across 10 of 10 tools scored. Lowest: 3.2/5.
Each tool has a clearly distinct purpose: changelog explains coaching decisions, get_program provides the full program, get_todays_session shows the immediate workout, list_swap_options and swap_exercise handle exercise substitution, log_workout records lifts, meal_plan and nutrition_targets cover nutrition, readiness_checkin handles daily readiness, and regenerate_program rebuilds the program. There is no ambiguity or overlap.
Most tools follow a verb_noun pattern (get_program, list_swap_options, log_workout, regenerate_program, swap_exercise). Two tools (changelog, meal_plan, nutrition_targets) are noun-only, which is a minor inconsistency but does not cause confusion. Overall, the naming is clear and predictable.
With 10 tools covering program viewing, daily sessions, exercise swapping, workout logging, nutrition, readiness, and program regeneration, the count is well-scoped for a fitness coaching engine. Each tool serves a clear need without redundancy.
The tool set covers core workflows: program management, workout execution, exercise swapping, nutrition, and readiness. However, there is no tool to update athlete profile data (e.g., body stats, goals), which is needed for regeneration based on profile changes. This is a notable gap that could cause agent failures.
Available Tools
10 toolschangelogWhat the engine changed and whyBInspect
The 'what changed & why' feed — the engine's coaching decisions (volume bumps, deloads, swaps) in Coach Fly's voice. Use to explain to the athlete why their plan evolved.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but fails to disclose any behavioral traits (e.g., read-only nature, auth needs, rate limits). Only describes output content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise: two sentences, no redundant words. Could be more structured but front-loads the key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and basic usage, but lacks parameter details and behavioral transparency. No output schema means return format is unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'limit' has no description in the input schema or the tool description. Description adds zero value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves the 'what changed & why feed' of coaching decisions (volume bumps, deloads, swaps) in Coach Fly's voice. Distinct from sibling tools like get_program or swap_exercise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the use case: 'Use to explain to the athlete why their plan evolved.' While it doesn't list alternatives, the sibling tool context implies when to use this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_programGet the active programAInspect
The athlete's current multi-day program (render-ready).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description bears full responsibility for disclosing behavioral traits. It only notes the resource is "render-ready" but fails to state that the operation is read-only, idempotent, or what happens if no active program exists. This lack of detail limits the agent's understanding of the tool's side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 8-word sentence that conveys the purpose and a key attribute (render-ready) with no unnecessary words. It is both concise and front-loaded, earning its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description adequately covers the resource and its state. However, it could be improved by noting that it is a read operation or clarifying the meaning of 'render-ready.' The lack of output schema is not a deficiency here given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the input schema is empty and schema coverage is trivially 100%. The description does not need to add parameter semantics, and the baseline of 4 is appropriate as there is no confusion about parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves "the athlete's current multi-day program" and indicates it is "render-ready," which specifies both the resource and its state. This distinguishes it from siblings like get_todays_session (which focuses on a single session) and regenerate_program (a mutation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool should be used to obtain the full program, as opposed to get_todays_session which likely returns only the current session. However, it does not explicitly state when to use this tool over alternatives nor provides any exclusion criteria, leaving it to the agent to infer usage based on tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_todays_sessionGet today's training sessionAInspect
Today's workout: exercises, sets/reps, per-exercise load guidance and concrete target weights, plus nutrition targets and cycle status. Auto-applies the user's readiness check-in (autoregulation) if they've done one today. Call this to see what the athlete should do now.
| Name | Required | Description | Default |
|---|---|---|---|
| dayIndex | No | Which program day (1-based). Defaults to the first day. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: it 'auto-applies the user's readiness check-in (autoregulation) if they've done one today,' which is a side effect. With no annotations, this is valuable transparency. However, it does not explicitly state whether the auto-application is reversible or if it modifies data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding distinct value: content summary, auto-application behavior, and usage directive. No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides a good list of returned items (exercises, sets/reps, load guidance, target weights, nutrition, cycle status). It could mention whether optional elements like warm-up or rest times are included, but it is adequate for understanding the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for dayIndex. The tool description does not add further meaning about the parameter (e.g., how it relates to 'today's' session), but the schema already clarifies it's a program day index defaulting to first day.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'exercises, sets/reps, per-exercise load guidance and concrete target weights, plus nutrition targets and cycle status.' It also mentions auto-applying readiness check-in. This distinguishes it from siblings like get_program (returns program structure) or meal_plan (separate nutrition tool).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Call this to see what the athlete should do now,' providing clear usage context. However, it does not explicitly state when not to use it or mention alternatives, though it's implied that other tools like log_workout are for after the session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_swap_optionsList same-area swap options for an exerciseAInspect
Valid alternatives for an exercise — same muscle group, filtered to the athlete's equipment/level/injuries. Use before swap_exercise.
| Name | Required | Description | Default |
|---|---|---|---|
| exerciseId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It mentions filtering criteria (equipment/level/injuries) and suggests a read-only listing, but does not explicitly confirm read-only nature, performance implications, or response format. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, front-loaded with core purpose. Every word contributes meaning. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers what it does, filtering, and usage order. It lacks details on return values but overall sufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It implies 'exerciseId' is for the exercise in question, but does not elaborate on format or expected values. Baseline 3 is appropriate as it adds some meaning beyond the empty schema property description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists valid alternatives (swap options) for an exercise, filtered by muscle group, equipment, level, and injuries. It uses specific verb 'list' and resource 'swap options', distinguishing it from sibling 'swap_exercise'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use before swap_exercise', guiding the agent on when to invoke this tool versus the sibling. However, it does not mention contextual do-not-use scenarios or alternative tools beyond swap_exercise.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
log_workoutLog completed setsAInspect
Record what the athlete actually lifted. The engine runs progression (double-progression, e1RM), detects PRs, and returns per-exercise outcomes (established/progressed/held/deloaded) with next-time targets. Weights are in kg.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | ||
| dayIndex | No | ||
| exercises | Yes | Per-exercise completed sets (weights in kg). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the engine runs progression (double-progression, e1RM), detects PRs, and returns per-exercise outcomes. This provides useful behavioral context beyond the basic write operation, though it lacks details on potential side effects or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a purpose: purpose, engine behavior, unit clarification. No fluff or redundant content. Front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (nested array parameters, progression logic) and lack of output schema, the description covers the return values (outcomes, next-time targets). Missing details about edge cases or error handling, but adequate for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description should compensate. It adds meaning for the exercises parameter by stating 'weights in kg' and linking to engine outcomes, but it does not explain the goal or dayIndex parameters beyond what the schema provides. Basic value added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Record what the athlete actually lifted.' It specifies the verb (record), resource (what was lifted), and additional context about progression and PR detection. This distinguishes it from sibling tools like get_todays_session or get_program.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used after a workout to log actual performance, but it does not explicitly state when to use it versus alternatives like changelog or meal_plan. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meal_planGenerate a meal planBInspect
A day of meals hitting the athlete's targets, USDA truth-checked (flags feasible=false with a note when macros are approximate). Slow (~15s AI call).
| Name | Required | Description | Default |
|---|---|---|---|
| exclusions | No | ||
| mealsPerDay | No | ||
| trainingDay | No | ||
| dietaryStyle | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses generative nature, target alignment, USDA checks, feasibility flag behavior, and latency. Lacks details on side effects or auth needs, but adequate for a generative tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and key details. Could be more structured but no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, 4 undocumented parameters. Description explains high-level behavior but misses parameter semantics and return format details, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 4 parameters with 0% description coverage. Description does not explain any parameter meaning, e.g., exclusions, mealsPerDay, trainingDay, dietaryStyle. Agent has no guidance on how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Title and description clearly state the tool generates a meal plan for athletes. It specifies 'day of meals' and 'USDA truth-checked', distinguishing it from sibling tools like nutrition_targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions slowness (~15s) implying it's a heavy call, but does not explicitly guide when to use or not use this tool. No mention of alternatives from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nutrition_targetsGet nutrition targetsAInspect
The athlete's daily calorie + macro targets, computed from body stats, activity, and goal.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions that targets are 'computed from body stats, activity, and goal' but does not disclose whether the tool is read-only, requires authentication, or has other behavioral traits beyond the computation hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that immediately conveys the core purpose and computation method. Every word earns its place, with no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is mostly complete. It explains what is returned and how it is derived. However, it lacks context about which athlete's data is used or any prerequisites like user authorization.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100%. With no parameters, the baseline is 4, and the description does not need to add parameter meaning. It adds no extra parameter info, but none is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns daily calorie and macro targets computed from body stats, activity, and goal. It uses a specific verb 'get' and resource 'nutrition targets', distinguishing it from siblings like meal_plan or get_program.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving nutrition targets but provides no explicit guidance on when to use this tool versus alternatives like meal_plan or get_todays_session. No exclusions or context cues are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
readiness_checkinLog a readiness check-inAInspect
Record how the athlete feels today (energy, sleep, soreness — each 1–5). The engine scores readiness and, on the next get_todays_session, reshapes the workout accordingly (reduce volume / reduce intensity / recovery day). Returns the readiness score + modifier.
| Name | Required | Description | Default |
|---|---|---|---|
| sleep | Yes | 1 terrible … 5 great | |
| energy | Yes | 1 drained … 5 great | |
| soreness | Yes | 1 none … 5 very sore |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool returns a readiness score and modifier, and that it modifies the next workout. The side effect of reshaping the workout is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first covers action and input, second covers effect and output. No unnecessary words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All three required parameters described with values, no output schema but return value is mentioned. The tool's integration with get_todays_session is explained, making it self-contained for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds context by grouping the three parameters together and mentioning their role in readiness scoring, but does not add significant detail beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool records today's readiness metrics (energy, sleep, soreness) on a 1-5 scale, explains the downstream effect on the next workout session, and distinguishes itself from sibling tools like log_workout and get_todays_session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use this tool (to record daily readiness) and connects it to get_todays_session, but does not give explicit when-not-to-use or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
regenerate_programRegenerate the programAInspect
Rebuild the whole program from the stored profile (~20s AI generation). Use after a profile change or a plateau.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Mentions '~20s AI generation' and implies destructive mutation (rebuilds program). Missing details on reversibility or impacts, but adequate for a simple tool with no parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action, no wasted words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a tool with no parameters and no output schema: says what it does, when to use, and timing. Could mention output or error handling, but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero parameters (100% coverage), so baseline 4 applies. Description adds no parameter info, which is appropriate since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it rebuilds the whole program from the stored profile with a specific verb ('Rebuild') and resource ('program'). Distinguishes from siblings like 'get_program' (read) and 'swap_exercise' (single change).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use after a profile change or a plateau,' providing clear context. Does not explicitly mention when not to use, but siblings imply alternatives for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
swap_exerciseSwap an exerciseBInspect
Replace an exercise with a valid same-area alternative. scope 'today' = just this session; scope 'program' = going forward. The new lift starts fresh (day-one calibration).
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Default 'program'. | |
| dayIndex | No | ||
| exerciseId | Yes | ||
| toExerciseId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the new lift starts fresh (day-one calibration), which is useful behavioral information. However, it does not disclose whether the swap is destructive, affects history, or requires specific permissions. The description only partially reveals behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with no wasted words. The first sentence states the core action, and the second adds scope clarification and a behavioral note. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, 2 required, no output schema, and no annotations. The description covers the core swap action and scope but omits details about dayIndex, the meaning of exerciseId and toExerciseId, and what happens to existing data. For a tool with low schema coverage and no annotations, the description is incomplete for a fully informed agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (25%), so the description should compensate. It adds meaning for the scope parameter by explaining 'today' vs 'program'. It also explains the 'fresh start' behavior related to the swap. However, it does not describe exerciseId, toExerciseId, or dayIndex parameters, leaving them largely unexplained. The description provides some added value but not enough to fully compensate for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool replaces an exercise with a same-area alternative and explains the scope parameter. However, it does not explicitly distinguish this tool from the sibling tool 'list_swap_options', which likely lists alternatives. The purpose is clear but lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool (same-area alternative) and explains scope values. However, it does not specify when to use this tool versus other alternatives (e.g., list_swap_options) or when not to use it. Usage guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!