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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds valuable context beyond annotations: it discloses the paid nature ($0.25 USDC via x402), that it applies to unauthenticated calls on the hosted /mcp endpoint, and that settlement occurs only on a successful non-error result. This enriches the agent's understanding of cost and failure behavior.

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 concise and well-structured: two sentences, the first stating the core purpose, the second providing payment and settlement details. No redundant information, every sentence serves a 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?

Given the tool has one simple parameter, no output schema, and rich annotations, the description is minimally complete. It explains the input constraint and payment behavior but does not describe what the compliance check returns (e.g., boolean, list of violations), which is significant given the absence of an output schema. The annotations cover safety, but return-value semantics are left implicit.

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 schema covers file_path with a basic 'Path to mesh file', and the description adds meaning by specifying 'using canonical pipeline outputs', clarifying that the input must be a canonical pipeline output rather than an arbitrary mesh. This goes beyond the schema's generic description, enhancing 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?

The description clearly states the tool's function: 'Run Roblox R15 compliance checks against a mesh'. It is specific and distinct from sibling tools like axis_validate or axis_inspect by focusing on R15 compliance. The phrase 'using canonical pipeline outputs' further clarifies the resource context.

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 verifying R15 compliance when canonical pipeline outputs are available, but it does not explicitly state when to use this tool versus alternatives or exclude other tools. It lacks clear when-to-use or when-not-to-use guidance, though the constraint of 'canonical pipeline outputs' provides some contextual direction.

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