setup

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

Beyond the annotations (readOnlyHint, idempotentHint), the description discloses that the tool only returns content and cannot perform external actions like creating Projects. This explains the tool's non-mutating behavior and its limitation, which is valuable context not fully captured by annotations alone.

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 well-structured with a concise opening sentence, a bulleted list of return items, and a short paragraph on limitations. Each sentence serves a purpose—no fluff or redundancy—and the most important information is 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?

Given zero parameters, a detailed output schema, and annotations covering safety, the description fully explains what the tool does, what it returns, and its limitations. It leaves no ambiguity about the tool's role in the overall setup workflow, making it contextually complete.

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 zero parameters, so schema coverage is trivially 100%. Per the rubric, a baseline of 4 applies for 0-param tools. The description does not need to explain paramet semantics, but it does clarify the returned object structure, which adds useful context.

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 opens with 'One-call onboarding for the Trackman golf coach,' which clearly states a specific verb (onboarding) and resource (coach setup). It enumerates concrete outputs (system_prompt, skills, instructions) and thus distinguishes itself from sibling tools like auth or session_analysis by its setup-focused role.

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?

It explains that the tool returns setup content and explicitly states an MCP server cannot create Projects or enable Skills itself, which clarifies when to use this tool (to get setup material) versus doing manual setup separately. It also notes the alternative of using Claude Code to directly write files, providing contextual usage guidance without explicit exclusions.

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