Free. Up to 50 checks at once (re-checked when due), as rows; format "csv" adds a reconciliation CSV.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | ||
| checkIds | Yes | ||
| requiredLevel | No | Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized; XRPL: unl_quorum). The answer then says whether it is releasable. |
Changes observed during successful MCP inspections.
Input schema / properties / requiredLevel / descriptionPrevious value: -"Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized). The answer then says whether it is releasable."New value: +"Proof level you need before releasing money (Base: tee_attested < zk_proven < resolved; Ethereum: finalized; XRPL: unl_quorum). The answer then says whether it is releasable."Input schema / properties / requiredLevel / enumPrevious value: -[
- "tee_attested",
- "zk_proven",
- "resolved",
- "finalized"
-]New value: +[
+ "tee_attested",
+ "zk_proven",
+ "resolved",
+ "finalized",
+ "unl_quorum"
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose real behavior: cost ('Free'), batch cap (50), and that checks are 're-checked when due', implying a possible side effect, plus the CSV reconciliation output. It omits auth requirements, rate limits, and what 're-checking' actually mutates, so context is partial.
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 dense clauses with zero filler; the cost and batch constraint are front-loaded. The telegraphic style is efficient, though 'Free.' as a fragment and terse phrasing border on cryptic.
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 annotations, no output schema, and 3 parameters at 33% coverage leave the description as the main information source, yet it omits what a verification is, auth needs, and the return shape beyond 'rows'. For a batch tool that may trigger re-checks, this is inadequate.
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 only 33% (requiredLevel is documented in-schema; checkIds and format are not). The description partially compensates by explaining that format "csv" adds a reconciliation CSV and that the count is capped at 50, but it says nothing about what checkIds represent or how requiredLevel interacts with the response.
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 conveys a batch retrieval of 'checks ... as rows' with a 50-item scope, and the name get_verifications anchors the resource. However, it never states plainly what is being retrieved (verification statuses/results) and does not differentiate itself from the singular sibling get_verification. Purpose is inferable but not explicit.
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?
'Free' and 'Up to 50 checks at once' imply this is the economical batch path, which hints at when to prefer it. But there is no explicit when-to-use statement and no routing to alternatives such as get_verification for a single item or verify_payments_batch. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.