RunLater

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and does so well: it discloses the monotonic forward-only semantic, the no-op behavior for stale seqs, and the error condition for out-of-range acks. The remaining gap is that it never says whose inbox is being acked (per-agent vs. shared) or whether the ack is durable across sessions, which matters for a mutation with zero annotation coverage.

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, each carrying distinct information — effect, monotonic rule, error/precondition — with the primary effect front-loaded and no redundant restatement of the name.

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 mutation with no output schema, the description covers effect, ordering, and failure modes adequately. It leaves out the scope of the inbox and whether acking is idempotent across repeated calls with the same seq, but nothing blocks a correct call.

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 the baseline is 3, but the description genuinely adds meaning beyond the schema's 'seq of the last event you handled' by clarifying inclusivity ('up to and including'), monotonicity, and the error case when up_to exceeds the newest event.

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 ('mark inbox events ... as read') with the inclusive boundary spelled out, and ties the effect to the observable outcome ('so read_inbox stops returning them'), which distinguishes it from the read_inbox sibling.

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 explicit preconditions and exclusions: only ack events you have read, an older seq is a no-op, and an up_to past the newest event is an error. This is a full when/when-not contract rather than a hint.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden; it does disclose a genuinely useful trait — a mid-delivery task is only canceled when the attempt ends, and a successful attempt wins. It does not say whether cancellation is irreversible, whether it is idempotent, what happens on an already-delivered task, or what the call 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 short sentences, zero filler, with the core eligibility constraint front-loaded before the edge case. Every clause carries information an agent needs.

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, non-annotated mutation tool with no output schema, the description covers the key precondition and the ambiguous mid-flight case. It could be stronger by noting irreversibility or the expected response, but nothing essential for correct invocation 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 and schema description coverage is 100%, with the schema already stating the task id comes from schedule_http and enforcing a pattern. The description adds no meaning about task_id beyond the schema, so the baseline of 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?

States a specific verb and resource ('Cancel a task') plus the scoping precondition ('that has not been delivered yet'), which is far more informative than the bare name. It does not explicitly differentiate itself from related siblings such as redrive_task or get_task, but the resource and operation are 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 clear context for use: only tasks that have not yet been delivered, and explains the mid-delivery case. There are no explicit exclusions or named alternatives (e.g. when to redrive instead of cancel), so it stops short of full when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so unusually well: each run costs delivery attempts, failures trigger a signed alert to alert_url (and again on recovery), runs that cannot start never report but flip the cron to failing, calling with the same name replaces the existing cron, and there is a hard cap of 10 crons. These are non-obvious operational consequences an agent could not get from the schema.

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?

