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 / meta / properties / doiAdded value: +{
+ "description": "Zenodo concept DOI: the latest archived release",
+ "type": "string"
+}Output schema / properties / meta / properties / copyrightAdded value: +{
+ "description": "Rights holder",
+ "type": "string"
+}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 cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds a genuinely useful behavioral fact: results are truncated to the first 20 of each category, with the full report available at /v1/health. That truncation notice is the kind of operational detail an agent needs and cannot get from the annotations.
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?
A single dense sentence listing the four metric categories, followed by a short usage clause and the truncation caveat. It is front-loaded and wastes no words, though the metric list is slightly comma-heavy and could be easier to scan.
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 zero parameters, an output schema present, and annotations declaring read-only local behavior, the description does what is needed: it names the metrics and warns that results are sampled. The only missing piece is guidance on how to act on the counts once retrieved.
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 and the baseline score applies. The description correctly implies a no-argument call by describing the output rather than any input.
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, each as counts plus a first-20 sample. That is specific enough to distinguish it from siblings like check_question or resolution_sources, though it never states the verb explicitly ('returns a health report').
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 clear motivating context for calling it, which is more than nothing. However, it offers no exclusions or comparisons to adjacent tools such as check_question, so the agent must infer when this is preferable to querying an answer directly.
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.