deathcare_market
Current-year expected deaths for a county or state — market size for death-care operators and investors. Free preview masks county names.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| fips | No | ||
| limit | No | ||
| state | No |
Current-year expected deaths for a county or state — market size for death-care operators and investors. Free preview masks county names.
| Name | Required | Description | Default |
|---|---|---|---|
| fips | No | ||
| limit | No | ||
| state | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It does add one genuinely useful behavioral trait — free-tier output masks county names — but says nothing about authentication/tier requirements needed to unmask, rate limits, or pagination, leaving most operational behavior unexplained.
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 tight sentences with the purpose front-loaded and the caveat trailing; nothing is redundant. It is slightly terse to the point of omitting necessary parameter detail, but the prose itself is efficient.
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?
No output schema, no annotations, and zero parameter documentation mean the description must compensate for a lot, and it doesn't. An agent cannot learn the FIPS/state format, units of the death count, or what limit does without guessing.
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 0% for all three parameters. The phrase 'for a county or state' loosely maps to fips and state, but no format, identifier scheme, or default is given, and 'limit' is entirely unexplained in both schema and description.
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 concrete resource and scope — current-year expected deaths for a county or state — plus the audience (death-care operators and investors), so an agent knows exactly what data it gets back. It doesn't explicitly contrast itself with deathcare_projection or deathcare_growth_ranking, though 'current-year' implicitly separates it from the projection tool.
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?
There is no when-to-use guidance and no mention of alternatives among the many siblings (deathcare_projection, deathcare_growth_ranking, deathcare_bulk_extract). The only usage-flavored remark is that the free preview masks county names, which is a limitation rather than selection guidance.
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.