Reconcile declared stablecoin invoices and transfers; flag partial, pending and mismatched payments.
Scored across 3 tools
The three tools form a clear discover→retrieve→execute chain: search finds tool/citation pages, fetch pulls a specific reference by ID, and reconcile_stablecoin_records performs the actual reconciliation. The only mild risk is confusing search vs fetch, but the descriptions clarify that fetch requires an ID from search.
Two tools use bare generic verbs (fetch, search) while the third uses a long verb_noun snake_case name (reconcile_stablecoin_records). It is readable and all lowercase snake_case, but the stylistic split between terse verbs and a descriptive compound name is inconsistent.
Three tools is at the low end but each maps to a distinct step (discover, retrieve reference, execute reconciliation) and the server's stated scope is narrow. It is slightly thin but nothing is redundant or missing for the core task.
For a stateless reconciliation-review utility, the surface covers discovery, methodology/examples retrieval, and the reconciliation operation itself, with out-of-scope features (wallet sync, FX, refunds, persistence) explicitly disclaimed. Minor gaps like result export or batch handling remain, but the core workflow has no dead ends.
Retrieve a public tool reference by the ID returned from search. Contains methodology, limits, official source links and fictional worked examples; no user records. Cite the returned canonical URL.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | |
| title | Yes | |
| metadata | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read-only, idempotent, closed-world profile, so the description is free to add what they cannot: the payload contents (methodology, limits, source links, worked examples) and the assurance 'no user records.' It adds real value, though it says nothing about failure modes for an unknown ID.
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?
Three compact clauses: what it does, where the ID comes from, what it returns, plus one usage instruction. The retrieval action and ID source are front-loaded, and nothing is padding.
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 an output schema present, the description need not enumerate return fields; it correctly focuses on the input provenance, the no-user-records scope, and the citation obligation. An agent has everything needed to call it correctly in sequence after `search`.
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% for the single `id` parameter, so the description carries the load by explaining where the value comes from (the `search` result). That provenance is meaningful context the enum-only schema does not provide, though the exact ID format is still unspecified.
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?
States a specific verb (Retrieve) and resource (a public tool reference), and pins the input's provenance to the sibling tool: 'by the ID returned from search.' An agent can distinguish this single-item read from the list/query behavior of `search` without opening either schema.
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?
It clearly establishes the precondition for use — the ID must come from `search` — and adds a follow-up instruction ('Cite the returned canonical URL'). It does not state when not to use it or compare against `reconcile_stablecoin_records`, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stable Reconcile compares your declared invoices with recorded stablecoin transfers. It separates partial payments, pending transfers and wrong-network records, with exact decimal totals. Use it for a local exception review before updating your books. No wallet sync, automatic matching, FX, refund processing, tax accounting or independent finality checks. Retrieve reconcile with fetch or read its example resource to obtain exact inputs. Parameters are processed remotely without application persistence.
| Name | Required | Description | Default |
|---|---|---|---|
| invoices | Yes | Invoices | |
| transfers | Yes | Transfers |
| Name | Required | Description |
|---|---|---|
| report | Yes | |
| toolId | Yes | |
| version | Yes | |
| citation | Yes | |
| revision | Yes | |
| processing | Yes | |
| limitations | Yes | |
| evidenceStatus | Yes | |
| officialReferences | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds meaningful behavior: parameters are processed remotely without application persistence, there are no independent finality checks, and it separates records by state. These details go beyond the schema and 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?
Three dense sentences with zero filler. The core comparison is front-loaded, followed by usage guidance, exclusions, and input retrieval hints. Every sentence earns its place.
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 rich schema (100% parameter description, output schema, no nested objects) and strong annotations, the description covers the essential purpose, usage, and behavioral constraints. The phrase 'Retrieve reconcile with fetch or read its example resource to obtain exact inputs' is slightly cryptic but not a blocker. An agent can perform a local exception review with this definition.
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 100% and both arrays are fully documented, so the baseline is 3. The description's mention of 'exact decimal totals' and retrieving exact inputs via fetch/example resource adds minor context, but it doesn't elaborate on how invoices and transfers relate beyond what the schema already states. No need for more.
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 opens with a specific verb and resources: 'compares your declared invoices with recorded stablecoin transfers.' It further separates payments by category (partial, pending, wrong-network) and names exact decimal totals, giving a precise scope. The 'No wallet sync, automatic matching, FX...' line helps distinguish it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use it for a local exception review before updating your books' clearly states the intended scenario. The long exclusion list provides when-not-to-use signals, such as no FX or tax accounting, though no sibling tool is explicitly named as the alternative. This is good context but slightly implied rather than fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search this server’s public AI/Web3 tools and citation pages. English and Chinese names supported. Empty query lists the available worksheets.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds valuable behavioral context: bilingual (English and Chinese) name support, public scope, and the empty-query listing behavior. These details go beyond what annotations or schema provide without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two clean sentences with no filler. The primary action is front-loaded, and the supporting usage details are kept minimal and relevant.
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 single-parameter search tool with annotations and an output schema, the description is complete: it defines the search scope, supported query forms, and the empty-query behavior. No essential information for invoking the tool correctly is missing.
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 0%, so the description carries the burden of explaining the query parameter. It clarifies that queries are names, that English and Chinese are accepted, and that an empty query has special meaning. It does not fully specify matching behavior (e.g., exact vs partial), but it compensates well for the schema gap.
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 states a specific verb ('Search') and resource ('this server’s public AI/Web3 tools and citation pages'), making the tool’s function immediately clear. It is distinct from all sibling tools, which focus on checking permissions, comparing costs, or reading profiles rather than searching a corpus. The title and description align well.
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 clearly indicates when to use the tool: when searching for AI/Web3 tools or citation pages on this server. The note about empty query listing available worksheets provides a concrete usage scenario. It does not explicitly name alternatives or exclusion conditions, so it misses the top score.
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.
fetchreconcile_stablecoin_recordssearchAn owner's own Stripe: who owes you, today's money, draft invoices. Every write needs a confirm.
Screen crypto wallets vs OFAC SDN + threat intel; pre-payment checks, signed receipts; SAR drafts
Invoicing for businesses and AI agents: invoices, crypto payments, compliance, Invoice Passports.
Free, non-custodial MCP: validate bounded USDC/USDT payout plans, look up public transfers (read-only), reconcile payouts. Never holds funds or keys.
Add one secure layer between your agents and this server.