chainwhisper-mcp

Server Quality Checklist

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

Latest release: v0.1.0-beta.0
Disambiguation5/5
Each tool has a clearly distinct purpose: order types, status, listing, reading, price comparison, bridge status, bridge preparation, and various order preparation actions (create trade, create recurring, fill, counter, edit, update). No overlapping functionality.
Naming Consistency5/5
All tools follow a consistent snake_case pattern with the prefix 'chainwhisper_' followed by a verb_noun structure (e.g., list_orders, get_order, prepare_create_trade). The verb 'prepare' is used uniformly for transaction-preparation tools.
Tool Count5/5
With 13 tools, the server covers a complex domain (orders, bridges, price references, lifecycle) without being overwhelming. Each tool serves a necessary function, and the count is well-scoped for the intended functionality.
Completeness4/5
The tool set covers essential operations: understanding order types, status checks, listing, reading, creating (one-off and recurring), filling, countering, editing, and lifecycle updates. Missing explicit deletion or cancellation, though lifecycle update may cover it. Minor gap, but otherwise comprehensive.
Average 3.7/5 across 13 of 13 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 38 commits in the last 12 weeks
- No stable releases found
- 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description claims to 'prepare an allowlisted lifecycle update' (a write operation), but annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, creating a direct contradiction. This severely undermines transparency.
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?
Description is two sentences and adequately concise, though it could be slightly more structured to improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing output schema, low parameter coverage, and an annotation contradiction leave the description incomplete for an agent to understand the tool's behavior and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'update' parameter has a description). The tool description provides no additional parameter meaning, leaving order, wallet, and expiresAt largely unexplained.
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?
Description states it prepares an allowlisted lifecycle update for a trusted ChainWhisper order, differentiating from siblings like prepare_create_trade. However, the read-only annotation contradicts the 'update' action, slightly diluting clarity.
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?
Description implies usage for allowed updates and notes that administrative actions are unavailable, but lacks explicit when-to-use or when-not-to-use guidance compared to sibling prepare tools.
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?
The description says 'Prepare an edit', which suggests a mutation, but annotations declare readOnlyHint=true, indicating a read-only operation. This is a direct contradiction. Annotations already convey safety, but the description undermines them by implying a write operation.
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?
Two sentences efficiently convey purpose and constraint, with no extraneous text. However, the second sentence could be slightly more specific about 'allowlisted order terms'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is present, so the description should explain return values or side effects. It does not. Combined with low schema coverage and the annotation contradiction, the description lacks essential context for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema lacks descriptions for all 3 parameters. The tool description adds no parameter-level meaning, leaving the agent to infer the purpose of 'order', 'wallet', and 'changes' without guidance.
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 action ('Prepare an edit'), the resource ('trusted owned ChainWhisper order'), and a constraint ('Only allowlisted order terms are accepted'). It distinguishes from sibling tools like 'chainwhisper_prepare_create_trade' by focusing on editing an existing order.
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 for orders that are 'trusted owned' but does not explicitly state when to use this tool versus alternatives like 'chainwhisper_prepare_order_update' or 'chainwhisper_prepare_fill'. No exclusions or caveats are provided.
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 adds behavioral context beyond annotations: counter terms are recipient-bound, confidential amounts stay local, and legacy Standard orders use a separate route. Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which are consistent. The description enhances understanding without contradiction.
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 sentences that convey the core purpose and key behavioral nuances. No unnecessary words or repetition, and it front-loads the critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of counterorders and the absence of an output schema, the description lacks completeness. It does not explain return value, prerequisites, error scenarios, or how the output is used. While annotations indicate idempotency, the agent lacks full context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (40%); only offerAmount and requestAmount have descriptions. The tool description does not explain the order, wallet, or expiresAt parameters. It indirectly references confidential amounts but does not add substantial meaning to the input schema beyond what is already provided in schema descriptions for two 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 clearly states it prepares a 'canonical Direct counterorder' against a trusted one-off order, specifying recipient-bound terms and confidential token amounts. It distinguishes the tool as specific to countering orders, though it does not explicitly differentiate from sibling tools like chainwhisper_prepare_fill or chainwhisper_prepare_create_trade.
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 explicit guidance on when to use this tool versus alternatives (e.g., when to counter vs. fill vs. create trade). The description implies use for countering existing orders but lacks conditional advice or mentions of prerequisites.
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?
Annotations declare readOnlyHint true, idempotentHint true, destructiveHint false. The description adds that only safe summaries are returned and secrets are never included, which is useful but does not cover pagination, sorting, or default 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?
Single sentence, front-loaded with action and key constraints. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and no output schema, the description is too minimal. Lacks explanation of filtering options (kind, role, status, etc.), pagination via cursor, and default limit. Incomplete for a complex list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 22%, yet the description does not explain any parameter meaning (e.g., kind, role, cursor). The description fails to compensate for the low coverage, leaving agents to infer from schema alone.
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?
Clearly states it lists up to 20 order summaries, and specifies that hidden amounts and access secrets are never returned, providing a specific verb and resource scope. Differentiates from siblings like chainwhisper_get_order (single order) and chainwhisper_order_types (types).
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 on when to use this tool versus alternatives like chainwhisper_get_order for a single order, or when filtering is needed. Lacks context for prerequisites or exclusions.
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?
Annotations already set readOnlyHint, idempotentHint, destructiveHint. The description adds value by explaining how amounts are handled (planner input vs. signer collection). However, it does not disclose return behavior, authorization needs, or side effects beyond what annotations imply.
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?
Two sentences that efficiently convey purpose and key behavioral nuance. No wasted words, but could be slightly more structured (e.g., bullet points for clarity). Still well within good conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description leaves gaps for a complex tool: no explanation of what 'prepare' entails operationally, no return value specification, and no prerequisite details beyond 'existing trusted order'. The agent may lack critical workflow context.
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 60%, so baseline is 3. The description adds context for inputAmount and minOutputAmount by relating them to privacy modes, but does not provide new meaning for other parameters beyond the schema's own 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?
Clearly states the tool prepares a fill for an existing trusted ChainWhisper order. The verb 'prepare' differentiates it from other prepare tools among siblings, and the description of public vs confidential amounts adds specificity.
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 when to use (to prepare a fill for an existing order) but does not explicitly state when not to use or mention alternatives. No exclusions or alternative tool references are provided.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's 'validate and prepare' is consistent. It adds context about inventory routes and price format, but does not disclose potential side effects (none expected) or other behavioral traits beyond what annotations provide.
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 sentences that front-load the core purpose and key features. Every sentence earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and no output schema, the description is relatively complete on purpose but lacks details on return value or validation specifics. It covers the essential context for usage but leaves some gaps for an agent to infer.
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 description adds value beyond the schema by explaining that prices use 'quote per base' and that visible/private-token inventory routes are supported, which relates to the liquidity parameters. With schema description coverage at 78%, this overarching context is meaningful.
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 clearly states the tool validates and prepares a recurring ChainWhisper order with explicit orderType, and specifies support for public/fixed-recipient and visible/private-token inventory routes. It distinguishes from sibling tools like chainwhisper_prepare_create_trade by using 'recurring' but does not explicitly compare.
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 the tool is for recurring orders and mentions the need for explicit orderType, but does not provide explicit when-to-use or when-not-to-use guidance or direct alternatives. The usage hint for orderTypes is in the schema, not the description.
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 adds value beyond annotations by stating that the planner never signs or broadcasts (confirming readOnlyHint), that approvals and fee are bound, and that the amount is public. This provides meaningful behavioral context without contradicting any 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 two sentences with no redundant information. It front-loads the core purpose and includes essential behavioral notes, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and key behavioral traits, but lacks details on return value (what does 'prepare' output?), prerequisites (e.g., wallet must have funds for the pair), and error conditions. Given the absence of an output schema, the description should provide more completeness.
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?
With only 25% schema coverage, the description partially compensates by explaining direction as shield/unshield and noting the amount is public. However, it does not add meaning for wallet or pair beyond what the enum provides, and fails to clarify the amount's format or constraints beyond the schema pattern.
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 prepares shield or unshield transactions for Privacy Portal pairs. It uses specific verbs and resource, and implicitly distinguishes from other prepare tools (e.g., trade, fill) by focusing on privacy bridge operations. The scope is well-defined with the mention of eight allowlisted pairs.
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?
The description does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or contraindications. It lacks context that would help an agent decide between this and sibling tools like chainwhisper_prepare_create_trade or chainwhisper_privacy_bridge_status.
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 indicate read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context: the conditional return of best-execution ranking based on amount and liquidity checking. This goes beyond the annotation 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?
The description is extremely concise with two sentences. Every word serves a purpose: the first sentence states the core function, and the second provides critical conditional behavior. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should clarify what the tool returns. It only mentions 'best-execution ranking' conditionally, but does not describe the default output (e.g., list of price references, their format, or how they are ranked). This lacks completeness for an agent to understand the full behavior.
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?
With 100% schema coverage, the schema already documents each parameter. The description adds minimal value, only noting that amount is optional and affects output. The behavioral note on amount is useful but does not significantly enhance understanding beyond the schema.
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 ('Compare') and resource ('market price references'), clearly distinguishing it from sibling tools that deal with orders, status, and privacy bridges. The 'quote-per-base orientation' clarifies the comparison context.
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 explains that amount is optional and when best-execution ranking is returned, providing clear context for usage. However, it does not explicitly state when to use this tool versus alternatives, though the differentiation is implicitly clear from sibling tool names.
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. The description adds that the tool never signs or submits, reinforcing the read-only nature. It also mentions validation and local handling of hidden amounts, providing useful behavioral context beyond annotations. However, it does not describe the output or what happens after preparation.
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 four sentences long, concise, and front-loaded with the main purpose. It could be slightly more streamlined, but it avoids unnecessary detail and gets the key points across efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, nested objects, many siblings) and no output schema, the description covers the core purpose and a key behavioral trait, but lacks information about the return value, workflow positioning, and prerequisites beyond orderType selection. The agent may need additional guidance to use the tool correctly in a multi-step process.
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 schema has 56% parameter description coverage, so some burden falls on the description. The description adds context for orderType selection and hidden amounts (related to offerAmount/requestAmount), but does not explain other parameters like wallet, expiresAt, recipient, or fillPolicy. It provides moderate added value but does not fully compensate for undocumented parameters.
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 it validates and prepares a one-off OTC order, specifying it's for ChainWhisper audited orders. It distinguishes itself from sibling tools like chainwhisper_prepare_create_recurring by explicitly mentioning 'one-off' and states it never signs or submits, clarifying its role in the workflow.
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 tells the agent to select an explicit orderType to avoid confusion, and references chainwhisper_order_types for explanation. It also notes that hidden amounts stay local, guiding on when to include certain parameters. However, it does not explicitly compare to sibling tools like chainwhisper_prepare_fill or chainwhisper_prepare_counter, leaving some ambiguity about when to choose this tool over 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?
Annotations already provide readOnlyHint=true and idempotentHint=true, so the description adds value by disclosing the two identification methods. It does not contradict annotations. However, it could mention that no side effects occur, but annotations cover that sufficiently.
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?
One sentence of 12 words, front-loaded with the verb and resource. Every word is necessary; no filler or repetition.
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 operation with comprehensive annotations and no output schema, the description fully covers what the tool does and how to identify the order. The return value is implied (the order), and no additional context is needed.
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?
With 0% schema description coverage, the description compensates by explaining that the single parameter 'order' is either a verified contract-local identity (escrowContract + localId) or an opaque trusted handle. This adds meaning beyond the schema's structural constraints.
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 verb 'Read' and resource 'one ChainWhisper order', and specifies the two identification methods (contract-local identity or handle), which distinguishes it from sibling tools like chainwhisper_list_orders.
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 you have a specific order identifier, but does not explicitly state when to use this tool versus alternatives like chainwhisper_list_orders or when not to use it. No exclusion criteria or alternative tool names are mentioned.
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 indicate readOnly, idempotent, non-destructive. Description adds specific behavioral details about what is listed (access model, fill style, safety) beyond annotations, providing useful transparency for agent decision-making.
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?
Single sentence that efficiently communicates purpose and usage. No wasted words, front-loaded with key 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 no output schema, the description fully explains what the output contains (order type, access model, etc.) and provides usage context. No gaps remain for a zero-parameter listing tool.
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?
No parameters exist, schema coverage is 100% trivially. Description does not need to add parameter meaning; baseline score of 4 is appropriate as it adds no unnecessary param info.
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?
Description clearly states verb 'List' and specifies the resource: canonical ChainWhisper order types with details (access model, term, liquidity, fill style, safety). Distinguishes from siblings by advising to call it before asking user to choose an orderType.
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?
Explicitly states when to call ('before asking the user to choose an orderType'), providing clear usage context. Does not explicitly mention alternatives but the guidance is strong.
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 declare readOnlyHint, idempotentHint, and no destructiveness. The description adds value by specifying exactly what is checked (planner, registry, compatibility) and explicitly stating the tool never connects a wallet, which is critical behavioral context.
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 with no wasted words. The first sentence lists the three checks, the second provides a key safety note. Perfectly front-loaded and efficient.
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, parameterless status check with comprehensive annotations, the description covers the essential behavioral and scope details. It does not mention the return format, but given no output schema and the straightforward nature, this is acceptable.
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?
There are zero parameters, so schema coverage is effectively 100%. The description does not need to explain parameters, and the baseline for zero-parameter tools is 4.
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 specific verbs and resources: 'Check the keyless ChainWhisper planner, COTI Mainnet registry snapshot, and write compatibility.' It clearly distinguishes from sibling tools, which focus on orders, trades, and privacy bridge operations.
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 implies this is a quick health check tool with no parameters, and it explicitly states it never connects a wallet, suggesting safe use without wallet interaction. However, it does not explicitly state when to use it versus other tools.
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 declare readOnlyHint=true and idempotentHint=true. The description adds value by detailing exactly what is read (pause/deposit policy, blacklist status, limits, fee quote) and confirming keylessness, going beyond the annotations without contradiction.
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: the first efficiently lists the tool's capabilities, the second clarifies key properties (keyless, read-only). No superfluous words, front-loaded with the primary action.
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?
The description covers the tool's purpose and scope adequately given the rich annotations. It does not describe output format, but for a read-only query tool with no output schema, the description is sufficiently complete for an agent to understand what it retrieves.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite low schema description coverage (25%), the description maps each parameter to its functional role: 'pair' for the bridge pair, 'amount' for the optional fee quote, 'wallet' for blacklist status, and 'direction' implied for the fee quote direction. This adds meaningful context that the schema lacks.
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 specifies the verb 'read and verify' and the resource 'Privacy Portal bridge pair', listing concrete aspects like pause/deposit policy, wallet blacklist, limits, and fee quote. This clearly distinguishes it from sibling tools that are prepare/write tools.
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 states it is 'keyless and read-only', implying use for status queries. However, it does not explicitly contrast with sibling tools or provide when-not-to-use guidance, though the read-only nature serves as a strong hint.
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:

[![ChainWhisper-MCP MCP server](https://glama.ai/mcp/servers/RosuLaurentiu/ChainWhisper-MCP/badges/card.svg)](https://glama.ai/mcp/servers/RosuLaurentiu/ChainWhisper-MCP)

Score Badge

Copy to your README.md:

[![ChainWhisper-MCP MCP server](https://glama.ai/mcp/servers/RosuLaurentiu/ChainWhisper-MCP/badges/score.svg)](https://glama.ai/mcp/servers/RosuLaurentiu/ChainWhisper-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/RosuLaurentiu/ChainWhisper-MCP'

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