@cubiczan/chp-mcp
Server Quality Checklist
Latest release: v0.2.0
- Disambiguation2/5
The authorization lifecycle is split across several tools with fuzzy boundaries: evaluate_spend_gate and evaluate_tool_approval both evaluate proposed actions, while approve_spend, issue_approval_receipt, and request_authorization can all produce signed receipts. Detailed descriptions help, but an agent selecting by name alone will struggle to identify the correct phase.
Naming Consistency4/5Most tools follow a clear lowercase verb_noun pattern such as evaluate_spend_gate, place_equity_order, inspect_audit_ledger, and authorize_tool_call. The only deviations are the two chp_* utility tools, chp_content_hash and chp_version, which are consistently prefixed but not verb-led.
Tool Count4/5Twelve tools is within the ideal range for a policy/authorization MCP and the count is not bloated. However, there is some redundancy in the approval and receipt-issuance tools, so a couple of tools could be consolidated without losing functionality.
Completeness4/5The core flow is covered end-to-end: evaluate policy, request/approve authorization, issue and verify receipts, execute scoped reference tools, and inspect the audit ledger. Missing pieces are mostly non-critical, such as explicit receipt revocation or allowlist management, but agents can work around these.
Average 3.6/5 across 12 of 12 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral outcomes: auto-lock mints a receipt, HITL_REQUIRED waits for an approver, hard fails return a structured deny, and the result is recorded on the audit ledger. This gives a clear picture of side effects and failure modes, especially since no annotations are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise but uses specialized jargon ('auto-lock', 'HITL_REQUIRED', 'hard fails') that may be unclear without additional context. The structure is acceptable but could be more streamlined to avoid ambiguity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain how the signed receipt is used, what constitutes a 'scoped reference tool', or what the expected output format is. With no output schema and only partial parameter documentation, an agent would struggle to invoke this tool correctly in a real scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 7 parameters but only 3 have descriptions (tool, args, approver), and the description does not explain any of them. Parameters like scope, policy, ttl_seconds, and committed_today are entirely undocumented both in schema and description. The description adds no semantic value for parameters, failing to compensate for the 43% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Request a signed authorization receipt') and the target ('scoped reference tool') with concrete examples like place_equity_order, wire_treasury_transfer, and rebalance_portfolio. It is specific enough for an agent to understand the tool's primary function, though it could be slightly more explicit about the 'signed receipt' concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions outcome branches (auto-lock, HITL_REQUIRED, hard fail) but does not explicitly state when to use this tool versus siblings like evaluate_spend_gate or approve_spend. No guidance is provided on when this tool is the appropriate choice, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the operation is synthetic, that there is no live desk, and that an authorization receipt is required. It does not describe what happens on success or failure, whether portfolio state is persisted, or how invalid or expired receipts are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no fluff or repetition. Every phrase carries meaningful operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested schema, no annotations, and no output schema, the description is far from complete. It omits essential parameter meanings, expected output, error behavior, and the process for validating the authorization receipt.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has five parameters plus a nested receipt object, but the description only mentions notional and the receipt requirement generically. portfolio_id, target_weights, confidence, and the receipt's internal fields are completely undocumented, and schema coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action as a portfolio rebalance, states the synthetic scope, and names the key resource. It does not explicitly differentiate from sibling tools like place_equity_order, but the verb and resource are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides important preconditions: requires a signed authorization receipt and HITL above $1,000 notional, and notes that no live desk is involved. However, it does not explicitly state when to choose this tool over alternatives or describe the expected workflow for obtaining the required receipt.
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?
The description discloses key behaviors: it is synthetic (no live bank rail), requires a receipt by default, and missing receipt leads to a logged deny. This is useful transparency, though it does not mention whether the operation is read-only or write, or what effects it has on system state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point, using three short sentences. It is well-structured and does not include unnecessary details or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description gives some operational context (policy, synthetic nature), it omits essential details about parameters, output, and when to use this tool relative to siblings. Given the complexity (7 parameters, nested objects), the description is insufficient for an agent to use it correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
None of the seven parameters (from_account, to_account, amount, currency, confidence, memo, receipt) are explained. The description only mentions the receipt policy but does not describe the receipt object's fields or the meaning of any other parameter. With 0% schema coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a 'synthetic treasury wire' with a scope, but the verb is implicit and the term 'synthetic' may confuse rather than clarify. It does not explicitly state the action (e.g., 'transfer funds') or the intended use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some context (requires a human-issued receipt, no live rail, missing receipt results in a logged deny) but does not explicitly say when to use this tool versus alternatives. The guidance is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the order is synthetic (no live execution) and that a missing receipt results in a logged 'missing_receipt deny'. However, it omits success behavior, response format, side effects, or any other operational details. It adds meaningful behavioral context but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. It front-loads the core purpose and scope, then adds critical behavioral notes. Every sentence earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, nested receipt object, authorization workflow, no output schema), the description is incomplete. It lacks return value expectations, does not explain how to obtain the authorization receipt, and does not describe parameter constraints or the meaning of 'bound to these args' in terms of args_hash. It provides essential context but leaves many operational gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds semantic meaning for the 'receipt' parameter by noting it must be 'bound to these args' and that it is 'optional on the wire'. Other parameters (symbol, side, quantity, notional) are self-explanatory by name, and the description does not elaborate further, leaving some semantics unexplained (e.g., limit_price, confidence). It provides partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool places a 'Synthetic equity order' with an explicit scope ('trading:equities:place') and clarifies it is not a live venue. This clearly identifies the action and resource, though it does not explicitly differentiate from sibling tools like rebalance_portfolio or wire_treasury_transfer beyond the equity-order focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool requires a signed authorization receipt but does not explicitly state when to use it versus alternatives, nor does it direct the agent to obtain the receipt from a specific sibling (e.g., request_authorization or issue_approval_receipt). It provides context (synthetic, no live venue) but no explicit when/when-not guidance.
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?
Explicitly describes return values (LOCKED, HITL_REQUIRED, BLOCKED), the side effect of writing a policy_deny to the audit ledger on BLOCKED, and the non-overridable nature of hard violations. This gives a clear picture of the tool's 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences that front-load the primary purpose and then efficiently cover outcomes and side effects. No redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately explains the expected return statuses, the content hash, and the audit ledger side effect. It does not detail the structure of 'claims', but that is not essential for invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all three parameters (action, policy, committed_today) with meaningful context. The tool description itself does not add additional parameter-specific meaning, but schema coverage is 100%, so the baseline applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Run'), resource ('CHP Profile B capital/spend gate'), and scope ('proposed action'). It does not name sibling tools, but the specificity of the gate and its profile makes its purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives like 'approve_spend' or 'request_authorization'. It only describes what the tool does, not when it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions side effects like recording the decision and generating a MAC, but it does not explain the return format, verification process, or whether the tool is idempotent. It leaves out details about how host_bound and _meta affect behavior, and lacks an explicit statement about read/write nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and highly technical, repeating details from the schema (MAC coverage, signing key source) without adding clarity. It is not concise and may overwhelm an agent with jargon, making it less effective than a shorter, more focused summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description assumes prior knowledge of the CHP system (e.g., CHP canonical JSON, cubiczan.principal, host_bound) and does not explain these concepts. For a standalone agent, this is incomplete; it lacks definitions and fails to specify how to obtain required host-injected fields or interpret the receipt output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for many parameters (e.g., actor, decision, ttl_seconds), but some fields like 'call' at the top level lack descriptions, and the tool description does not add meaning beyond what the schema already gives. The description repeats some schema details but does not clarify ambiguous parameters like 'signing_key' or 'host_bound'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records a human allow/deny decision and returns a signed receipt. It specifies the exact action and outcome, leaving no ambiguity about the tool's primary function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used after a human decision, but it does not explicitly contrast with sibling tools like approve_spend or request_authorization. The intended context is inferable, though not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation via 'Report', but does not explicitly state that no data is modified or that it is safe to call. Since no annotations are provided, the description carries the full burden of transparency and could be more explicit about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words or repetition. It is well-structured and easy to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description is complete and sufficient. It fully describes the tool's purpose without leaving any critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the input schema, so the description adds no parameter-level information. The baseline score of 3 is appropriate as there is nothing to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports MCP server and CHP Profile B protocol versions, with a specific verb and resource. No ambiguity or missing information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool, such as checking version compatibility before other operations. It simply states what it does without context or alternatives.
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?
With no annotations, the description carries the full burden. It discloses a constraint (cannot approve BLOCKED) and a conditional side effect (mints a signed authorization receipt when tool and bound_args are supplied). This goes beyond a generic 'approve' statement, though it omits details like irreversibility or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences, front-loading the core purpose and then adding a key constraint and side effect. Every sentence earns its place, and it references spec sections for deeper detail without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 8 parameters, nested objects, and no output schema. The description does not explain the structure or intent of the action and policy objects, nor what happens when tool and bound_args are absent, nor the return value. The agent would struggle to construct valid calls without additional knowledge from spec sections or examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, so the description should compensate for undocumented parameters like scope, action, policy, and committed_today. It only references tool and bound_args when explaining the receipt minting, adding no meaning to the other four parameters. This leaves the agent without guidance on how to populate critical nested objects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: human-in-the-loop approval for proposals that returned HITL_REQUIRED. It specifies the verb 'approve' and the resource (proposal), and distinguishes itself by noting it cannot approve BLOCKED/hard-rule failures. This sets it apart from sibling tools like request_authorization or issue_approval_receipt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit conditions: use for HITL_REQUIRED proposals and avoid for BLOCKED/hard-rule failures. It does not name alternative tools for other scenarios, but the context is clear enough for an agent to know when to invoke this tool versus others.
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?
With no annotations provided, the description carries the full burden. It discloses the algorithm (SHA-256), the canonicalization method, and the consistency with Python digests. It doesn't mention edge cases or determinism, but for a pure hash function, this is reasonable. A minor gap is the lack of explicit side-effect-free declaration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core operation (SHA-256 over float-aware canonical JSON) and adds the interoperability detail. Every word earns its place, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no output schema, and no annotations. The description fails to specify the return format (e.g., hex string, base64, binary) or error behavior for invalid inputs. An agent cannot be sure how to interpret the result, which is a significant gap for a hash function. Given the simplicity, this should have been included.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter 'value' with the description 'JSON-serializable value to hash'. The tool description adds no additional semantic meaning beyond that, so the baseline of 3 applies. It doesn't clarify format, size limits, or serialization specifics beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes a SHA-256 hash over float-aware canonical JSON, referencing CHP §3.1 and matching Python consensus-hardening-protocol digests. This specifies the verb (compute hash), resource (canonical JSON), and the exact algorithm, distinguishing it from unrelated sibling tools like chp_version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for cross-language consistency (matching Python digests) within the CHP protocol. While it doesn't explicitly list when not to use it, there are no similar sibling tools, so the context is sufficient. It could be more explicit about typical use cases, but the purpose is clear.
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?
With no annotations supplied, the description carries the transparency burden and does enumerate important denial cases: changed arguments, expiry/replay, MAC failure, host-bound override, and binding mismatch. It does not describe success return values or error channels, but the security-relevant behavior is well exposed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences convey the operation, preconditions, and key failure modes without filler. Every sentence adds information needed to call or avoid misuse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nested call/policy/receipt objects and no output schema, and the description focuses on deny conditions rather than success output or parameter construction. It leaves some gaps around how to build policy and how signing_key is used, though the core authorization check is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The prose adds meaning for receipt, arguments, and host_bound by explaining which conditions cause denial. It does not clarify policy construction or the role of signing_key, and with only 50% schema coverage the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and object: authorize a tool call against a previously issued receipt. It immediately separates this from issuing or evaluating receipts and highlights the core precondition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the required precondition (previously issued receipt) and warns that allowlist matches alone are denied, which tells callers when not to use it. It does not explicitly name sibling flows such as request_authorization or issue_approval_receipt, so it stops short of full alternative routing.
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?
The description discloses the non-destructive nature ('Read') and the verification behavior ('verify the chain') that checks signatures. It does not mention auth needs or rate limits, but the read-only and verification aspects are transparent given no 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundant information. Every word adds value, clearly stating the action, resource, and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete enough to invoke the tool: it names the resource, the action, and the parameter. It does not specify return format, but since there is no output schema and the operation is a simple read, this is acceptable. The mention of 'synthetic scoped reference tools' is slightly ambiguous but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'limit' is fully described with its meaning ('Max trailing entries') and default value (50). Schema coverage is 100% and the description adds clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Read' and the resource 'CHP-signed deny / authorize / execute ledger' with the action 'verify the chain'. It also mentions a secondary purpose of listing synthetic scoped reference tools, but the primary purpose is unambiguous and distinct from 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides some context about reading and verifying the ledger but does not explicitly state when to use this tool versus alternatives. It mentions listing synthetic scoped reference tools, which hints at a use case, but lacks explicit conditions or selection criteria.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly reveals that allowlisting is not a grant, that host-injected fields are merged into the hash and cannot be overridden, and that ambiguity (wildcards, missing resource, unparseable arguments) results in denial. These are security-critical behaviors that an agent must know before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly packed sentences with zero fluff. The first sentence states the purpose, the second clarifies a key nuance (allowlist vs grant), and the third specifies the ambiguity-denial rule. Information density is high and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested objects and a nuanced policy, the description covers the critical decision logic well (allowlist behavior, host-bound merging, ambiguity handling). However, it does not enumerate the full set of possible outcomes beyond RECEIPT_REQUIRED and 'deny on ambiguity' — it never states what an approval result looks like, nor what happens for non-allowlisted tools. This leaves a minor gap in the agent's understanding of return values, which is notable given there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema fully describes the 'call' and 'policy' objects, the description adds substantial meaning beyond the schema: it explains how host_bound and _meta.cubiczan.host_bound are merged, that arguments are hashed with host-injected fields, and that wildcards/missing resources/unparseable args trigger denial. This semantic layer is essential for correct invocation and is not present in the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear, specific action: 'Evaluate a proposed MCP tool call.' It further clarifies the tool's role by contrasting a managed allowlist with a grant, and by detailing the ambiguity-denial behavior. This distinctively separates it from sibling tools like authorize_tool_call (which likely grants) and evaluate_spend_gate (which likely focuses on spend policy).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the pre-approval evaluation step by noting that allowlisted tools still return RECEIPT_REQUIRED and that ambiguity denies. However, it does not explicitly name alternative tools or provide when-to-use/when-not-to-use guidance. It leaves some inference to the agent about choosing this over sibling evaluation tools.
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:
Score Badge
Copy to your README.md: