Temporary key-value drops and hand-off channels between agents, paid per call over x402. Reads free.
Scored across 5 tools
Each tool maps to a distinct operation: put writes, get reads immediately, list enumerates keys, delete removes, and wait long-polls for changes. The only potential overlap is get vs wait, but their descriptions clearly distinguish immediate read from blocking read.
All five tools use single lowercase verbs (delete, get, list, put, wait) in a consistent style. There is no mixing of conventions or casing.
Five tools is well-scoped for a key-value store with paid writes and long-poll reads. Each tool earns its place and there is no redundancy.
The core lifecycle is covered: create/update via put, read via get, enumerate via list, remove via delete, and change notification via wait. Minor gaps exist around box-level management (e.g., deleting or listing entire boxes), but agents can work around these using key-level operations.
Delete a key from a box immediately. Free, rate limited per address. Anyone holding the box id can do this; there is no undo.
| Name | Required | Description | Default |
|---|---|---|---|
| box | Yes | ||
| key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint and idempotentHint, and the description goes beyond them by disclosing that the effect is immediate, that access control is possession-of-box-id only, and that there is a rate limit. 'No undo' overlaps with destructiveHint but reinforces irreversibility; return behavior is left unstated.
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 short sentences, zero padding, with the action and its destructive consequence front-loaded before the operational notes.
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 two-parameter destructive call with no output schema, the description covers auth model, cost/rate limit, and irreversibility, which is most of what an agent needs. It omits what happens when the key does not exist (relevant given idempotentHint) and any hint about the response.
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 must carry parameter meaning; it does the minimum by calling `box` a box id (an identifier) and `key` the key being removed. It adds no format, path semantics, or constraint guidance beyond what is already visible in 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?
States a concrete verb and resource with scope: deleting a key from a box, immediately. That is unambiguous and clearly distinct from get/list/put siblings, though no sibling is named explicitly, so it stops short of the top band.
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 supplies a prerequisite ('anyone holding the box id can do this') and a warning ('no undo'), which implicitly frames when it is appropriate. It never says when to prefer put/overwrite over delete, or what to do instead, so 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.
Read a key. Free, no payment or identity needed, rate limited per address. Needs the box: a box_... id from put, or a channel name. Returns value null with found false if absent or expired. A box is a namespace of keys. Omit it on a paid call to use your own wallet's box (the call returns its id). Pass any long random string to share a box with another agent as a channel: whoever knows the string can read and write it, so short or guessable names are public. Pass a box_... id returned by an earlier call to address that box directly. The box id is the only credential: anyone holding it can read, list, delete and wait.
| Name | Required | Description | Default |
|---|---|---|---|
| box | Yes | ||
| key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Consistent with readOnlyHint=true, and it adds substantial context beyond the annotation: no payment or identity required, rate limiting per address, absence/expiry returning value null with found=false, and the critical disclosure that the box id is a bearer credential granting read, list, delete and wait. That security and cost profile is far more than the annotation conveys.
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 essential claim (read, free, rate limited, needs box) is front-loaded and every sentence carries information. The box explanation is, however, spread across four sentences with overlapping framing ("A box is a namespace", "Pass any long random string", "Pass a box_... id"), which could be tightened.
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 no output schema, the description still covers the return shape on the miss path (value null, found=false), the credential model, cost and rate limits, and all box addressing modes. An agent has everything needed to call this correctly and to reason about sharing risk.
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 full load and does so well for `box`: namespace semantics, three accepted forms, and the sharing/credential implications. `key` is only implied as the key name within a box with no format guidance beyond the schema's length bounds, leaving a small 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?
"Read a key" gives a specific verb and resource, and the surrounding text makes clear this is a single-key fetch scoped to a box namespace. It differentiates implicitly from put/delete/list/wait, but never explicitly names a sibling as the alternative, so it stops short of the top score.
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 spells out three concrete usage modes with their conditions: omit box on a paid call to use your own wallet's box, pass a long random string to share a box as a channel, and pass a box_... id to address a box directly. It also warns that short or guessable names are public, which is exactly the kind of when-not guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the keys in a box with their seq, size and expiry, newest first, without values. Free, rate limited per address. Anyone holding the box id can do this.
| Name | Required | Description | Default |
|---|---|---|---|
| box | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true, so the description carries real weight and delivers: free of charge, rate limited per address, no values returned, newest-first ordering, and an authorization rule (anyone with the box id). It omits pagination/result caps, which matters for a list operation on a keyspace, keeping it from a 5.
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 compact sentence group that front-loads the resource and return shape, then cost, then access rule. Every clause (ordering, no values, cost, auth) 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?
For a single-parameter read-only list with no output schema, the description covers return fields, ordering, cost, and access. The one meaningful gap is behavior when a box holds many keys — no mention of limits or pagination.
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% for the single 'box' parameter, so the description must compensate; it does partially by tying 'box' to a box id that acts as the access credential. It adds no format, source, or validation guidance for that id, leaving the compensation incomplete.
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?
Specific verb ('List') plus resource ('the keys in a box') and an explicit statement of what is returned (seq, size, expiry) and what is not (values). The 'without values' clause implicitly separates it from the sibling 'get', but no sibling is named outright, so it stops just short of a 5.
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 'without values' phrasing implies you follow up with 'get' for values, and 'Anyone holding the box id can do this' establishes the access precondition. There is no explicit when-to-use/when-not statement or named alternative, so 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.
Store a value under a key. Costs $0.002, charged only if the payment settles; a failed payment stores nothing. Values up to 64 KB, stored unencrypted, kept for ttl_seconds (default 3600, max 604800) then deleted. Overwrites an existing key and bumps its seq. The write becomes visible once the payment has settled. Returns the box id, which is also what free reads need. A box is a namespace of keys. Omit it on a paid call to use your own wallet's box (the call returns its id). Pass any long random string to share a box with another agent as a channel: whoever knows the string can read and write it, so short or guessable names are public. Pass a box_... id returned by an earlier call to address that box directly. The box id is the only credential: anyone holding it can read, list, delete and wait.
| Name | Required | Description | Default |
|---|---|---|---|
| box | No | ||
| key | Yes | ||
| value | Yes | ||
| ttl_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes far beyond the sole annotation (idempotentHint=true): states price ($0.002) and that it is charged only on settlement, that failed payments store nothing, 64 KB limit, unencrypted storage, TTL default 3600 / max 604800, overwrite-with-seq-bump, and settlement-gated visibility. It also warns that the box id is the sole credential granting read/list/delete/wait to anyone holding it — a security trait no annotation conveys.
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?
Front-loaded with the core write-and-price fact, then layered behaviors, and every sentence carries non-obvious information. It runs long and the credential warning about read/list/delete/wait partly restates the preceding 'whoever knows the string can read and write it' sentence, a minor redundancy.
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 exists, yet the description names the return value (the box id) and its downstream use in free reads. For a paid, credential-scoped write tool it covers cost, durability, expiry, visibility timing, and access risk — everything an agent needs before invoking it.
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 carries the load and largely does: 'box' is exhaustively explained across its three modes, 'value' gets size and encryption semantics, 'ttl_seconds' gets default and maximum. Gaps remain — it never states the ttl minimum of 60 or the key/value length bounds enforced by 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?
Opening sentence gives a specific verb and resource ('Store a value under a key') plus the cost model, which unambiguously separates it from the read-side siblings (get, list, wait) and mutating siblings (delete). The follow-on clauses about overwriting and box namespacing further pin down exactly what kind of write this is.
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 gives concrete selection rules for the 'box' parameter: omit it on a paid call to use your own wallet's box, pass a long random string to open a shared channel, or pass a box_... id to address an existing box. What's missing is any explicit routing advice against siblings (e.g., when to recover a value via get instead of re-putting), so a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Block until a key changes, then return it. Costs $0.001 per call whether or not anything arrives (it is a long-poll, not a subscription). Returns immediately if the key's seq is already greater than since; otherwise waits up to timeout_seconds (max 25) and returns value null with timed_out true. Pass the seq from the last value you saw to get only newer ones; since 0 returns whatever is there. This is how two agents sharing a box pass messages. A box is a namespace of keys. Omit it on a paid call to use your own wallet's box (the call returns its id). Pass any long random string to share a box with another agent as a channel: whoever knows the string can read and write it, so short or guessable names are public. Pass a box_... id returned by an earlier call to address that box directly. The box id is the only credential: anyone holding it can read, list, delete and wait.
| Name | Required | Description | Default |
|---|---|---|---|
| box | No | ||
| key | Yes | ||
| since | No | ||
| timeout_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond readOnlyHint=true: discloses a fixed $0.001 cost per call even when nothing arrives, the immediate-return condition, the 25s cap on blocking, and the return shape (value null with timed_out true). It also flags a real security trait -- the box id is the only credential and anyone holding it can read, list, delete and wait -- which an agent must know before passing a box value.
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?
Front-loaded with the core behavior and return conditions before the box/credential detail, and almost every sentence carries non-redundant information. It is dense and the box discussion runs long relative to the operational contract, but nothing is filler.
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 exists, yet the description documents the return contract (value plus timed_out, or an immediate value), the cost model, the timeout ceiling, and the credential/namespace model. An agent has everything needed to call it correctly and safely on the first attempt.
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 full burden and does: `key` is what is watched for changes, `since` is the prior seq (0 = whatever is there), `timeout_seconds` is the block budget capped at 25, and `box` has three distinct semantics depending on whether it is omitted, a random string, or a box_... id. Every parameter gains meaning not present in the bare 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?
States a specific verb and resource ('Block until a key changes, then return it') and immediately reframes it as a long-poll rather than a subscription, which separates it from the non-blocking siblings like get/list. The added line 'This is how two agents sharing a box pass messages' makes the intent unambiguous.
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?
Gives concrete selection logic -- pass the seq from the last value seen to get only newer ones, since 0 returns the current value, and the call returns immediately when seq is already ahead. It also spells out three box modes (omit, arbitrary random string for a shared channel, box_... id for a known box). It never explicitly contrasts with the sibling `get` ('use get if you don't want to block'), which keeps it below a 5.
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.
deletegetlistputwaitPaid tools for AI agents over x402: frontier-model chat per call, plus drops and hand-off channels.
Drop-and-claim storage, relay codes and fair-exchange chambers for AI agents. Pay per use in USDC.
Wake-ups, webhook inboxes, TTL memory, watches and human approval for agents. Paid per call.
Private, permanent encrypted storage for AI agents. Paid per call in USDC via x402.
Add one secure layer between your agents and this server.