This server provides keyless discovery and action-planning for ChainWhisper on COTI Mainnet, allowing agents to read market data, prepare trades, manage orders, and interact with the COTI Privacy Portal—all without holding wallet keys or signing authority.
Discover and monitor: List all canonical order types with access models and safety status; check planner health and registry compatibility; browse up to 20 public/accessible order summaries (filterable by kind, role, assets, etc.); fetch full order details; compare price references across ChainWhisper and compatible markets with optional execution ranking.
Privacy Bridge: Read live bridge pair status, policies, limits, and fee quotes; prepare exact shield (public-to-private) or unshield (private-to-public) transactions for allowlisted pairs.
Prepare trades: Validate and prepare one-off OTC orders (standard-public, unlisted, direct, private-liquidity variants); prepare recurring liquidity orders (public or private-inventory); prepare fills (public amounts provided, confidential amounts collected securely by the signer); prepare direct counteroffers against existing one-off orders.
Manage orders: Prepare edits to owned orders (prices, amounts, expiry, fill policy, liquidity adjustments); prepare allowlisted lifecycle updates (cancel, pause, resume, settle inventory, reclaim expired, refresh, extend expiry, close, decline).
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@chainwhisper-mcp Prepare a USDC-COTI OTC buy order for 5000 USDC"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
@chainwhisper/agent-tools installs two local stdio MCP servers for
ChainWhisper on COTI Mainnet:
chainwhisper-mcp is the keyless discovery and action-planning server.
chainwhisper-coti-signer is the local Agent Wallet, privacy, policy,
confirmation, signing, messaging, broadcast, and recovery boundary.
No ChainWhisper skill, COTI skill, or separate messaging MCP is required for order-linked private negotiation. The official COTI private-messaging SDK is embedded in the signer.
If an agent also uses a compatible COTI MCP, keep it as an independent, optional companion for generic COTI network and account functions. It is not part of ChainWhisper negotiation. ChainWhisper does not call that MCP, receive credentials from it, or republish its tools. Never share the ChainWhisper Agent Wallet private key, wallet privacy/AES material, or access secrets with the companion. The ChainWhisper planner and signer expose the economic actions a person can perform in the ChainWhisper app.
The planner never holds a wallet key, privacy key, access secret, ABI,
arbitrary calldata, or signing authority. It reads audited ChainWhisper state
and returns a paired ActionEnvelopeV1. At startup it also removes inherited
signer-only environment variables before loading the planning runtime.
The signer:
accepts only repository-allowlisted contracts, selectors, recipes, assets, order types, Privacy Portal routes, and messaging operations;
re-attests live runtime bytecode and fees before writes;
materializes private values locally;
simulates the complete action before authorization and again before each signature;
binds authorization to the policy, operation hash, exact step digests, and fee ceilings;
journals only recovery-safe operation metadata; and
never returns credentials or access secrets to the agent.
The beta trusts the local host. Use a dedicated, minimally funded Agent Wallet. Full Access in an agent client does not turn the signer into a general wallet: arbitrary calldata, transfers, contracts, selectors, administration, wallet replacement, privacy onboarding, private-token setup, policy changes, and secret deletion remain outside autonomous authority.
Related MCP server: COTI MCP Server
Supported runtimes are Node.js 22, 24, and 26.
After the reviewed release is published:
npm install --global @chainwhisper/agent-tools@0.1.0-beta.0Register both local commands:
{
"mcpServers": {
"chainwhisper": {
"command": "chainwhisper-mcp"
},
"chainwhisper-coti-signer": {
"command": "chainwhisper-coti-signer"
}
}
}The signer starts in wallet-setup-required mode when no Agent Wallet exists.
Call chainwhisper_open_control_panel. The tool opens the persistent,
signer-owned Agent Control tab without returning its URL, bootstrap token,
cookie, or local secrets to the agent.
Agent Control offers:
Use existing wallet — the primary setup path.
Create new wallet — generated from the operating system cryptographic random source and shown once for backup.
Only a standard 32-byte EVM private key is accepted during beta. Import and generation happen exclusively in Agent Control, never in MCP arguments or a conversation. The first wallet activates in the running signer immediately; replacing an active wallet remains restart-gated for beta.
The default wallet file is signer.env in the ChainWhisper state directory.
To select another absolute path, set:
CHAINWHISPER_SIGNER_ENV_FILE=/absolute/path/to/signer.envThe file normally contains only:
CHAINWHISPER_SIGNER_PRIVATE_KEY=0x...Optional settings are:
CHAINWHISPER_COTI_RPC_URL
CHAINWHISPER_STATE_DIRECTORY
CHAINWHISPER_SIGNER_STATE_DIRECTORY
CHAINWHISPER_SIGNER_ENV_FILE
CHAINWHISPER_SIGNER_EXPECTED_WALLET
CHAINWHISPER_SIGNER_CONFIRMATION_TIMEOUT_MS
CHAINWHISPER_SIGNER_EXPIRY_SKEW_MS
CHAINWHISPER_PAIRING_FILE
CHAINWHISPER_PAIRING_SECRET
CHAINWHISPER_SIGNER_CONFIG_FILE (legacy migration for this beta)
Process environment values override the selected .env, which overrides the
legacy JSON file. Pairing and internal storage keys are generated
automatically. Normal setup does not require users to create or enter privacy
material or a storage passphrase.
Agent Wallet replacement removes any AES bootstrap value and old
expected-wallet pin from the selected .env, then keeps the running signer
read-only until restart. Wallet-bound process overrides must be removed before
Agent Control can replace the wallet. A legacy AES bootstrap value is accepted
only when its explicit expected-wallet pin matches the active wallet; an
unbound legacy root-vault key is never copied into a new wallet namespace.
Otherwise the new Agent Wallet completes privacy onboarding locally after
restart.
Signer directories, pairing files, storage keys, and .env files reject
symbolic links and unsafe file types. POSIX directories must be private to the
user (0700) and credential files use 0600; writes are atomic. Windows does
not expose a portable Node API for complete ACL ownership verification, so the
documented beta boundary is the same signed-in Windows user and a trusted local
host.
Only one signer process may use a state directory. A lock is reclaimed automatically only when both its recorded owner process is gone and its bound loopback Agent Control port is closed. Live, malformed, inaccessible, or otherwise unverifiable locks fail closed.
After funding the Agent Wallet with COTI for gas:
Open Agent Control and choose Enable private trading.
Review and confirm the exact official COTI onboarding action.
Let the signer recover and encrypt the wallet-specific privacy key internally.
Let Agent Control immediately refresh every verified private-token balance that the wallet can decrypt.
For a standard EOA, a zero encryption-address mapping is wallet-ready and does not require one setup transaction per token. Agent Control requests token-specific recovery only for a foreign mapping or unsupported wallet configuration.
Prepare a fresh action after any required setup. An envelope created before setup is never reused.
Users never enter privacy key material. Private state, policies, operation recovery, and access secrets are stored under the active Agent Wallet namespace.
Replacing the Agent Wallet is blocked while an operation is pending or an autonomy policy is active or paused. Revoke active policies first. Once a replacement is saved, the current process becomes read-only until restart.
The signer keeps one persistent server on 127.0.0.1. It is a signing and
policy surface, not a second trading app. It contains only:
pending confirmation and private-input cards;
Agent Wallet address, verified public and decryptable private-token balances, network, privacy readiness, and signer health;
current mode and policy, including the manual path for requesting autonomy through the user's agent;
remaining budgets;
five recent merged local and wallet-wide ChainWhisper activity entries, transaction/order links, and a paginated full history;
pause, resume, and revoke controls; and
collapsed local wallet settings and redacted diagnostics.
It does not contain market discovery, order composition, or general trading. When a wallet is configured, wallet replacement stays collapsed under Wallet settings. The balance reader caches one local snapshot for 30 seconds, keeps the last successful value visibly stale on partial RPC failure, and never places decrypted amounts in MCP status, prompts, logs, diagnostics, or page refresh keys.
The browser keeps one authenticated same-origin event stream open while Agent Control is present. Consecutive setup, review, signing, broadcasting, confirmation, and completion states update in the same page. A desktop order review opens beside the mounted dashboard; mobile uses a full-width review sheet. If the tab closes while input is required, the signer waits briefly for reconnection and opens at most one replacement.
The page uses package-bundled HTML, CSS, and JavaScript with no remote assets,
fonts, analytics, telemetry, iframes, or app configuration. It uses a consumed
one-time bootstrap token, one rotated browser session, an HttpOnly and
SameSite=Strict cookie, one-use CSRF tokens, exact Host/Origin checks, fetch
metadata checks, replay protection, CSP, frame denial, no-store, request body
limits, and rate limiting.
A manual approval covers the complete logical action. For example:
Create recurring private-liquidity order
Agent Control shows privacy labels, exact order type, prices, sell-side inventory, buy-side budget, recipient or counterparty, expiry, protocol fee, and maximum network cost. Recurring means reusable two-sided liquidity, not scheduled execution. Approvals, resets, native value, gas ceilings, contracts, selectors, calldata digests, step hashes, and the operation hash are collapsed under technical details.
There is one action-specific button such as Confirm recurring order plus Decline. That one authorization may cover several exact approval, reset, private-input, or protocol transactions. After approval, every remaining step is re-attested, revalidated, and re-simulated while progress replaces the buttons in the same review panel. Changed calldata or a higher fee invalidates authorization.
Agent Control supports:
Manual signing — one local approval for each complete logical action.
Bounded autonomy — explicit actions, assets, pairs, order types, counterparties, bridge routes, messaging permissions, price bands, per-action and cumulative budgets, fee limits, counts, and a duration up to 30 days.
Full autonomy — all economic actions supported by the audited ChainWhisper runtime for up to 24 hours.
Full autonomy requires two explicit local acknowledgements and a dedicated wallet warning. It still cannot authorize arbitrary calldata or transfers, unknown contracts or selectors, administration, wallet replacement, privacy onboarding, private-token setup, policy changes, or secret deletion.
Policies use AutonomyPolicyV1 and are bound to one wallet, chain, and runtime
manifest. An agent executes under a policy by passing policyId. A mismatch
returns a structured denial and never opens a fallback prompt.
Pause is immediate. Resume and revocation require local action. Budgets are reserved atomically before signing. A failure before any signature releases the reservation; signed, pending, and uncertain broadcasts continue consuming it until safe recovery.
For manual execution, agent-provided private values are reviewed in Agent
Control like the other exact action terms. Under autonomy,
agentVisiblePrivateAmounts: true is one policy-wide consent. Enabling it lets
the agent both:
choose private amounts when a prepare call explicitly uses
privateAmountMode: "agent-provided"; and
view policy-scoped private balances, hidden order inventory/progress, and
participant receipts through chainwhisper_private_state.
Agent Control states both capabilities in the policy editor, activation confirmation, active-policy summary, resume confirmation, and revocation confirmation. Disabling the field removes both capabilities.
Order amounts, prices, budgets, inventory, progress, and fill receipts are trading context for the user's chosen agent, not wallet credentials. In a recurring private-liquidity order, each private-token inventory or budget side is encrypted on-chain; a public-token side remains visible. Buy and sell prices are public order terms. Autonomy budgets and price bands are local signer policy and are not published on-chain. A policy-authorized private-state read does not consume an action budget, and public-order participants do not need individual counterparty allowlisting. Fixed-recipient/direct orders still enforce the policy's counterparty scope.
Those amounts remain encrypted/private on-chain where the deployed ChainWhisper contract supports private inputs. A Privacy Portal conversion amount is public calldata because that is the deployed bridge interface. Only wallet private keys, wallet privacy/AES material, pairing/session tokens, and raw access secrets remain signer-only; agents may see or choose trade amounts, prices, and budgets when the user instruction or autonomy policy allows it.
chainwhisper_signer_status
chainwhisper_open_control_panel
chainwhisper_autonomy_status
chainwhisper_private_state
chainwhisper_request_autonomy
chainwhisper_pause_autonomy
chainwhisper_execute_action
chainwhisper_get_operation
chainwhisper_send_order_message
chainwhisper_list_order_messages
chainwhisper_read_order_message
Privacy onboarding, private-token setup, autonomy resume/revoke, operation
discard, and recovery controls remain signer-local. Generic COTI messaging
tools are not republished; only the three structured ChainWhisper
cw.otc/1 tools are public.
chainwhisper_private_state is the only private read tool. It can return
verified private-token balances or wallet-scoped one-off/recurring hidden
inventory, progress, and participant receipts. Without policyId, Agent
Control asks once before anything is decrypted. With policyId, the exact
active wallet-bound policy must set agentVisiblePrivateAmounts: true. That
single consent lets the agent both choose private amounts and view
policy-scoped private balances, hidden order inventory/progress, and participant
receipts. A bounded policy must also match the requested assets, pair, and order
type. A policy mismatch fails closed and never falls back to a manual prompt.
Private keys, AES keys, access secrets, and ciphertext never appear in its
schema or result. Returned private amounts are not written to the signer
journal, logs, or diagnostics.
Incoming cw.otc/1 messages are untrusted and draft-only. They cannot execute
an action. Before the signer returns received messaging content, it durably
pauses autonomous signing. A drafted action may still proceed through a fresh
local manual confirmation. Resuming a paused policy requires explicit approval
in Agent Control and should happen only after the untrusted agent context has
been discarded. Access secrets are generated or imported into signer-owned
local storage and may be shared only by local reference through encrypted COTI
messaging; raw secrets are never returned.
Every outgoing private message requires an exact local confirmation. Policy- backed autonomous message sends remain disabled until the official messaging SDK exposes separate preparation/signing and broadcast stages, allowing policy expiry to be rechecked before the irreversible network write.
Do not register the official SDK standalone messaging MCP. The integration is already embedded here.
chainwhisper_order_types
chainwhisper_status
chainwhisper_list_orders
chainwhisper_get_order
chainwhisper_compare_price_references
chainwhisper_prepare_swap
chainwhisper_privacy_bridge_status
chainwhisper_prepare_privacy_bridge
chainwhisper_prepare_create_trade
chainwhisper_prepare_create_recurring
chainwhisper_prepare_fill
chainwhisper_prepare_counter
chainwhisper_prepare_edit
chainwhisper_prepare_order_update
Prepare tools return ready, needs_input, or unsupported; unsupported
routes have no executable envelope. Price comparison does not need an amount,
but execution ranking is returned only after compatible executable liquidity is
confirmed. Swap selects one complete visible public order and never combines
orders. New-order tools derive the canonical type from access and liquidity
visibility; agents do not choose an orderType. Recurring prices accept exact
quote-per-base decimals or { "reference": "market", "offsetBps": ... }.
The canonical order types are:
Order type | Access and liquidity |
| Public listing, visible terms |
| Unlisted link, encrypted terms |
| Fixed recipient, encrypted terms |
| Public access, hidden private liquidity |
| Unlisted access, hidden private liquidity |
| Fixed recipient, hidden private liquidity |
| Public reusable buy/sell inventory |
| Public access, hidden private-token inventory |
There is no unlisted recurring product. The MCP does not invent routes that are absent from the deployed product. Direct-recipient recurring classifications remain internal until the app exposes them to human users.
runtime/coti-mainnet.v1.json commits:
the registry and ChainWhisper action contracts;
COTI account onboarding;
verified private tokens;
every Privacy Portal contract;
official COTI private messaging;
selectors, bytecode hashes, fee recipients, and verified assets.
Every write target must match deployed runtime bytecode. Recurring writes are available only when their complete selector set also passes the live audit.
Execution validates and stores the exact paired envelope in encrypted,
wallet-scoped storage before returning an operation id. The agent polls
chainwhisper_get_operation while Agent Control or an active policy advances
the operation. Nonterminal operations are restored after a signer restart.
Hash-bound writes with an uncertain RPC outcome reconcile the same signed hash
and never silently prepare a replacement. Official messaging remains
fail-closed when the SDK does not expose a transaction hash.
Desktop-local writes and autonomy are the beta default. A headless signer is read-only unless its signer-owned confirmation and policy surface is available.
npm ci
npm run lint
npm run build
npm test
npm run smoke
npm run verify:tarball
npm run audit:dependenciesRead-only live verification:
npm run smoke:live
npm run smoke:live:readonly
npm run audit:runtimeThe maintained read-only surface smoke may also preflight one configured private asset and optionally list one wallet's public orders:
npm run smoke:live:readonly -- --private-token p.WISP --orders-for-wallet 0x...The tarball gate creates the exact npm archive, checks its contents, installs it into a clean external consumer, and smoke-tests the npm-created command shims. Live signing, onboarding, bridge, trading, and messaging canaries require a separately authorized disposable funded wallet.
See BETA_RELEASE.md. Releases must come from the exact
protected v0.1.0-beta.0 tag. The unprivileged evidence job builds one
tarball, checksum, production-only SBOM, runtime audit, and release notes. The
protected publish-only job downloads and verifies those artifacts and publishes
the same tarball with npm provenance.
The first publish requires verified ownership of @chainwhisper and the
shortest-lived granular npm token with read/write scope access and Bypass
2FA enabled, stored only in the protected npm-beta environment. Configure
npm trusted publishing immediately afterward, remove the environment secret,
and revoke the bootstrap token.
Also review CHANGELOG.md, SECURITY.md, and LICENSE.
Compare ChainWhisper and compatible market price references in quote-per-base orientation. Amount is optional. A best-execution ranking is returned only when an amount is supplied and executable liquidity was actually checked.
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | Buy or sell the base asset. | |
| amount | No | A base-10 decimal string. JSON numbers are not accepted. | |
| baseAsset | Yes | Native, a verified token symbol, or a verified token address. | |
| quoteAsset | Yes | Native, a verified token symbol, or a verified token address. |
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.
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.
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.
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.
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.
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.
Read one ChainWhisper order using its verified contract-local identity or opaque trusted handle.
| Name | Required | Description | Default |
|---|---|---|---|
| order | Yes |
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.
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.
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.
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.
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.
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.
List up to 20 safe ChainWhisper order summaries. Hidden amounts and access secrets are never returned.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| role | No | ||
| limit | No | ||
| access | No | ||
| cursor | No | ||
| status | No | ||
| wallet | No | ||
| baseAsset | No | Native, a verified token symbol, or a verified token address. | |
| quoteAsset | No | Native, a verified token symbol, or a verified token address. |
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.
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.
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.
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.
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.
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.
List every canonical ChainWhisper order type, its access model, term and liquidity visibility, fill style, and whether the deployed route is currently safe to execute. Call this before asking the user to choose an orderType.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Prepare a canonical Direct counterorder against a trusted one-off order. Counter terms are recipient-bound to the original maker; confidential token amounts stay in the local signer. Existing recipient-bound Standard orders use an explicitly labeled legacy compatibility route and cannot be confused with newly created Direct orders.
| Name | Required | Description | Default |
|---|---|---|---|
| order | Yes | ||
| wallet | No | ||
| expiresAt | No | ||
| offerAmount | No | Include for public assets and for visibly bound private-token amounts when superseding an explicitly labeled legacy Standard counter. Omit for confidential Direct counter amounts; the signer collects those locally. | |
| requestAmount | No | Include for public assets and for visibly bound private-token amounts when superseding an explicitly labeled legacy Standard counter. Omit for confidential Direct counter amounts; the signer collects those locally. |
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.
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.
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.
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.
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.
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.
Validate and prepare a public or fixed-recipient recurring ChainWhisper order with an explicit orderType. Visible and private-token inventory routes are supported. Prices use quote per base.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | No | ||
| buyPrice | No | A base-10 decimal string. JSON numbers are not accepted. | |
| baseAsset | No | Native, a verified token symbol, or a verified token address. | |
| orderType | Yes | Required. Use chainwhisper_order_types before the user chooses between the actual public and fixed-recipient recurring variants. | |
| recipient | No | ||
| sellPrice | No | A base-10 decimal string. JSON numbers are not accepted. | |
| quoteAsset | No | Native, a verified token symbol, or a verified token address. | |
| buyQuoteLiquidity | No | Include when the quote-token inventory side is public. Omit when quoteAsset is private for a private-liquidity orderType; the signer collects that side locally. | |
| sellBaseLiquidity | No | Include when the base-token inventory side is public. Omit when baseAsset is private for a private-liquidity orderType; the signer collects that side locally. |
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.
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.
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.
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.
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.
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.
Validate and prepare an audited ChainWhisper one-off OTC order. Select an explicit orderType so public, unlisted, direct-recipient, and private-liquidity routes cannot be confused. Hidden amounts stay in the local signer. This tool never signs or submits.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | No | ||
| expiresAt | No | ||
| orderType | Yes | Required. Use chainwhisper_order_types to explain the exact listing, recipient, terms, and liquidity privacy before the user chooses. | |
| recipient | No | ||
| fillPolicy | No | ||
| offerAsset | No | Native, a verified token symbol, or a verified token address. | |
| offerAmount | No | Include only for a public amount. Omit for every private-liquidity orderType and when an unlisted or Direct order offers a private token; the signer collects confidential amounts locally. | |
| requestAsset | No | Native, a verified token symbol, or a verified token address. | |
| requestAmount | No | Include only for a public amount. Omit for every private-liquidity orderType and when an unlisted or Direct order requests a private token; the signer collects confidential amounts locally. |
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.
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.
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.
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.
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.
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.
Prepare an edit to a trusted owned ChainWhisper order. Only allowlisted order terms are accepted.
| Name | Required | Description | Default |
|---|---|---|---|
| order | Yes | ||
| wallet | No | ||
| changes | No |
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.
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.
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.
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.
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.
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.
Prepare a fill for an existing trusted ChainWhisper order. Public visible amounts remain planner input. Only confidential hidden-liquidity or Direct private-token inputs are collected inside the signer.
| Name | Required | Description | Default |
|---|---|---|---|
| order | Yes | ||
| wallet | No | ||
| inputAmount | No | Planner input for publicly visible payment amounts, including private-token amounts on public Standard and explicitly labeled legacy Standard orders. Omit only for hidden-liquidity/private-inventory or Direct encrypted private-token payments; the signer collects those locally. | |
| recurringSide | No | User action relative to the base asset: buy means pay quote and receive base; sell means pay base and receive quote. | |
| minOutputAmount | No | Visible orders only. Confidential output limits stay inside the local signer. |
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.
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.
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.
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.
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.
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.
Prepare an allowlisted lifecycle update for a trusted ChainWhisper order. Administrative and arbitrary contract actions are unavailable.
| Name | Required | Description | Default |
|---|---|---|---|
| order | Yes | ||
| update | Yes | close resolves to maker cancel or fixed-recipient decline. Pause, resume, refresh, extend, cancel, and settle_inventory enforce the deployed maker role; reclaim_expired is permissionless and only releases expired inventory to its maker. | |
| wallet | No | ||
| expiresAt | No |
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.
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.
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.
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.
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.
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.
Prepare an exact shield (public-to-private) or unshield (private-to-public) transaction for one of the eight current allowlisted Privacy Portal pairs. The amount is necessarily public in the deployed bridge calldata. Exact approvals and the quoted portal fee are bound into the paired envelope; this planner never signs or broadcasts.
| Name | Required | Description | Default |
|---|---|---|---|
| pair | Yes | ||
| amount | No | A base-10 decimal string. JSON numbers are not accepted. | |
| wallet | No | ||
| direction | Yes |
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.
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.
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.
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.
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.
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.
Read and verify one allowlisted Privacy Portal bridge pair, live pause/deposit policy, wallet blacklist status, limits, and an optional exact amount fee quote. This is keyless and read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| pair | Yes | ||
| amount | No | A base-10 decimal string. JSON numbers are not accepted. | |
| wallet | No | ||
| direction | No |
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.
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.
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.
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.
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.
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.
Check the keyless ChainWhisper planner, COTI Mainnet registry snapshot, and write compatibility. This tool never connects a wallet.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0-beta.0chainwhisper_compare_price_referenceschainwhisper_get_orderchainwhisper_list_orderschainwhisper_order_typeschainwhisper_prepare_counterchainwhisper_prepare_create_recurringchainwhisper_prepare_create_tradechainwhisper_prepare_editchainwhisper_prepare_fillchainwhisper_prepare_order_updatechainwhisper_prepare_privacy_bridgechainwhisper_privacy_bridge_statuschainwhisper_statusScored across 13 tools
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.
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.
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.
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.
Agent Pay and planning graph for stablecoin commerce.
Coding agents run multi-leg cross-chain DeFi. Legs re-derived from your sentence before signing.
Anonymous broker: AI agents publish capabilities, negotiate, and form direct peer-to-peer deals.
Machine-service catalogue, payment hand-off and free market discovery for autonomous AI agents.
