Return jurisdictions, sources, record counts, freshness, pricing, and known limits. Free; no API key required.
This tool declares no required parameters. Add optional parameters from the input schema as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {},
"name": "get_coverage"
}
}| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full burden, and it does disclose the two things an agent most needs for a no-parameter call: it is free and requires no API key, so there is no auth setup or billing risk. "Return" implies a read-only, side-effect-free operation, and the mention of "known limits" flags that constraints are surfaced rather than hidden, though it does not state whether the tool itself is rate-limited.
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 short sentences, front-loaded with what is returned and followed by the operational caveat. Nothing is padded and no sentence is redundant.
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?
A no-parameter, read-only tool with an output schema is inherently simple, and the description covers cost, auth, and scope adequately. The one real gap is guidance on when to invoke it relative to the sibling, which matters because coverage checks are typically a prerequisite step.
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 the baseline is 4 and there is no parameter meaning the description could add. The enumerated return fields do not map to any input and so neither help nor hurt this dimension.
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?
"Return jurisdictions, sources, record counts, freshness, pricing, and known limits" names a specific verb and enumerates the resource's contents, so an agent can tell this is a metadata/coverage-discovery call. It stops short of stating the tool's intent (e.g., "use before querying to learn what data is available") and never contrasts with the sibling check_contractor, so it is clear but not fully differentiated.
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 explicit when-to-use or when-not-to-use guidance, and no reference to the alternative tool. "Free; no API key required" lowers the cost of calling it but does not tell an agent under what circumstances it should prefer this over check_contractor or a direct query.
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.