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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds important behavioral context: the tool does not call tools on the checked server by default, determinism is reported as 'not measured' rather than guessed, and allow_tool_call has specific consent implications. It also clarifies the scope (conformance/disclosure only) and that correctness of returned figures is out of scope, which goes beyond what annotations provide.

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 compact and information-dense: four sentences each carry distinct content—what is measured, what is not measured, default behavior, and the explicit warning about allow_tool_call. No filler or redundancy, and critical safety information is placed at the end as a natural call-to-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 tool's moderate complexity (2 params, one boolean), the description is nearly complete: it explains the five conditions, the safety model, and the default behavior. The presence of an output schema means return-value details are already covered elsewhere, so the description doesn't need to explain them. Minor gap: it does not explicitly state what happens if the endpoint is not reachable or how the verdict is returned, but these are acceptable given the output schema exists.

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 100%: both endpoint and allow_tool_call have descriptions in the schema. The tool description adds semantic value by explaining the default behavior of allow_tool_call (default false) and the safety condition ('only set this for a server you own'), which complements rather than merely repeats the schema. It does not add format details for endpoint beyond the schema's 'https URL', so a 4 is appropriate.

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 states a specific verb ('Measure') and resource ('a public MCP endpoint') and enumerates five concrete conditions, which clearly differentiates it from sibling tools like lookup_server or verify_verdict. The title is also specific about checking conformance and disclosure, so an agent can immediately know what this tool accomplishes.

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 explains what the tool does not do ('says nothing about whether any figure the checked server returns is correct'), provides a clear safety rule ('Set allow_tool_call true only for a server you control'), and notes that by default no tool is called. This gives the agent clear when-to-use and when-not-to-use guidance, though it does not name sibling alternatives directly.

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