Skip to main content
Glama
Sign In

MONS Athletics

by com.monsathletics
OverviewDiscussionsAdmin

Check readiness for a challenge

check_readiness
Read-onlyIdempotent

Picks the challenge to aim for from the person's training, whether they are ready for it, and what is still needed if not. Returns the next question while one is unanswered, then the challenge and verdict. Send every answer so far each time.

Input Schema

NameRequiredDescriptionDefault
sportYesThe sport of the challenge: running, cycling or swimming.
todayNoThe person's local date as YYYY-MM-DD, the day before if it is earlier than 05:00 where they are. Omit if unknown.
answersNoAnswers so far, keyed by question id, each a distance in kilometres: the one the person gave, or the value of the option they chose. Omit before the first answer.
furthest_kmYesThe furthest distance the person has ever done in one go in that sport, in kilometres. 0 if never.
challenge_idNoOptional: a challenge id from the challenges find_next_challenge lists, when the person names a goal of their own. Omit to let their training answers pick one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / answers / description
      Previous value: -"Answers so far, keyed by question id, each the value of the option the person chose. Omit before the first answer."New value: +"Answers so far, keyed by question id, each a distance in kilometres: the one the person gave, or the value of the option they chose. Omit before the first answer."
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already establish that this is a safe, read-only, idempotent operation. The description adds meaningful behavioral detail beyond that: it returns the next unanswered question first, then the challenge and verdict, and requires cumulative answers.

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?

The description is tightly structured: purpose first, return behavior second, and the key invocation instruction last. Every sentence adds useful information without waste.

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?

For a tool with no output schema and a nested answers object, the description adequately explains the response progression and the answer-accumulation requirement. It could say more about the shape of the next question or possible verdict values, but the core behavior is covered.

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%, so parameter meanings are already well documented. The description only reinforces the answers parameter by saying to send every answer so far each time, without adding syntax or format details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific purpose: pick a challenge from training, assess readiness, and say what is still needed. It distinguishes this from simply listing challenges, but it does not explicitly name or contrast with the sibling find_next_challenge.

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

Usage Guidelines3/5

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

It gives useful invocation guidance for the iterative flow, especially 'Send every answer so far each time,' but it does not explain when to use this tool instead of alternatives such as find_next_challenge or add_challenge.

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

All MONS Athletics 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