Purpose is front-loaded in the first sentence and every subsequent block addresses a distinct concern (cost, dead man's switch, reporting, replacement, quota). It is dense with stacked parentheticals and cross-references to set_wake and schedule_http, which slows parsing, but little of it is fillers.

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 an 11-parameter tool with nested header objects, no annotations and no output schema, the description covers cost, failure, quotas and update semantics thoroughly. The notable remaining gap is the return value: nothing says what create_cron hands back (a cron object, an id, or just confirmation), which matters when there is no output 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 91%, so the schema already explains most parameters. The description still adds real meaning: the schedule must have a single minute value (at most hourly) with a worked example, name reuse means replacement rather than an error, and report/alert_url/callback_url are tied together into a coherent reporting story.

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?

Opens with a specific verb+resource and scope: 'Run an HTTP request on a recurring schedule', then pins the schedule format to a 5-field UTC cron with a single minute value. It distinguishes itself from the one-off sibling by referencing schedule_http only for shared semantics ('as schedule_http's capture', 'Same rules as schedule_http'), so an agent can tell this is the recurring variant.

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 clear conditional guidance: use report: "failures" for a quiet healthy cron, set alert_url (or "inbox") to catch crons that cannot start, and pass callback_url+capture to see run results. It stops short of an explicit 'use schedule_http for a single request instead' routing statement, so the when-not is only inferable from the recurring framing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does so richly: the URL is shown once and cannot be recovered, re-calling retires the old URL, verify failures yield 401 and events show verified: false, unverified hooks are writable by anyone, sender retries with delivery ids are deduped, and prompt-injection risk is flagged. It also discloses rate/cost limits (60 req/min, per-project and per-hook daily caps, filtered requests free). Minor gap: it doesn't describe the response payload shape or status code for success beyond the 202 mention in the accept text.

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?

Purpose and the one-time-URL warning are front-loaded, and nearly every sentence carries a distinct constraint (dedup, limits, filtering, security). It is dense and long, with several independent facts chained together, which slightly raises reading load, but little is filler relative to the tool's complexity.

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 tool with four parameters, nested objects, no output schema and no annotations, the description covers creation, verification, filtering, limits, lifecycle, and security guidance. An agent has everything needed to call it correctly and understand consequences; nothing material 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 100% so a baseline 3 applies, but the description adds real meaning beyond the schema: verify's security role and the 401/verified:false consequence, accept's filtering behavior ('filtered ones cost nothing', same 202 but nothing written), and keep_headers' implications. It reinforces rather than duplicates the schema's documented semantics.

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 opening sentence states a specific verb and resource ('Get a URL that receives webhooks for you') and frames scope with concrete examples (GitHub, Stripe, CI). It explicitly distinguishes itself from siblings like update_hook, list_hooks and read_inbox, so an agent can route correctly without opening a 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 names the exact alternative for the related but different operation ('To change verify, accept or keep_headers later without a new URL, use update_hook'), explains idempotency semantics of calling again with the same name, and states a hard cap of 20 hooks. When-to-use and when-to-use-something-else are both explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are supplied, so the description carries the full behavioral burden and handles the most important traits: idempotent re-invocation with no trial reset, the trial quota (100 attempts / 7 days), and the security-relevant return of signing_secret for verifying RunLater-Signature. It omits auth requirements, failure modes, and whether the project can ever be reset or deleted, which keeps it below 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?

Three short sentences, each with a distinct job: what is created and its trial terms, the call-once/idempotency rule, and the returned secret's purpose. The critical idempotency warning is front-loaded rather than buried. Minor density in the parenthetical trial figures, but nothing is wasted.

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 zero-parameter provisioning tool with no output schema, the description covers what an agent needs: what gets created, the trial limits, the idempotency contract, and the one returned field that matters downstream. It lacks detail on error conditions or whether other return fields exist, but no material gap blocks a correct call.

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 tool takes zero parameters, so there is no parameter semantics to explain and the baseline is 4. The description spends its space on behavior instead, which is the right allocation.

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 verb and resource plus scope: 'Create this agent's RunLater project with a free trial (100 delivery attempts, 7 days).' An agent can immediately tell this provisions a project rather than reading one. It stops short of naming the sibling get_project as the read counterpart, so the differentiation is implied by the verb rather than 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?

'Call once before scheduling' gives a clear ordering constraint and trigger condition, and 'calling again returns the same project and never resets the trial' defers the redundant-call case. It does not point to get_project when an agent only wants to inspect an existing project, which is the one obvious alternative left unaddressed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 one genuinely important trait: a run already started still finishes. It does not say whether no further runs are scheduled immediately, whether deletion is reversible, or whether permissions are required, leaving the mutation profile partly opaque.

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 terse sentences with zero filler; the core action is front-loaded and the caveat follows immediately. Nothing could be removed 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?

For a one-parameter deletion tool with no annotations and no output schema, the description covers the action and the key side effect on running jobs. The remaining gap is minor: recoverability and immediate scheduling effects are unstated, but an agent can call this correctly from what is given.

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 the single required field already has a description with an example, so the schema does all the work. The description adds nothing about the identifier beyond what is structured, which is the expected baseline for one well-documented parameter.

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?

"Stop and remove a cron" names a specific verb pair and the exact resource, which cleanly distinguishes it from siblings like cancel_task and delete_secret. It stops short of explicitly contrasting itself with cancel_task, whose name could tempt an agent to cancel a running job instead of deleting the schedule.

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?

Usage is only implied by the verb: an agent can infer this is for permanent removal of a schedule. There is no explicit when-to-use/when-not-to-use guidance and no mention of cancel_task as the alternative for stopping an in-flight run, which is the most plausible confusion in this sibling set.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry behavioral disclosure. It usefully states that the deleted hook's URL returns 404 and prior events remain in the inbox, but it omits permissions, irreversibility or confirmation expectations, and error behavior for a missing hook.

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 short sentences, front-loaded with the action and followed immediately by the observable consequences. No filler or redundant restatement.

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 one-parameter delete operation with no output schema, the description covers the essential post-deletion effects an agent needs. It could be slightly more complete by stating prerequisites or behavior when the hook does not exist, but it is largely sufficient.

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 is one required 'name' parameter and schema description coverage is 100%, so the schema already defines the parameter. The description adds no additional semantics about the hook name, such as its source, format, or whether it must already exist.

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 the specific action and resource ('Delete a hook') and is unambiguously distinct from sibling operations such as create_hook, update_hook, and list_hooks. There is no ambiguity about what the tool does.

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 verb implies the tool is used to remove a hook, but the description gives no explicit when-to-use or when-not guidance and never mentions alternatives such as update_hook. It provides consequences, not routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations supplied, the description carries the full burden and does add real behavioral disclosure: deleting a secret breaks dependent scheduled work, that failure does not consume an attempt, and it surfaces as the specific error code secret_missing. It still omits irreversibility, permission requirements, and behavior when the name does not exist, so it falls short of complete.

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 short sentences with the action front-loaded and the consequence immediately following; nothing is wasted. The clause 'fails without using an attempt when it next comes due' is slightly dense and takes a reread 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?

For a one-parameter destructive tool with no output schema, the definition covers the essential downstream side effect and its error code. Missing are confirmation of irreversibility and behavior on a nonexistent secret, which an agent invoking a delete would reasonably want.

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% for the single 'name' parameter, including a format pattern and a concrete example, so the schema already does the documenting. The description adds no further meaning about the name argument beyond what the schema states.

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+resource ('Delete a secret') that is unambiguous and clearly distinct from the sibling write tool set_secret and the read tool list_secrets. It does not explicitly name those siblings, which keeps it 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?

Usage is implied by the imperative 'Delete a secret', and the second sentence usefully warns that work still referencing the secret will fail on its next due date. However, there is no explicit when-to-use vs. when-not guidance, and nothing about verifying references before deleting or preferring another sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations supplied, the description carries the full behavioral burden and does add real value by disclosing in-flight semantics: an already-sending wake completes, while an unsent one is canceled. It does not say what happens when no wake is configured (idempotency or error) or whether the operation requires authorization, leaving a modest gap.

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 short sentences, front-loaded with the core action and followed by the one non-obvious behavioral detail. No filler or restatement of the tool name.

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 zero-parameter mutation with no annotations and no output schema, the description covers the essentials: what changes and how in-flight work is handled. The remaining gap is the response/return behavior and the no-op case, which an agent would need to know to handle results correctly.

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 tool takes zero parameters, so there is no parameter meaning for the description to add; the baseline for a parameterless tool applies. The empty schema with additionalProperties=false is self-explanatory.

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 ('Stop waking: RunLater no longer calls the wake URL'), which is concrete enough for an agent to distinguish it from the counterpart set_wake in the sibling list. It stops short of naming set_wake explicitly as the inverse operation, so it is clear but not fully sibling-differentiated.

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?

Usage is only implied: an agent can infer this is the tool for disabling an existing wake schedule. There is no explicit statement of when to prefer it over adjacent tools like cancel_task or delete_cron, and no mention of prerequisites such as whether a wake must exist first.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 shape of the response, including the three health states and that a failing health comes with a reason, which is real behavioral value. It omits error behavior for a missing cron, any permission requirements, and does not explicitly label the operation read-only beyond the word "Show".

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 front-loaded sentence, no filler, and the most decision-relevant information (what a cron is and what the response reveals) comes first. Every clause carries content.

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?

Since there is no output schema, describing the returned fields is essential and the description does it well, including the health enum semantics. The remaining gap is the not-found/error path and confirmation that the call has no side effects.

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 the single name parameter is documented in the schema with a pattern and an example ("daily-backup"). The description adds no meaning beyond that, 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?

"Show a cron" gives a specific verb and resource, and the enumeration of returned fields (schedule, next run, health, last run task, last success) makes clear this is a single-record detail lookup. It is distinguishable from the plural list_crons by the singular framing, though it never names that sibling explicitly.

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?

Usage is only implied: an agent can infer this is for inspecting one known cron, while list_crons handles enumeration. There is no explicit when-to-use statement, no guidance on what happens if the name is unknown, and no named alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are supplied, yet the description fully explains the terms of operation: price and quantity, that leftover attempts carry over, a 12-month validity window, the 24-hour lifetime of payment_url vs the 7-day lifetime of mpp_url, and the fact that MPP payment credits attempts immediately while card payment requires the user to act. It also names the sibling (get_project) that confirms the result, which is the key post-call behavior an agent needs.

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?

Purpose and price are front-loaded in the first clause, followed by the terms, then a per-return-value breakdown with lifetimes and the action to take for each. Though it is longer than most, every sentence conveys decision-relevant information, including the concrete MPP command example, and there is 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?

For a zero-parameter tool with no output schema, the description compensates by documenting both possible return fields (payment_url and mpp_url), their lifetimes, and the follow-up check via get_project. An agent can pick the right payment path and know how to close the loop without inspecting anything else.

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 tool takes zero parameters, so parameter semantics carry no burden and the baseline of 4 applies. The description instead invests its detail in the return values, which is the useful place for a no-arg tool.

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 (get) and resource (a link) and states exactly what the link buys: 50,000 delivery attempts for $5.00 for this project. This is clearly distinct from every sibling tool (get_project, create_project, etc.) with no overlap in intent.

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 usage instructions: pass payment_url to your user, POST to mpp_url and pay the 402 challenge when MPP is available, and verify the outcome with get_project. What's missing is an explicit trigger condition (e.g. 'use when attempts run low or after an insufficient-attempts error') and any when-not-to-use guidance, so the agent still has to infer when to call it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full disclosure burden, and it does disclose the return payload's sensitive content (the signing secret) and interprets derived fields like inbox_unread and wake. It never states permissions needed, error behavior, or that the call is side-effect free, leaving some behavioral gaps for a no-annotation 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 verb and the returned-field list, then the session-start motivation. Every clause either names a returned field or routes the reader to the sibling that explains it; 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?

For a zero-parameter getter with no output schema, the description effectively serves as the return-value contract by naming each field. It is nearly complete, missing only notes on failure modes or freshness/caching of the reported state.

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 input schema has zero parameters at 100% coverage, so there is nothing to disambiguate; baseline for a 0-param tool is 4. The description correctly adds no parameter noise.

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?

"Show this agent's project" gives a specific verb plus resource, and the description enumerates exactly which fields come back (trial expiry, delivery attempts, signing secret, inbox_unread, wake). It implicitly separates itself from create_project and from the inbox/wake tools by pointing those field meanings at read_inbox and set_wake.

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?

"Calling it at the start of a session tells you whether anything finished while you were away" is an explicit, actionable when-to-use trigger with a stated purpose. There is no when-not guidance or naming of alternatives among the 20 siblings, so it stops short of the 5 tier.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are supplied, so the description carries the full behavioral burden. It usefully discloses returned data (status, per-attempt time, HTTP status or error), but does not state read-only safety, error behavior for unknown task IDs, rate limits, or whether delivery attempts are paginated or truncated.

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?

It is a single front-loaded sentence with zero wasted wording. The parenthetical efficiently clarifies what a delivery attempt contains.

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 one-parameter retrieval tool with no output schema, the description adequately explains the return contents. It is slightly incomplete around failure cases and pagination, but nothing critical is missing for typical 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 100%: the single task_id parameter is fully documented with its pattern and origin from schedule_http. The description adds no parameter meaning beyond what the schema already provides, so the baseline of 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 states a specific verb and resource ('Get a task') plus the returned scope ('status and every delivery attempt'), which is clear and actionable. It does not explicitly distinguish itself from siblings such as list_tasks or watch_http, so it falls 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?

Usage is only implied: retrieve details for a single task. The description gives no explicit when-to-use guidance, no exclusions, and no alternatives such as list_tasks for enumeration or redrive_task for retries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are supplied, so the description carries the full burden. "List" implies a read-only, non-destructive operation and it discloses the returned fields (health, next run), but it says nothing about pagination, result ordering, or whether crons from other projects are excluded.

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?

A single front-loaded sentence with no filler; the resource and the returned information are stated immediately.

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 zero-parameter, read-only listing tool with no output schema, naming the scope and the key returned fields is close to sufficient. A brief note on what "health" means or how results are ordered would close the remaining 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?

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline for a no-param tool applies. No misleading parameter hints are present.

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 (List) and resource (crons), scoped to "this project's", and previews the payload (health, next run). It is distinguishable from the sibling get_cron by the plural/list framing, though it never names that sibling explicitly.

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?

There is no when-to-use guidance, no mention of when to prefer get_cron for a single cron, and no prerequisites or exclusions. The usage is only inferable from the verb itself.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses the exact shape of the returned data, distinguishes 'accept' from 'refused' with sample reason codes (signature_invalid, rate_limited), and notably declares 'Never their URLs or secrets,' which prevents an agent from attempting to extract sensitive values. It does not cover ordering, pagination/volume limits, or permission requirements.

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?

A single tight sentence front-loads the verb and resource, then packs the returned fields efficiently; the closing 'Never their URLs or secrets' lands as a clear constraint. The trailing ellipsis in the reason list ('signature_invalid, rate_limited, …') is slightly loose but signals that reasons are an open set.

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?

There is no output schema, so the description must convey return content, and it does so compactly and specifically, including the sensitive-data exclusion. Gaps remain around result volume/ordering and what an agent should do if it actually needs a hook URL or secret, since no sibling appears to expose those.

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 tool takes zero parameters, so there is nothing beyond the schema to clarify and the baseline of 4 applies. The description's explanation of returned attributes is useful but belongs to behavioral disclosure rather than parameter meaning.

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 ('List this project's hooks') with clear scope ('this project's') and then enumerates what each entry reports: verification method, retention, last-received time, and accept/refuse counters. The create/update/delete_hook siblings are self-evidently different operations, but the description never explicitly contrasts with them or with list_secrets.

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?

Usage is only implied by the word 'List' and the project scoping; there is no explicit 'use this when...' statement or exclusion pointing to another tool. For a no-parameter read of a fixed resource this is largely unambiguous, but the description does not help an agent decide between this and, say, inspecting secrets or hooks for another project.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations supplied, the description carries the full burden and does useful work: it discloses project scoping and, critically, that secret values are never returned ('Never values'), which sets a hard expectation about the payload. It does not state required permissions or whether ordering/pagination applies, keeping it short of 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?

A single sentence with zero waste; the resource scope comes first and the security-critical 'Never values' caveat lands at the end where it is most visible.

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 zero-parameter read tool with no output schema, the description supplies the effective return shape (names, allowed hosts, set timestamps). Only minor gaps remain - permissions needed and any ordering or pagination 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?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. The enumerated return fields partially compensate for the absent output 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 ('List') and a precisely scoped resource ('this project's secrets'), and enumerates the returned fields (names, allowed hosts, set time). The read-only listing nature inherently separates it from set_secret and delete_secret, though it never names an alternative explicitly.

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?

Usage is implied by the verb - an agent would call this to inventory existing secrets before setting or deleting one - but the description gives no explicit when-to-use, when-not-to-use, or pointer to a sibling like get_project that may also surface secret metadata.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 two meaningful traits: results are ordered newest first and results are paginated. It omits permission requirements, whether archived or canceled tasks are included, and what 'this project' resolves to.

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 short sentences with the core behavior front-loaded and zero filler. The only flaw is that the concise second sentence introduces a misnamed parameter, so brevity costs accuracy.

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 4-parameter read tool with no annotations and no output schema, the definition covers purpose, ordering, and pagination but leaves the status/lane filters and the limit default (20, max 100) unexplained. Adequate but with clear gaps an agent would hit in practice.

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% (lane documented; limit, cursor, status not), so the description needs to compensate. Instead it refers to "next_cursor", a parameter name that does not exist in the schema (the parameter is "cursor"), creating a real risk of a malformed call, and it says nothing about lane, status, or limit.

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?

"List this project's tasks" gives a specific verb and resource, and "newest first" states the ordering. It does not explicitly contrast with the sibling get_task, but the list-vs-get distinction is inferable from the verbs.

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 explains the pagination workflow (pass the cursor from a previous page to continue), which is genuine when-to-use guidance. There is no guidance on when to use this versus get_task, or on how filters affect the result.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does so: reading does not mark events read, unread events are retained 30 days, 'dropped' counts events removed before being read, and output is oldest-first. It also warns that captured response bodies and hook requests are third-party data to be treated as data, never instructions — a non-obvious safety property not expressible in schema.

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?

It is front-loaded with the high-value framing ("Read what happened while you were away") and every sentence carries operational information. It is dense — a single long paragraph mixing purpose, payload shapes, acking workflow, retention, and a safety note — so a scan-and-skim agent may need to re-read, but there is little filler to cut.

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, so the description must explain return values, and it does: events are { seq, at_ms, event, ... } with per-type payload details, plus 'dropped' counts. Combined with the ack workflow and retention rules, an agent has everything needed to call this correctly and follow up with ack_inbox.

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 67%, so the schema documents `ack` and `after` but leaves `limit` with no description at all. The prose adds real meaning beyond the schema — the default is unread-only, `seq` is the cursor value, and acking advances the cursor — but never mentions `limit`'s role in bounding how many events are returned, so it does not fully compensate for the coverage 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 and resource — reading inbox events from tasks, watches, crons and hooks, oldest first — and enumerates the concrete event types (task.finished, cron.failing/recovered, hook.received). It explicitly contrasts with the sibling ack_inbox, so an agent can distinguish the two operations 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 gives an explicit use case ("read what happened while you were away"), states the default behavior (returns unread events), names the alternative (ack_inbox with the last seq) and the inline option (ack: true), and flags the retention window (30 days) and the `after` lookback window (7 days). When-to-use and when-to-use-the-other-tool are both covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry behavioral weight. It usefully discloses that the attempt counter is reset and that prior attempt history is preserved, which tells the agent the operation is non-lossy. It does not say what state the task enters, whether concurrent redrives are safe, or what permissions are required.

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 short sentences, no filler, and the core action plus its restart semantics are front-loaded before the preservation detail.

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 mutation tool with no output schema, the description covers the essential behavior an agent needs: what it does, that retries start fresh, and that history survives. Only the resulting task state and any preconditions remain implicit, a minor gap at this complexity level.

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 the only parameter, task_id, is already documented with a pattern and provenance ("returned by schedule_http"). The description adds no meaning about the parameter, 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?

"Retry a failed task from now, with a fresh set of attempts" states a specific verb (retry) and resource (task), plus two scoping details: the restart point ("from now") and the reset of attempt count. This clearly separates it from siblings like cancel_task and get_task, though it never names them.

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 phrase "a failed task" implies the precondition that the task must be in a failed state, and "from now" implies it won't rewind. Beyond that there is no explicit when-to-use or when-not-to-use guidance, and no alternative sibling is referenced for tasks that haven't failed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does: it discloses signing, the exact retry set (timeouts, 408, 425, 429, 5xx) with backoff bounded by max_attempts, attempt recording, the 7-day capture retention, and that a callback is itself a billable task costing one delivery attempt per try. These are non-obvious operational traits an agent could not infer from the schema.

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 action and timing modes, then layered options in descending importance. It is dense with nested quoted literals ('Pass callback_url: "inbox"'), which reads as slightly run-on, but virtually every clause carries 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 an 11-parameter mutation tool with no annotations and no output schema, the description covers timing, retry policy, result retrieval, and capture lifetime. It does explain what is returned ('the task') at a high level, though it does not describe the task object's fields, which get_task presumably surfaces.

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 82%, so the baseline is 3, but the description adds real meaning: worked delay examples ('90s', '15m', '24h', '7d'), the 7-day horizon, and the intent behind callback_url 'inbox', capture, and idempotency_key. The lane parameter and method defaults are left entirely to 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 ('Schedule an HTTP request'), plus the three timing modes (now, delay, run_at_ms) and the URL constraint. The scope is narrow enough that an agent can immediately tell this is a one-off scheduled send rather than a recurring watcher.

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 routes follow-up work to siblings: get_task to poll, callback_url to receive a POST, read_inbox for 'inbox' delivery, set_secret for header secrets. It never states when to prefer watch_http or create_cron instead, so the sibling differentiation is incomplete for a family that contains a near-neighbor like watch_http.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations supplied, the description carries the full burden and does so: encryption at rest, injection only at send time, host-allowlist enforcement that refuses non-allowed hosts, the value never being returned, best-effort redaction of echoed values (with an explicit caveat that other encodings are not caught), overwrite semantics including hosts, and a 50-secret quota. These are exactly the non-obvious behaviors an agent cannot infer from the schema.

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 purpose, then usage, then guarantees, then caveats — a sensible ordering with no filler sentences. It is dense and somewhat long, but nearly every clause conveys a distinct safety or lifecycle fact rather than restating the name.

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 three-parameter mutation tool with no annotations and no output schema, this covers everything an agent needs: how the secret is referenced later, where it may be sent, what happens on overwrite, what is visible in responses, and the quota. Nothing material is left for the caller to 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 coverage is 100%, so constraints like the name pattern and value length are already documented. The description still adds real meaning: the name becomes the {{secret:NAME}} token, allowed_hosts is enforced by refusal rather than merely recorded, and re-calling with an existing name replaces both value and hosts for future attempts.

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?

"Store a credential once and refer to it instead of pasting it into requests" gives a specific verb (store) and resource (a named credential) plus the mechanism that makes it useful. It immediately distinguishes the tool from siblings like list_secrets/delete_secret and from the request-making tools that consume the value.

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 names both the alternative it replaces (pasting the literal credential into requests) and the exact consumer tools where the reference is valid (schedule_http, create_cron, watch_http, set_wake), with a concrete header example. An agent knows when to reach for this and when a plain literal value would do.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so well: exact POST payload shape, signing, at-most-one-wake-per-debounce with burst collapsing, dropping wakes that would find nothing unread, one delivery attempt per wake, and auto-disable after 3 consecutive failures plus a wake.disabled inbox event. That discloses cost, failure, and state consequences an agent could not infer elsewhere.

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?

Purpose is front-loaded in the first sentence, and each subsequent clause adds operational detail rather than filler. Some sentences are densely stacked (the payload, signing, and read_inbox aside in one line), which slightly hurts scanability but not correctness.

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 three-parameter configuration tool with no annotations and no output schema, the description covers what is sent, when it fires, what suppresses it, cost, failure handling, and how to inspect or revert state. An agent has everything needed to invoke it correctly and to predict side effects.

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 structural meaning of url, headers, and debounce is already documented. The description still adds value by tying debounce to observable behavior (bursts start the agent once) and by naming headers such as Authorization as the mechanism for authenticating the wake. It restates the URL requirement rather than adding new constraints, which keeps it just short of a 5.

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?

Opens with a specific verb+resource framing: register a URL so RunLater starts an agent run when the inbox receives something, rather than on session open. It explicitly separates the role of set_wake (configure the hook) from read_inbox (read the events) and get_project (inspect state), so an agent can place it among siblings.

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 a clear usage context (use this instead of waiting for someone to open a session) and covers the reactivation case: after 3 consecutive failures it disables itself, and you must call set_wake again to re-enable. It also states that calling again replaces URL, headers, and debounce. It does not explicitly contrast with watch_http or schedule_http, which are the closest alternatives, so the alternatives story is incomplete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations supplied, the description carries the behavioral burden well: it discloses partial-update semantics ('fields left out stay as they are'), the destructive-ish effect of verify: null ('stops checking signatures'), the reset effect of accept: null, and the side effect of replacing the stored secret. It omits what the call returns and whether name itself is mutable, which leaves some gaps for a mutation tool with zero annotation coverage.

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?

Four short sentences, front-loaded with what changes, then what stays stable, then null/omission semantics, then a caveat about secret rotation. Nothing is repeated from the schema and every sentence 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 four-parameter mutation tool with no annotations and no output schema, the description covers the important behavioral surprises: preservation of URL/counts/delivery IDs, omission meaning no change, and null semantics. It could additionally state the response shape or that unknown fields are rejected, but an agent could invoke this correctly as written.

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?

Beyond the schema's own field docs, the description adds real meaning: null values have distinct semantics (accept null removes filtering, verify null disables signature checking), and passing verify silently replaces the stored secret. The required 'name' parameter's role as an immutable identifier is never clarified, which is the main remaining ambiguity.

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 resource ('Change a hook's verify, accept or keep_headers'), so the agent immediately knows this is a partial mutation of hook configuration rather than creating or deleting one. It does not explicitly name siblings like create_hook or delete_hook, but the mutability set is precise enough that confusion is unlikely.

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 clear usage context: use it when rotating the sender's secret, and it explains that the URL and delivery history stay stable so no sender-side change is needed. It does not state explicit exclusions (e.g. 'to create a hook use create_hook, to change the URL delete and recreate'), so the when-not guidance is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are supplied, and the description carries the full load admirably: it discloses the exact failure taxonomy (3 consecutive failures on 408/425/429/5xx/timeout/network, immediate termination on other 4xx or redirect), the attempt-consumption model (taken as it runs, not reserved), header deletion on completion, callback payload contents, and at-least-once delivery with dedupe on RunLater-Task-Id. This is behavior an agent could not infer from the schema alone.

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?

Long but dense—nearly every sentence delivers distinct information (failure rules, attempt accounting, lifecycle, on_match linkage). The lead sentence is front-loaded with purpose. A few clauses are tightly packed and could be split for readability, but there is minimal filler relative to the tool's complexity.

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 10-parameter, nested-object tool with no annotations and no output schema, the description covers the gaps that matter: termination conditions, attempt accounting, progress/cancellation path, callback result contents (matched value plus up to 16 KiB of last body), and on_match side effects. An agent has enough to invoke it correctly without external 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 coverage is already 90%, so the schema does most of the work, but the description adds genuine meaning: on_match is described as an ordinary task linked by watch.action_task_id and triggered_by whose attempt is reserved at watch creation, and `until` is characterized via the matching semantics. It stops short of adding detail for parameters like idempotency_key or the method enum, which 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?

Opens with a specific verb+resource framing ("Hand off waiting on a long-running job") and immediately defines the mechanism: polling a public https:// URL until the response matches `until`, the deadline passes, or 3 consecutive polls fail. This is clearly distinguishable from schedule_http (recurring scheduled request) and from get_task/cancel_task, so an agent can route to the right tool without opening the 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?

States the use case explicitly (offload waiting on a long-running job), then explains the key alternative branch: use on_match to act immediately without waiting for the agent's next turn, and notes that a timeout/failure/cancel sends nothing. It references related tools (get_task, cancel_task, schedule_http, set_secret) but does not give an explicit "use this instead of schedule_http when..." comparison or a clear when-not-to-use statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.