permitverdict-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.4
Disambiguation5/5
Each tool has a clearly distinct purpose: wallet_status, crypto settlement support/health, price verification/attestation, decision verification, and permit intelligence are all separated. Even similar tools like resolve_price_event vs attest_price_event are clearly differentiated by the signed artifact and intended use.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (list_, check_, get_, resolve_, decode_, verify_, attest_), but `wallet_status` deviates as a noun phrase, preventing a perfect score. The verbs are otherwise clear and uniform.
Tool Count5/5
With 11 tools, the set is well-scoped for covering two coherent domains (crypto settlement and permit intelligence) without bloat or redundancy. Each tool earns its place and the count is within the ideal range.
Completeness5/5
The crypto settlement workflow is fully covered: discover assets, check venue health, get spot prices, resolve events, attest with signed artifacts, decode decision IDs, and verify current validity. Permit intelligence includes jurisdiction listing, activity screening, and full verdicts, with wallet status ensuring payment readiness.
Average 4.3/5 across 11 of 11 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 commits in the last 12 weeks
- Last stable release on August 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing its safety profile. The description adds 'FREE.' which hints at cost, but no additional behavioral traits like rate limits or authentication requirements are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two fragments. 'FREE.' and 'Cities covered...' each add distinct information, though the sentence fragment structure could be smoother. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, and comprehensive annotations), the description sufficiently sets expectations. It clearly states the resource and extra details, though it could clarify what 'pricing and payment details' specifically refers to.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter documentation burden. The description adds context about the output content (cities with pricing/payment details), which compensates adequately for the absent schema parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (cities covered by the permit intelligence API) and notes additional content (pricing and payment details). The tool name and title clarify the action (list), making the purpose clear, though the description itself lacks an explicit verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings or any exclusions. The description only states what the tool returns, not the context for using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation contradiction: annotations declare readOnlyHint=true and idempotentHint=true, but the description states 'PAID — $0.05 USDC' and 'Pays automatically from the configured wallet.' This indicates a financial side effect that modifies wallet balance, contradicting the read-only and idempotent hints. Despite otherwise useful behavioral detail, the contradiction forces a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet front-loaded with the most critical facts: cost, purpose, return values, and mode selection. Every sentence contributes value—cost, outcome, mode warning, disagreement behavior, and payment. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description covers return values, evidence, confidence, venue disagreement behavior, and payment. It lacks explicit details about wallet configuration or edge cases, but for a tool with six parameters, it is largely complete and actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds important semantic context, especially for the 'mode' parameter: 'touch counts any intrabar print including wicks' and warns that 'the difference is the single most common cause of a disputed settlement.' This goes beyond the schema's dry enum descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Settlement verdict for a crypto price event: did the asset trade or close above/below a threshold during a window?' It specifies the resource (price event), the action (resolve/settle), and the return outcomes (YES/NO/DISPUTED/UNRESOLVED). This distinguishes it from siblings that attest or verify decisions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on mode choice: 'Choose mode carefully — close counts only candle closes, touch counts any intrabar print including wicks. They routinely give different answers.' It also explains why venues disagree leads to DISPUTED. It does not explicitly name alternative tools, but it provides clear context for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and non-destructive, so the description adds valuable context: cost (FREE), real-time venue status, and source count. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero wasted words. First sentence states the core function, second provides usage motivation. Information is front-loaded and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description covers purpose, usage timing, and value. It could mention output format, but the domain context and annotations make it sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single optional asset parameter, which already describes its default. The description does not add extra meaning about parameters, matching the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks which price venues are answering and how many independent sources back a verdict. This specific verb+resource combination distinguishes it from siblings like get_crypto_spot or resolve_price_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to call this before spending, explaining that verdicts corroborated by multiple venues are more valuable. It lacks exclusions or alternatives, but the usage context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the $0.01 cost and automatic payment from the configured wallet, which are behavioral traits not present in the annotations. It also explains the interpretation of spread (venues disagree, settlement contestable), adding significant context beyond the readOnly/openWorld hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with cost, then function, then a caveat. Each sentence earns its place with no redundant phrasing, making it efficiently concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool with rich annotations, the description covers the essential aspects: cost, payment behavior, and price interpretation. It does not specify the quote currency or return structure, but given the simple schema and annotation coverage, it is sufficiently complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the sole 'asset' parameter with examples (BTC, ETH, SOL), achieving 100% coverage. The description adds no additional parameter details, but none are necessary given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Live cross-venue spot price' with a specific verb and resource, distinguishing it from sibling tools like resolve_price_event or attest_price_event. It explicitly mentions venue agreement and spread, which uniquely identifies its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a cross-venue spot price with venue agreement is needed and warns about wide spreads being contestable. However, it does not explicitly contrast with alternatives or state when not to use it, leaving the usage guidance merely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the read-only, non-destructive nature. The description adds the behavioral trait that the result is a yes/no screen (not a full report) and that it covers 'recent' activity, which helps set expectations. It does not detail output formatting or error handling, but for a simple read operation with strong annotations, this adds sufficient context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and front-loaded with 'FREE.' which is extraneous and not pertinent to tool invocation. The remaining text is efficient and directly useful, consisting of a purpose statement and an alternative reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter read-only tool with no output schema, the description conveys the screening nature and directs to get_permit_verdict for more depth. This is sufficient for an agent to decide when to call it, though it leaves the exact response format underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already includes descriptions for both parameters (address and jurisdiction) with 100% coverage. The description references 'given address' but adds no additional semantics beyond the schema, so it doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks whether an address has recent permit activity and to what extent, using a yes/no screening format. It explicitly distinguishes this from get_permit_verdict, which provides full history and a decision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use this tool vs the alternative: use get_permit_verdict when full history and a decision are needed. This is an explicit when-to-use and when-not-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description doesn't need to restate safety. It adds valuable context beyond annotations: the $0.02 cost, automatic payment from the configured wallet, and the meaning of CHANGED as stale evidence. This exceeds minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence carries unique information: purpose, when to call, why it's needed, outcome semantics, cost comparison, and payment behavior. No filler or redundancy despite being a longer paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool, the description fully covers the use case, outcome values (CONFIRMED, CHANGED, INDETERMINATE), cost, and why freshness matters. Even without an output schema, the possible results are explicitly enumerated, making the tool self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for decision_id, describing it as issued by attest_price_event. The description only mentions that it comes from someone handing you a decision_id, which aligns with the schema without adding new syntax or format details. Baseline 3 applies since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('verify') and resource ('attested settlement'), and clearly states the action: re-resolve against price venues and report CONFIRMED, CHANGED, or INDETERMINATE. It distinguishes itself from sibling tools like resolve_price_event by focusing on checking an existing decision rather than buying a fresh one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this whenever someone hands you a decision_id you are about to rely on. It also names the alternative (resolving fresh) and explains why this is cheaper, providing both when-to-use and when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true, idempotentHint true, and destructiveHint false, so safety is covered. The description adds valuable context about the tool being free ("FREE.") and what it returns (wallet status and address), which goes beyond what annotations state. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentence fragments that immediately convey cost, purpose, and usage context. Every word adds value: "FREE.", the status/address purpose, and the "call first" guidance. It is front-loaded and wastes no space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only status tool with no parameters and no output schema, the description is fully complete. It covers cost, purpose, return value, and a concrete use case. Sibling tools are clearly different, and annotations cover safety, so no additional context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter schema to enrich. The description mentions the address as part of the output, but no input parameters are needed. Baseline for 0 params is 4, and the description does not add anything needed here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool reports whether a payment wallet is configured and its address, giving a specific purpose. "Whether a payment wallet is configured for this MCP server, and its address" distinguishes it from sibling tools like list_settlement_assets or get_crypto_spot, which focus on other financial aspects. The verb is implicit but unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage trigger: "Call this first if a paid tool reports it cannot pay." This provides clear when-to-use guidance and positions the tool as a diagnostic first step. It does not list exclusions or alternatives, but for a simple status check, this is sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds critical non-annotation behavior: it discloses the $2.00 USDC cost and states that payment happens automatically from the configured wallet. It also notes the tool provides nothing if no permit activity exists. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences of dense, high-value information: cost, what it does, the pre-check workflow, and automatic payment. No filler or redundancy, and it is front-loaded with the PAID warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately summarizes what the tool returns (normalized history, activity signals, verdict with cited records). It covers cost, preconditions, and workflow. The only minor gap is the lack of an explicit structure for the 'verdict' output, but that does not prevent correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, with clear examples (e.g., '760 14th St' and 'san_francisco') and a reference to list_jurisdictions. The description adds little beyond schema, such as reinforcing 'covered city,' but the schema already does the heavy lifting, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'address-level building-permit intelligence' with 'normalized permit history, activity signals, and a decision-ready verdict with cited public records.' It differentiates from the sibling free tool check_permit_activity by being paid and adding a verdict, and the title reinforces the $2.00 cost.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs the user to 'Run the free check_permit_activity first — if there is no activity, this call has nothing to add.' This provides a clear when-to-use and when-not-to-use condition, and the use of 'covered city' and jurisdiction slug gives contextual prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, non-destructive), the description discloses a critical behavioral trait: it is PAID ($0.25 USDC) and 'pays automatically from the configured wallet.' It also instructs the user to keep the decision_id and explains the self-contained nature of the artifact. This is valuable contextual information not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet information-dense. Each sentence contributes: cost, output contents, use case, decision_id handling, self-containment, and payment behavior. It is front-loaded with the most important fact (PAID) and follows a logical structure, with no fluff or repeated information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no output schema, the description compensates by listing exactly what is returned (resolve_price_event's output plus decision_id, hash, candles). It also covers cost, the verification pathway, and the requirement to retain the decision_id. This is complete enough for an agent to correctly decide when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all six parameters, so the schema already carries the semantic load. The description does not add extra meaning to parameters like asset, operator, or threshold, nor does it explain the meaning of 'mode' or time window formats. Baseline 3 is appropriate because the description is not misleading but also adds no parameter-specific value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it produces an attested, citable settlement record by returning everything resolve_price_event returns plus a signed decision_id, integrity hash, and outcome-determining candles. It explicitly positions itself as the 'citable artifact' for defending to counterparties, distinguishing it from the plain resolve_price_event and other sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'use it when the answer may later have to be defended to a counterparty, not when you just need to know.' It also explains the verification alternatives (decode_decision_id free, verify_decision for $0.02), providing actionable context for choosing this tool versus cheaper alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, etc.), the description adds valuable behavioral context: it is FREE, it returns pricing information for paid endpoints, and it serves as a prerequisite confirmation step. These details are not present in the annotations and help the agent anticipate cost and usage behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with 'FREE,' and every word contributes. It packs the tool's purpose, output scope, and usage relationship into a compact, well-structured format without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description fully explains what the tool returns (assets, venues, operators, modes, and prices) and gives usage context. It is sufficiently complete for an agent to select and invoke this tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema offers no semantic burden. The description doesn't need to explain parameters, and it doesn't, but it also doesn't add any parameter-related meaning. The baseline for zero-parameter tools is 4, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: listing the crypto assets, venues, operators, and modes supported by the settlement oracle, plus prices for paid endpoints. It also explicitly distinguishes its role from the sibling tool resolve_price_event, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance by saying 'Call this before resolve_price_event to confirm an asset is covered,' which tells the agent when to use this tool in relation to a specific alternative. However, it does not provide exclusions for when not to use it (e.g., if you already know coverage), so it falls just short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, non-destructive, idempotent), the description reveals how signatures work, that forgery/editing is detectable, and that authentication does not imply current correctness. This adds significant behavioral context and does not contradict 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place: cost, purpose, mechanism, and caveat/alternative. It is front-loaded with 'FREE' and structured logically, making it highly scannable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, rich annotations, and clear scope, the description is complete. It covers what it does, how it works, when to use it, what it does not do, and points to the correct sibling tool. No critical information appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter, explaining its format. The description adds semantic meaning beyond the schema by explaining that the signature is from the payment wallet, which conveys why the decision_id is authenticatable. This enriches the parameter's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states it decodes a decision_id and checks whether Permit Verdict actually issued it, using specific verbs and the resource. It also differentiates from the sibling verify_decision by explicitly stating it does NOT assess current correctness. This is a clear, specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use it (for decision_ids shown by a counterparty or issued earlier) and explicitly directs users to verify_decision for checking validity. It also notes it costs nothing and needs no wallet, providing clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![permitverdict-mcp MCP server](https://glama.ai/mcp/servers/okwithit9-debug/permitverdict-mcp/badges/card.svg)](https://glama.ai/mcp/servers/okwithit9-debug/permitverdict-mcp)

Score Badge

Copy to your README.md:

[![permitverdict-mcp MCP server](https://glama.ai/mcp/servers/okwithit9-debug/permitverdict-mcp/badges/score.svg)](https://glama.ai/mcp/servers/okwithit9-debug/permitverdict-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/okwithit9-debug/permitverdict-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server