FREE. Which crypto assets, venues, operators and modes the settlement oracle supports, plus pricing. Full paid feeds for humans: https://permitverdict.com/pricing
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds the 'FREE' distinction and clarifies that full paid feeds are for humans, which is useful behavioral context about cost and audience. No contradiction with 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?
The description is a single, well-structured sentence that front-loads the key 'FREE' tag, followed by the core purpose and a link for more info. Every word earns its place, with no redundancy.
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 parameterless list tool with no output schema, the description adequately conveys the full scope of information returned (assets, venues, operators, modes, pricing). Annotations cover safety traits, making the description complete for the agent to decide invocation.
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 has zero parameters, and the schema coverage is effectively 100% (an empty schema). With no parameters to explain, the description is not expected to add parameter details, so the baseline 4 applies.
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 uses a specific verb 'list' and clearly identifies the resource: 'which crypto assets, venues, operators and modes the settlement oracle supports, plus pricing.' This distinguishes it from siblings like list_jurisdictions, which would cover legal jurisdictions, not settlement asset coverage.
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 provides clear context: it is a free tool for querying settlement oracle coverage and pricing. It also points to the paid human-facing feeds via a link, offering an alternative for more comprehensive data. However, it does not explicitly name sibling tools as alternatives, so it stops short of a 5.
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.
Most tools are clearly distinct (e.g., get_crypto_spot vs. resolve_price_event), but attest_price_event and resolve_price_event both provide settlement verdicts, differing mainly in the signed record. The descriptions give enough guidance to choose correctly, so this is a minor overlap rather than a serious confusion.
All 10 tool names follow a consistent verb_noun pattern with snake_case (attest_price_event, check_permit_activity, decode_decision_id, etc.). The verbs vary but are appropriate for each action, and there are no mixed conventions or stylistic deviations.
10 tools is well-scoped for a server covering two distinct domains: building permit intelligence and crypto price settlement. Each domain has a focused set of tools (e.g., permits: list, check, get, find; settlement: get spot, resolve, attest, verify, decode), and no tool feels superfluous.
The tool set provides full coverage for its stated purpose. For building permits, it offers jurisdiction discovery, activity summary, detailed verdicts, and project searches. For crypto settlements, it covers spot prices, settlement resolution, attestation, verification, and decision decoding, with no obvious dead-ends or missing lifecycle operations.