dataset_healthCoverage, stale records, races still lacking a results page, and publisher-gate warnings, as counts with the first 20 of each (full report at /v1/health). Use to judge how far to trust an answer.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| meta | Yes | What this answer was built from; cite dataset_version | |
| result | Yes |
Changes observed during successful MCP inspections.
Output schema / properties / result / properties / full_reportAdded value: +{
+ "description": "URL of the full report with every warning",
+ "type": "string"
+}Output schema / properties / result / properties / races_without / descriptionPrevious value: -"Races lacking one"New value: +"First 20 races lacking one"Output schema / properties / result / properties / races_without_totalAdded value: +{
+ "description": "All races lacking one",
+ "type": "integer"
+}Output schema / properties / result / properties / stale / descriptionPrevious value: -"Stale records"New value: +"First 20 stale records"Output schema / properties / result / properties / stale_totalAdded value: +{
+ "description": "All stale records",
+ "type": "integer"
+}Output schema / properties / result / properties / warnings / descriptionPrevious value: -"Publisher-gate warnings"New value: +"First 20 publisher-gate warnings"Output schema / properties / result / properties / warnings_by_levelAdded value: +{
+ "description": "Warning count per level",
+ "type": "object"
+}Output schema / properties / result / properties / warnings_totalAdded value: +{
+ "description": "All publisher-gate warnings",
+ "type": "integer"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: results are counts truncated to the first 20 of each category, with the full report available at /v1/health, which tells the agent the output is deliberately partial.
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?
Two sentences, front-loaded with the payload contents and followed immediately by the use case. The category enumeration is long but each item describes distinct returned data, so it earns its space.
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?
With an output schema present, return values need not be explained in prose, and the description still adds the truncation rule and the /v1/health escape hatch. For a no-input diagnostic tool this covers everything an agent needs to call it correctly.
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 no parameters and schema coverage is 100%, so there is nothing for the description to disambiguate. The baseline for a zero-parameter tool applies.
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 enumerates exactly what the tool reports – coverage, stale records, races lacking results pages, and publisher-gate warnings – so the resource and content are unmistakable. It does not explicitly contrast itself with siblings like when_final or check_question, but the diagnostic-report framing is distinct enough in practice.
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?
"Use to judge how far to trust an answer" gives a concrete triggering context for the tool, which is unusually clear guidance. It stops short of naming alternatives or stating when not to call it, so it falls below the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.