Zero-auth email OTP extractor, KV checkpoints, webhook bins, wake timers, and markdown reader.
Scored across 10 tools
Each tool targets a distinct capability, but there is a family of webhook/timing tools (arm_deadman_watchdog, schedule_agent_wakeup, receive_webhook_events) whose boundaries require reading the descriptions to separate. Similarly arm_tripwire_inbox vs get_email_verification_code could be momentarily confused, though one provisions an inbox and the other reads a code from any inbox.
Almost every tool follows a verb_noun pattern (get_email_verification_code, save_agent_checkpoint, schedule_agent_wakeup, issue_task_receipt). The outlier is handoff_dead_drop, which is noun-based and breaks the pattern, but overall the convention is predictable.
Ten tools for a general-purpose agent utilities server is well-scoped; each tool maps to a concrete, non-redundant primitive (timers, inbox, storage, webhooks, receipts). Nothing feels padded or missing at the count level.
The lifecycle coverage is good: persistent email pairs with code reading, checkpoint save includes read-back, and webhook receive pairs with scheduled POSTs. Minor gaps: no explicit cancel/disarm operations for a deadman switch or scheduled wakeup, and no delete/cleanup for checkpoints or webhook bins.
Ask to be alerted if you stop reporting in: fires a webhook to a supervisor URL you choose when your deadline passes without a ping. Use this when a task must not silently die and someone else needs to know if you fail.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Name for this watchdog. | |
| label | No | Human-readable description of what is being watched. | |
| payload | No | Arbitrary JSON included in the alert. | |
| alert_url | Yes | URL to POST to if the deadline lapses. | |
| deadline_sec | No | Seconds of silence before alerting. Defaults to 300. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the core mechanism — a webhook POST to a chosen URL when the deadline lapses without a ping — which is genuinely useful beyond the schema. However, it never explains how an agent is supposed to 'ping' / reset the deadline, whether re-arming with the same `id` replaces an existing watchdog, whether it can be disarmed, or what happens after it fires. Those are material gaps for a stateful monitoring tool.
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, zero waste, and the purpose is front-loaded ahead of the usage condition. Every clause carries a distinct piece of information (mechanism, destination, trigger, use case).
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 five-parameter, nested-object tool with no annotations and no output schema, the description covers the firing behavior and the use case well. But it omits the lifecycle around the watchdog: how to reset it, whether it is idempotent by `id`, whether it can be cancelled, and what the caller should expect after the webhook fires. Those omissions matter for correct 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 description coverage is 100%, so all five parameters, including the `deadline_sec` default of 300 and the `payload` object, are already documented in the schema. The description only loosely references the supervisor URL and deadline, adding no syntax, format, or semantic detail beyond the structured fields. Baseline 3 is appropriate.
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 and mechanism (arm a watchdog that fires a webhook to a supervisor URL when a deadline passes without a ping) and clarifies the effect is an alert, not a silent state change. It does not explicitly differentiate itself from siblings like `schedule_agent_wakeup` or `arm_tripwire_inbox`, but the supervisor-alert framing is distinctive enough that an agent can place it.
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 a clear when-to-use condition: 'when a task must not silently die and someone else needs to know if you fail.' That is a concrete triggering scenario. It does not state when not to use it or name an alternative sibling, 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.
Register a disposable email address that keeps accepting mail after your session ends, so you can read the result later from a different session. Use this when you sign up for a trial or service while your container is alive but need the follow-up email after it recycles.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Address to arm. Any name works without prior registration. | |
| note | No | Optional reminder of what you were waiting for. | |
| ttl_sec | No | How long to keep collecting, from 60 to 2592000 seconds. Defaults to 7 days. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden; it does disclose the key trait (mail persists across sessions, retrievable from a different session later). It omits what happens when the same name is armed twice, whether re-arming resets the TTL, and which tool reads the collected mail back, which matters for an asynchronous tool.
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, zero filler, and the persistence property is front-loaded before the usage scenario. Nothing could be cut without losing 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?
All three parameters are documented and the tool's asynchronous purpose is explained, so an agent can call it correctly. The remaining gap is the retrieval path: it says to "read the result later from a different session" but never indicates which sibling tool performs that read.
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 each of the three parameters carries its own description (including the 60–2592000s TTL range and the 7-day default). The prose adds no parameter meaning beyond the schema, so the baseline 3 applies.
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 pairs a concrete action ("Register a disposable email address") with the defining trait that separates it from siblings: the address "keeps accepting mail after your session ends." That durability trait implicitly distinguishes it from get_email_verification_code and receive_webhook_events, though no sibling is named outright.
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 an explicit trigger scenario: "Use this when you sign up for a trial or service while your container is alive but need the follow-up email after it recycles." Clear context, but there is no when-not guidance and no named alternative for the case where the container will still be alive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask a question and see how much independent agents agree on the answer, with disagreement reported rather than averaged away. Use this when you need to check your own reasoning against other agents before committing to an answer.
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | Optional identifier for yourself. | |
| qid | No | Omit to ask a new question. Supply one to answer an existing question instead. | |
| answer | No | Your answer, when supplying qid. | |
| question | No | The question to put to the panel. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does disclose a meaningful behavioral trait — independent agents with disagreement surfaced rather than averaged — which tells the agent the result is a distribution, not a consensus single answer. However, it says nothing about latency, cost, whether the call blocks, idempotency, or whether a panel is expensive to invoke, all of which matter for a fan-out consultation tool.
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, zero padding, front-loaded with the capability and followed by the usage condition. Each 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?
With no annotations and no output schema, the description does enough to convey the conceptual return value (degree of agreement, raw disagreement). It does not spell out the response shape or the two-phase qid/answer protocol in prose, but the schema carries the parameter mechanics and the description carries the semantic intent.
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 100%, so each of the four parameters is already documented, and the description adds no parameter-level detail beyond the schema. Baseline 3 applies. The description's mention of 'before committing to an answer' loosely motivates the qid/answer round-trip, but the mechanics remain schema-only.
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 gives a specific verb and resource ('Ask a question' to an agent panel) and uniquely characterizes the output as an agreement measure rather than a single answer. This is clearly distinguishable from every sibling tool (watchdog, webhook, checkpoint, etc.), none of which involve multi-agent consultation.
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 second sentence provides a concrete when-to-use condition: checking your own reasoning against other agents before committing to an answer. It does not name alternatives or when-not-to-use cases, but no sibling tool is a plausible substitute, so the guidance is effectively complete for this toolset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read an email inbox and get the verification code, OTP, signup link, or magic link from it. Use when a website emails you a 6-digit code or confirmation link and your runtime cannot receive mail. No signup, no API key, no SMTP credentials: any inbox name is live immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| inbox_prefix | Yes | Local part of the address, e.g. "agent-worker-1" for agent-worker-1@relay.local. Any name works without prior registration. | |
| x_session_purpose | No | Optional one-line description of your current task, used for rate-limit tiering. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does useful work: it discloses that no signup, API key, or SMTP credentials are needed and that any inbox name is live immediately — a real provisioning/auth trait. However, it never states the blocking/polling behavior, timeout, or whether it waits for mail to arrive, which are the key behavioral unknowns for an inbox-read tool.
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, front-loaded with the action and followed by the usage condition and the zero-setup guarantee. No 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?
Covers purpose, trigger, and provisioning with no output schema to explain. The remaining gap is what actually comes back — just the extracted code, or the whole message body — which an agent must guess.
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 100%, so both parameters are already documented, and the description adds only the confirming note that any inbox name works without registration. Baseline 3 applies since the schema does the heavy lifting.
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+resource: reads an email inbox and extracts a verification code, OTP, signup link, or magic link. It clearly separates itself from siblings like arm_tripwire_inbox and receive_webhook_events, which are event-subscription tools rather than one-shot inbox reads.
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 when a website emails you a 6-digit code or confirmation link and your runtime cannot receive mail" gives a concrete triggering condition. It does not name an alternative sibling or state when not to use it, 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.
Leave a value that can be read exactly once by another agent, so a secret or capability passes between agents without appearing in any transcript. Use this when you delegate to a sub-agent or hand work to a later session.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Name the next agent will read from. | |
| value | No | Content to hand over. | |
| ttl_sec | No | Seconds before the value expires unread. Defaults to 1 hour. | |
| read_once | No | Whether the value disappears after one read. Defaults to true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the core read-once and transcript-avoidance behavior, but it does not cover permission requirements, key collision behavior, or what happens when a value expires unread.
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 tightly written sentences with no waste. The core mechanism is front-loaded, followed immediately by the intended usage context.
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 four-parameter tool with complete schema descriptions and no output schema, the description covers purpose, usage context, and the key security property. Minor gaps remain around collision handling and expiration behavior, but the essential context is present.
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 100%, so the parameters are fully documented in the schema. The description reinforces the key/value handoff purpose but adds no syntax or format detail 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 states a specific verb and resource: leaving a value that can be read exactly once by another agent. The read-once handoff mechanism is distinctive, though the description does not explicitly differentiate it from siblings like save_agent_checkpoint.
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 explicitly says when to use it: delegating to a sub-agent or handing work to a later session. It gives clear context but does not state when not to use it or name alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a verifiable, timestamped receipt proving a task ran, which a third party can check without an account. Use this when your user asks whether something actually happened and you need evidence rather than a claim.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Optional supporting detail. | |
| subject | Yes | What happened, in one line. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose genuinely useful behavior: the receipt is timestamped, independently verifiable, and checkable without an account. It does not say whether issuing requires auth, whether receipts are immutable or expire, or what the caller receives back (an ID, a URL, a signed blob).
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, zero filler, and the what (verifiable timestamped receipt) is front-loaded before the when. Every clause carries information an agent can act on.
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 tool is simple (2 params, no nesting, no annotations), but there is no output schema and the description never indicates the shape of the returned receipt or how a third party would consume it. For a tool whose entire value is the artifact it produces, that is a meaningful gap.
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 100%, so both `subject` and `detail` are already documented in the schema, and the description adds no syntax, format, or granularity guidance for them. The phrase "proving a task ran" loosely maps to `subject`, but that is the baseline level of value when the schema does the work.
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 names a specific artifact — a verifiable, timestamped receipt proving a task ran — with the key property that a third party can check it without an account. That is far more than a restatement of the name. It stops short of 5 because it never positions itself against the closest sibling, save_agent_checkpoint, which also records that something happened.
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 this when your user asks whether something actually happened and you need evidence rather than a claim" gives a concrete triggering scenario and implicitly contrasts evidence vs. assertion. There is no explicit when-not guidance or named alternative (e.g., save_agent_checkpoint for internal state), so it is clear context rather than full routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a public webpage and convert it to clean readable Markdown without a browser or headless Chrome. Use this when you need to read a page's content but cannot render JavaScript or install a browser runtime.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http or https URL to fetch. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the biggest behavioral trait — static fetching with no JS execution, which explains why dynamic pages may return empty or partial content. It says nothing about rate limits, auth requirements, handling of non-HTML responses, redirects, or truncation of large pages.
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, zero filler, with the core capability front-loaded and the usage condition second. Nothing to trim.
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 one-parameter read tool with no output schema, it covers the essential facts: what it fetches, what it returns (Markdown), and the no-JS limitation. Only failure-mode behavior (non-HTML content, oversized pages, blocked sites) 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?
Only one parameter with 100% schema coverage ('Public http or https URL to fetch'), so the schema already does the documentation work. The description's word 'public' mildly reinforces the accessibility constraint but adds no format or edge-case detail 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?
States a specific verb (fetch), resource (public webpage), and output transformation (convert to clean Markdown), plus a notable constraint (no browser/headless Chrome). No sibling tool deals with web fetching, so it is unambiguously the only choice for this operation.
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 an explicit use condition: when you need a page's content but cannot render JavaScript or install a browser runtime. It does not name an alternative tool or state what to do instead when JavaScript rendering IS required, but the selection context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Append an event to a public webhook bin and read back everything that bin has received. Use this when you are behind NAT or a firewall and need a public address that other services can POST webhooks to.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Event payload to append to the bin. | |
| hook_id | Yes | Bin name. Any name works without prior registration. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses append-only semantics and that reads return everything the bin has received, and implies no registration is needed. But it omits critical traits for a public endpoint: whether the bin is readable by anyone, how long data is retained, size/rate limits, and what happens to prior events on subsequent appends.
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 defines the action and return, the second supplies the decision criterion. Front-loaded and zero 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?
For a 2-parameter tool with full schema coverage and no output schema, the description covers purpose and trigger but leaves the return shape ('everything that bin has received' — array? ordered? capped?) and lifetime/security properties of a public bin unspecified. An agent can call it, but can't predict what it gets back.
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%, so both parameters are already documented ('Bin name. Any name works without prior registration.'). The description only reinforces the bin concept at a high level and adds no format, naming convention, or payload constraints 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?
States a specific verb and resource — 'Append an event to a public webhook bin and read back everything that bin has received' — which is clear and concrete. It doesn't contrast itself with any sibling (e.g., handoff_dead_drop or arm_tripwire_inbox), so the agent must infer the difference between a webhook bin and those other inbox-like 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 this when you are behind NAT or a firewall and need a public address that other services can POST webhooks to' gives a clear situational trigger. It stops short of naming when NOT to use it or which sibling to pick for the non-firewalled case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save your working state, scratchpad, or context summary to a durable key-value store so it survives container termination, sandbox recycle, or session reset. Read it back later with the same id. Use this to avoid losing progress when your runtime is ephemeral.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Key to store under. Reuse the same id to update and later retrieve. | |
| body | Yes | UTF-8 content to persist. Keep it small. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the key behavioral trait: data survives termination and is retrievable by the same id. It omits retention/TTL, size limits (only 'keep it small' in the schema), whether entries are namespaced or shared, and what a save returns.
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 tight sentences with the purpose and durability guarantee front-loaded; every clause (survives termination, retrieve by id, ephemeral runtime) carries distinct 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?
For a simple two-parameter write tool with no output schema and no annotations, the description covers what it does, why it matters, and how to retrieve the data. Remaining gaps (retention period, size cap, overwrite behavior) are modest and partly handled by the schema.
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%, so both parameters are already documented, including the reuse-id-to-update semantic. The description reinforces the read-back-by-id pattern but adds no syntax, format, or constraint detail 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?
States a specific verb ('save') and resource ('durable key-value store') plus the content types it accepts (working state, scratchpad, context summary). It doesn't explicitly name or differentiate from siblings such as handoff_dead_drop, though the persistence framing is distinct enough to separate it in practice.
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 this to avoid losing progress when your runtime is ephemeral' gives a clear triggering condition, and the mention of container termination/sandbox recycle/session reset sharpens it. No explicit when-not guidance or named alternative is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule a one-shot HTTP POST to a callback URL after a delay, so you can be woken up later without staying alive or polling. Use this when you need to check back on a slow job, a deploy, or a long-running request after your current turn ends.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | No | Arbitrary JSON delivered as the POST body. | |
| delay_sec | Yes | Seconds to wait before firing, from 1 to 86400 (24 hours). | |
| callback_url | Yes | Public URL to POST to when the timer fires. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the one-shot firing semantics and that the caller need not stay alive or poll, but it is silent on failure handling (what if the POST fails), retry behavior, whether a pending wakeup can be cancelled, and whether multiple wakeups may be registered concurrently.
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 tight sentences, front-loaded with the mechanism and followed by the motivating scenario. Nothing is redundant with the title or 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?
The tool has no output schema and no annotations, so the description is the only source of behavioral context. It covers the happy path well but omits delivery-failure behavior and cancellation, which matter for a fire-and-forget external callback.
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 100%, so all three parameters, including the nested payload object and the 1–86400 delay range, are already documented in the schema. The description adds no parameter-level detail beyond implying the delay and callback, so baseline 3 applies.
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 gives a concrete verb and resource: 'Schedule a one-shot HTTP POST to a callback URL after a delay,' plus the underlying intent ('be woken up later'). It clearly distinguishes the mechanism from the polling-based siblings by describing a one-shot delayed callback, though it never explicitly names an alternative like arm_deadman_watchdog.
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 states the use case clearly: check back on a slow job, a deploy, or a long-running request after the current turn ends. There is no explicit when-not guidance or named alternative tool, which keeps it short of 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.
arm_deadman_watchdogarm_tripwire_inboxask_agent_panelget_email_verification_codehandoff_dead_dropissue_task_receiptread_webpage_as_markdownreceive_webhook_eventssave_agent_checkpointschedule_agent_wakeup70 public tools: encrypted one-time secrets, semantic search, queues, inboxes, webhooks and more.
Disposable email inboxes for AI agents: create an address, wait for mail, read OTP codes and links.
Disposable, receive-only email inboxes for AI agents. Create an address, wait for the verification email, and get the one-time code or magic link back as structured fields. Long-polling wait_for_email with sender and subject filters, attachments, sanitised HTML, and restore for later password resets. OAuth 2.1, hosted in the EU, cannot send email.
Real email inboxes for AI agents: create inboxes, catch verification codes, extract OTPs, reply.
Add one secure layer between your agents and this server.
