NCHS leading causes of death by state (bi63-dtpu). Returns total deaths and age-adjusted death rates per cause per state per year. Useful for chronic disease + injury mortality research.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Year | |
| limit | No | Max rows (default 50) | |
| state | No | Full state name or 'United States' | |
| cause_name | No | Cause name (e.g. 'Heart disease', 'Cancer', 'Suicide') |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds useful output-shape context but does not disclose potential operational behaviors such as default scope when filters are omitted, available year range, or valid cause-name list. No contradiction with 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?
Two sentences are front-loaded with the dataset source and return values, and the closing use-case sentence adds context without clutter. The dataset ID in parentheses is a minor but useful identifier, not wasted 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?
For a simple optional-filter retrieval tool with no output schema, the description provides the key missing output semantics: rows contain deaths and age-adjusted rates by cause, state, and year. It could add valid cause-name/date-range details, but the 100%-covered schema and read-only annotations make the tool safely invokable with reasonable defaults.
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 already describes all four parameters at 100% coverage, so the baseline is 3. The description adds value by explaining that results are organized 'per cause per state per year,' clarifying how the optional filters combine into output rows. This goes slightly beyond the one-line schema descriptions.
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 names a specific resource — the NCHS leading-causes-of-death dataset (bi63-dtpu) — and states the exact returned metrics: total deaths and age-adjusted death rates by cause, state, and year. This makes it easy to distinguish from CDC siblings such as cdc_drug_overdose_deaths or cdc_weekly_deaths_by_state.
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 offers an implied use case ('useful for chronic disease + injury mortality research') but no explicit when-to-use/when-not-to-use guidance or alternative tool suggestions. Among many CDC siblings, the agent is not told why this tool should be selected over cdc_dataset_query or the other CDC dataset tools.
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.