get_mcp_status

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

With readOnlyHint/idempotentHint already covering safety, the description adds meaningful return semantics: what stale_copy means, that supported is null when the cache cannot tell, and that the app links carry fixed campaign attribution. It stops short of describing what a disconnected bridge looks like in the response, which is the key thing the 'call this first' advice is meant to detect.

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 lead 'Health check:' is well front-loaded, but the rest is one long run-on sentence with nested parentheticals that packs freshness, recompute and URL attribution into a single breath. Every clause adds information, yet the structure makes it harder to scan than a short bulleted list would.

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?

There is no output schema, so the description must carry return-value meaning, and it does so for the freshness and recompute blocks plus the app links. What is missing is the failure/disconnected state, the one behavior an agent calling this as a pre-flight check most needs to interpret.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline for a no-arg tool applies. The description correctly asks for no inputs.

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?

States a specific verb and resource ('Health check') and enumerates exactly what the result contains: data source, metric/workout counts, context files, latest data date, freshness block, recompute summary and app links. It does not, however, distinguish itself from the sibling get_freshness, which appears to cover overlapping freshness information.

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?

'Call this first to confirm the bridge is connected' gives an explicit trigger and ordering, which is strong guidance for the agent. It never says when to prefer the sibling get_freshness instead, so the overlap with that tool is left unresolved.

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