Lists NASA EONET v3 category IDs and titles so you can pass a valid category ID to event searches. Use it to resolve category names before querying natural events.
List NASA EONET v3 category ids and titles. Pass a category id to eonet_events. No API key.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered structurally. The description adds one genuinely useful behavioral fact — 'No API key' — but says nothing about response shape, size of the category list, or caching. With annotations doing most of the work, this is a modest addition.
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?
Three short sentences, each earning its place: what it returns, where the output goes, and the auth constraint. Front-loaded with the action and resource.
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?
For a zero-parameter, no-output-schema lookup tool, the description covers what comes back (ids and titles), how to use the result, and the auth requirement. Nothing an agent needs in order to call it correctly is missing.
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?
Zero parameters, so the baseline is 4; the description correctly implies no input is needed and instead directs the returned values onward to eonet_events. There is no parameter ambiguity to resolve.
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?
States a specific verb and resource ('List NASA EONET v3 category ids and titles'), making it immediately distinguishable from the event-oriented siblings like eonet_events and fires_near. An agent knows this is the taxonomy/lookup endpoint without opening anything else.
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?
'Pass a category id to eonet_events' explicitly names the downstream consumer and the workflow, which is strong routing guidance. It stops short of stating when not to call this (e.g., if the agent already knows the category id), so it lacks an explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.