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

No annotations are present, so the description is the sole source of behavioral context. It clearly implies a non-destructive check via 'See if ... arrived' and scopes it to callback types and a time window, but it does not explicitly state whether callbacks are consumed or whether this is a blocking vs. one-shot poll.

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 place the primary behavior first, then usage context and an alternative. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The existence of an output schema means return values do not need to be restated. The description gives workflow and alternative context, but the undeclared identifier semantics and low schema coverage leave a real gap for a 3-parameter tool.

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 webhook_token has a schema description, so the description must compensate. It indirectly documents since_minutes ('last N minutes') but gives no meaning to the nullable identifier filter, which remains ambiguous.

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 uses a specific verb ('See if') and resource ('SSRF, XSS, or canary callbacks'), while time-window scoping differentiates it from generic request/email waiters. This is a distinct purpose 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?

It explicitly instructs to use after the three generate_* tools and names wait_for_email as the correct alternative for website verification emails. This is concrete when-to-use guidance with an exclusion.

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 carries the transparency burden. It discloses that the tool creates a disposable inbox and returns token, URL, email, and DNS, and it outlines the intended workflow. It omits persistence/cleanup details, but the core creation and return behavior are clearly conveyed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: the first sentence defines the tool, the second states when to use it, and the third gives the downstream workflow. Every sentence earns its place, with no filler or redundant schema repetition.

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 creation tool with an output schema, the description provides complete operational context: purpose, trigger conditions, returned values, and recommended next steps. An agent can determine when to invoke create_webhook and how to proceed afterward without additional information.

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, so there is no parameter-level semantics for the description to add. The description contributes value by explaining the returned fields (token, url, email, dns), which satisfies the baseline for a parameterless 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 uses a specific verb ('Create') and resource ('disposable inbox'), and enumerates concrete capabilities: HTTP URL, temp email, and DNS. It clearly establishes that this is the default first step for sign-up/verification workflows, distinguishing it from more specialized 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?

The description explicitly lists when to use the tool: signing up, receiving verification/magic-link/password-reset emails, catching webhook callbacks, or getting a one-off URL. It also provides the recommended follow-on sequence (wait_for_email, follow_email_link/OTP), but it does not explicitly contrast it with create_webhook_with_config or state when not to use 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?

With no annotations, the description carries the full burden for behavioral disclosure. It conveys that the tool creates a webhook with customizable response behavior, but does not detail side effects, potential errors, or the impact of omitted parameters (e.g., defaults beyond the implied 200). It adds some context but not comprehensive transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, both front-loaded and relevant. The first sentence states the core function, the second provides usage guidance with an alternative. No filler or redundancies.

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 moderately complex with seven optional parameters and an output schema (not shown). The description covers the primary use case but does not explain default behavior when no config is given, interactions between parameters, or how expiry works. It suffices for choosing the tool but not for fully predicting behavior without further schema info.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain all seven parameters. It only names five (status, body, timeout, CORS, alias) and does not elaborate on units, constraints, or the remaining params (expiry, default_content_type). The mapping is shallow and leaves significant gaps in understanding the parameters' meanings and valid values.

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 clearly states the tool creates a webhook with custom status, body, timeout, CORS, or alias, and explicitly contrasts it with the simpler create_webhook for normal use cases. This distinguishes it from siblings and names the specific resources being configured.

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?

Provides explicit guidance: use this tool when the endpoint should mimic an API (e.g., 404, delay, JSON body) rather than a default 200, and directs users to create_webhook for a standard sign-up inbox. This is strong when/when-not guidance with a 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?

With no annotations provided, the description carries the full burden of disclosing behavioral traits. While 'Clear captured events' implies deletion, it does not mention that the action is irreversible, the full scope (all matching requests), or any confirmations/undo options. The description's 'reset an inbox' metaphor is helpful but insufficient for a destructive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exceptionally concise: two sentences that quickly convey the action and a primary use case. Every word earns its place with no fluff.

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?

Despite having an output schema and four parameters, the description lacks key details for a destructive operation: it does not state that the deletion is permanent, that it applies to all captured events for the webhook, or any safety mechanisms. The use-case sentence helps but is not enough to fully understand the tool's impact.

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 only documents 'webhook_token' (25% coverage). The description adds that clearing can be optionally filtered 'by date or search query', which partially explains the purpose of 'query', 'date_from', and 'date_to'. However, it does not specify the date format, query syntax, or how these parameters interact, leaving significant 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 clearly states the action ('Clear captured events on a webhook') and the optional scoping by date or search query, which makes the core purpose obvious. However, it does not explicitly differentiate from the sibling tool 'delete_request' (singular) or mention 'all', relying on the tool name to imply bulk deletion.

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 provides a clear use case: 'Use to reset an inbox before a new sign-up or test run.' This gives strong contextual guidance for when to invoke the tool, though it does not mention when not to use it or name alternatives.

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 carries the full burden of behavioral disclosure. It states the destructive action and target scope, but does not disclose whether deletion is permanent, whether webhook ownership is required, or any side effects or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single 13-word sentence, front-loaded with the verb and target, with no redundant or filler 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?

For a simple two-parameter delete tool with an output schema, the description is largely adequate, but it lacks usage boundaries and permanence/authorization details, leaving the agent to infer important operational 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?

The schema already describes webhook_token as a UUID from create_webhook. The description adds that request_id identifies the event to delete, but does not provide its format, where to obtain it, or any additional context to compensate for the undocumented request_id 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?

The description uses a specific verb 'Delete' and names the exact resource: 'one captured HTTP, email, or DNS event by request id.' This clearly distinguishes it from sibling tools like delete_webhook and delete_all_requests.

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 'one...by request id' implies the tool is for deleting a single captured event, which provides some usage context. However, it does not explicitly state when not to use it or name alternatives such as delete_all_requests for bulk deletion.

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 carries the burden of behavioral disclosure. It states the action is 'Permanently delete' and that it deletes 'every captured request/email', which conveys irreversibility and scope. However, it does not mention any permissions, side effects, or error conditions. The description adds some value beyond the schema but could be more explicit about the destructive nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded. The first sentence states the core action, and the second sentence provides usage context. No wasted words; every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no nested objects, output schema present), the description is fairly complete. It explains the destructive scope and usage context. It could mention that the action is irreversible, but the word 'Permanently' already implies that. The output schema exists, so return values need not be described.

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 schema description coverage is 100% (the only parameter, webhook_token, is described as 'Webhook UUID returned by create_webhook'). The description does not add additional parameter semantics beyond what the schema provides. Baseline 3 is appropriate since the schema already documents the parameter well.

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 clearly states the tool's purpose: 'Permanently delete a webhook and every captured request/email.' It uses a specific verb (delete) and resource (webhook), and distinguishes it from sibling tools like delete_request and delete_all_requests by specifying it deletes the webhook itself along with all captured data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: 'Use when the user is done with a temp inbox or wants to clean up.' It implies when to use this tool, but does not explicitly mention alternatives or when not to use it. However, the context is clear enough for an agent to select it appropriately.

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 carries full responsibility. While the tool appears to be a read-only data export (no side effects implied), the description does not explicitly state that it is non-destructive or mention any rate limits or permissions. It is adequate but could be more explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and to the point, with no unnecessary words. It efficiently conveys the tool's function and when to use it.

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 description mentions the output includes 'HTML and untruncated bodies' which gives some context, but it does not explain the limit parameter or how pagination or data volume is handled. Since an output schema exists (as indicated), the return format need not be detailed, but the missing limit explanation leaves a slight gap in completeness.

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 webhook_token parameter is well described as 'Webhook UUID returned by create_webhook', but the limit parameter has no description in the schema nor in the tool description. With only one of two parameters documented, the schema coverage is low, and the description does not compensate.

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 clearly states the tool's purpose: 'Full dump of captured HTTP/email/DNS events, including HTML and untruncated bodies.' It also distinguishes itself from siblings with the explicit note 'Use this when list/wait tools omitted HTML or truncated a body.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool versus alternatives: 'Use this when list/wait tools omitted HTML or truncated a body.' This directly addresses the decision point among the sibling tools.

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 bear the burden of explaining behavior. It mentions defaulting to the latest event and the relationship with wait_for_email, but it does not clarify the roles of request_id and filter_domain, nor does it address potential side effects or error conditions. Thus, behavior is only partially transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively brief—four sentences—and conveys essential usage information without excessive verbosity. However, the sentence about wait_for_email already extracting links could be seen as slightly redundant, but it does help distinguish the tool, so it is not 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?

The description provides enough context for when to use the tool and mentions the default behavior, but it omits explanations for two parameters and does not describe the output format. Given that an output schema exists, the lack of return-value detail is acceptable, but the incomplete parameter context reduces completeness.

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 schema has three parameters, but only webhook_token has a description. request_id and filter_domain lack any description, and the tool description does not compensate for this gap—it only hints at 'defaults to the latest event' without explaining request_id's effect. With only 33% schema coverage and no meaningful explanation, parameter semantics are weak.

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 clearly states the function: pulling confirm, reset, magic-link, and other URLs from a captured email or HTTP body. It also distinguishes this tool from siblings by noting that wait_for_email already extracts links and codes, implying this tool serves a different or more specific purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use the tool: after wait_for_email or get_webhook_requests when the user needs verification, login, or password-reset links or OTPs. It also mentions the default behavior of using the latest event, providing clear usage context.

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 present, so the description carries the burden. It discloses that only http(s) links from the inbox are followed and mentions the return values (status, final URL, short preview). It does not mention potential side effects, but the described behavior is reasonably transparent for a link-following 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?

The description is three concise sentences, each adding essential information without redundancy. It is well-structured with a clear action, usage context, and contrast.

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 description provides necessary context: it references wait_for_email, specifies return outputs, and clarifies limitations. It does not cover error handling or edge cases, but for a simple link-following tool, the information is largely complete.

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 (webhook_token) has a schema description, and the tool description adds minimal clarity. 'url' and 'request_id' are not explained, nor is their relationship to the email capture or usage after wait_for_email. Schema coverage is low, and the description fails to compensate.

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 clearly states the tool's action: opening a verify/magic-link/reset URL from a captured sign-up email. It distinguishes from OTP-code retrieval, making the purpose 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?

Explicitly instructs to use after wait_for_email, limits to http(s) links from that inbox, and directs OTP-code extraction to a different tool. Provides clear when-to-use and when-not-to-use 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?

No annotations are provided, so the description carries the burden. It transparently states that the token 'alerts when someone opens it' and clarifies that email tokens are tripwires, not inboxes. However, it does not explicitly mention that alerts are sent via the required webhook_token, though this is implied by the parameter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, consisting of two sentences that directly address purpose and usage caveats without unnecessary fluff. It is well-structured and easy 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?

Given the simplicity of the tool, the description covers its core purpose, usage, and a key behavioral note. It does not describe the return value, but that is not critical for this type of tool, and the output schema is not provided for evaluation. Overall, it is sufficiently complete for an agent to use 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 description explains token_type options by mentioning URL, DNS, and email, and the schema describes webhook_token. However, the identifier parameter is not explained at all, leaving some ambiguity about its purpose. Schema coverage is incomplete, so the description adds partial meaning but not full clarity.

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 clearly states the tool's function: 'Make a canary URL, DNS, or email that alerts when someone opens it.' It uses a specific verb and resource, and distinguishes it from sibling tools like create_webhook and wait_for_email.

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 provides explicit usage guidance: 'Use to mark your own files or systems.' It also warns against misuse for email ('not a sign-up inbox') and points to an alternative approach (create_webhook + wait_for_email), which clarifies when to use this tool versus others.

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 carries the full burden. It discloses authorized use and that local_bypass_examples cannot be confirmed, but it doesn't describe the output structure, whether the tool creates a webhook if none exists, or any side effects like logging or rate limits. This is a security-sensitive tool, so more behavioral context is needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded with the main action. The multi-line structure with bullet points is clear. No wasted words, but the paragraph break after the first sentence is odd. Still, it's concise and scannable.

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 an output schema, so return format is covered. The tool has 4 parameters, 4 siblings, and no annotations. The description explains the core purpose, acceptable use, and a key limitation (local_bypass_examples not confirmable). However, it lacks context on how to use the generated URLs (e.g., where to insert them) and what the output looks like without an example, but that is mitigated by the 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 description coverage is low (25%), with only webhook_token having a description. The description mentions 'local_bypass_examples' which is not a parameter, but it doesn't explain identifier, include_ip, or include_dns beyond their names. Includes that they are booleans controlling IP/DNS payloads is inferrable but not explicit. However, the description does indicate that include_ip and include_dns relate to payload construction, so partial value.

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 clearly states the tool generates SSRF callback URLs that ping a webhook. It distinguishes from siblings by naming check_for_callbacks as a companion for confirming hits, and noting local_bypass_examples cannot be confirmed, but it doesn't explicitly contrast with other generation tools like generate_xss_callback.

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 provides clear usage guidance: use only on authorized systems, not for sign-up email, and confirms hits with check_for_callbacks. It doesn't mention what to do if not authorized or alternatives like generate_xss_callback, but the primary conditions are well stated.

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 carries the burden. It mentions 'authorized' and that payloads ping the webhook, but does not disclose side effects (e.g., that the payload may collect cookies or DOM data) or security considerations beyond authorization. The phrase 'authorized XSS payloads' is slightly misleading since the tool itself doesn't authorize; it generates payloads for authorized use. This is adequate but not detailed.

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 total, zero waste. Effectively front-loaded with purpose and a usage caution. The description is concise and gets straight to the point.

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 4 parameters (one required) and an output schema, but the description is minimal. It doesn't explain output content, parameter roles, or how the payload integrates with the webhook. Given low schema coverage and no annotations, this falls short of what a complex security tool needs. It's missing essential details for an agent to use it 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?

Schema coverage is only 25% (webhook_token has a description). The description does not explain any parameters, such as identifier, include_dom, or include_cookies. With low schema coverage, the description should compensate, but it doesn't address parameter meaning or defaults, leaving the agent to infer from names alone.

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 clearly states the tool builds authorized XSS payloads that ping a webhook when executed. This is specific (verb 'build', resource 'XSS payloads', purpose 'ping webhook') and distinguishes it from sibling tools like generate_ssrf_payload or create_webhook.

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?

Provides usage context: 'Use only on systems you are allowed to test' and suggests confirming via check_for_callbacks. This gives clear authorization guidance, but does not explicitly compare to alternatives or state when not to use it; still, it's sufficient for indicating appropriate scenarios.

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 present, so the description must carry the burden. It implies a read-only operation via the word 'get' and the phrase 'quick peek', but does not disclose edge cases, permissions, or side effects. Some context is added but not exhaustive.

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 concise sentences, front-loaded with the main purpose, followed by practical usage guidance. No redundant or filler content; every sentence contributes value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and the simplicity of the tool (one parameter, getter), the description provides sufficient context. It mentions event types and usage scenarios, though it omits details like behavior with no events, which are likely covered by the 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?

The schema covers 100% of the parameter with a description: 'Webhook UUID returned by create_webhook'. The tool description adds no additional meaning beyond what the schema already provides, so 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 clearly states the action: 'Return only the newest captured event' with specific resource types (HTTP, email, DNS). It distinguishes from siblings by explicitly naming alternatives like wait_for_email and get_webhook_requests.

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?

Provides explicit guidance: 'Use for a quick peek. Prefer wait_for_email after a sign-up, or get_webhook_requests to see history.' This tells when to use this tool and when to choose alternatives, fully meeting the criteria.

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 carries the burden. It implies a read-only operation ('Return') and mentions 'existing webhook,' but does not disclose potential errors, side effects, or authentication requirements. It is not misleading, but it is minimal; for a simple getter this is acceptable.

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 concise sentences with the main purpose first. Every sentence adds value, clearly distinguishing usage and providing an alternative. No wasted words.

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 getter with an output schema, the description covers the essential purpose, usage, and alternative. It does not mention the validate parameter, but that is a minor gap given the tool's simplicity. Overall, it is adequately complete.

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 50% (webhook_token is described, validate is not). The description does not elaborate on either parameter, leaving validate's purpose unclear. Since coverage is low, the description should compensate, but it does not.

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 clearly states the tool's action: 'Return the DNSHook domain for an existing webhook.' It explicitly distinguishes itself from related tools like get_webhook_email and notes that create_webhook already returns dns, providing a clear scope and purpose.

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?

Provides explicit usage guidance: 'Use for out-of-band DNS callbacks, not for sign-up email.' It also points to an alternative (create_webhook already returns dns), making it clear when to use this tool versus others.

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 carries the full burden. It discloses the address pattern, that this only returns the inbox (not creates a token or waits for mail), which is useful behavioral context. However, it does not explicitly state read-only nature, error cases, or the meaning of the `validate` parameter, though the core behavior is clear.

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 concise sentences, front-loaded with the primary purpose, followed by the address template and usage/call-order guidance. Every sentence adds necessary context without 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?

For a low-complexity retrieval tool with an output schema, the description covers the key usage flow, alternatives, and next step. The main gap is the undocumented `validate` parameter, but overall it is sufficiently complete for an agent to correctly select and invoke the tool.

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 documentation covers webhook_token but not validate (50% coverage). The description explains how webhook_token maps to the address and references create_webhook, but it never mentions the `validate` boolean parameter or its effect. The description compensates for webhook_token only, leaving validate undocumented.

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 ('Return the temp inbox') and clarifies the token-based address format. It distinguishes itself from siblings by explicitly naming create_webhook and wait_for_email as related tools with different functions.

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 states when to use ('Use when the user already has a token') and directs to create_webhook if not, and wait_for_email after mail. This provides clear when-to-use and sequencing 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?

No annotations are provided, so the description carries the full transparency burden. It conveys a read-only inspection behavior through 'Show' and the validity-check use case, but it does not disclose error behavior, permission requirements, or side-effect guarantees. This is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences with no filler: the first states what the tool shows, and the second gives the trigger scenario. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple one-parameter tool with an output schema, so the description does not need to enumerate return fields. It covers purpose, usage trigger, and the read-only nature, making it complete for tool selection and 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%, and the only parameter is already documented as the 'Webhook UUID returned by create_webhook.' The description adds no extra parameter-level meaning, so the baseline score of 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?

Description uses a specific verb 'Show' and enumerates exactly what is returned: webhook settings, expiry, and request count. This clearly distinguishes the tool from sibling tools like get_webhook_requests, get_webhook_url, or create_webhook.

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 'Use when the user asks if a token is still valid or how it is configured,' providing clear trigger conditions. It does not mention exclusions or alternative tools, but the use case is concrete enough for an agent to select 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 carries the burden. It discloses the truncated bodies and omitted HTML behavior, which is key for setting expectations. It doesn't mention pagination or the response structure, but the existence of an output schema likely covers return details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a compact paragraph with a clear first sentence and then usage notes. Each sentence adds value: it covers purpose, usage, alternatives, and filtering. No fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool is a list/fetch operation, the description covers the key points: what it lists, limitations (truncated, no HTML), alternatives for full dump, newest item, and waiting. The output schema presumably documents the return fields. With three parameters, two have defaults and enums in the schema, and the description clarifies usage. It is complete for this tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 33%: webhook_token is described as 'Webhook UUID returned by create_webhook', but limit and request_type lack description beyond defaults and enum values. The description adds context on how to use request_type to filter emails, and the default values are in the schema. It compensates somewhat, but could add more on limit behavior.

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 the tool lists captured HTTP, email, or DNS events for a webhook, which is a specific verb+resource combination. It explicitly distinguishes itself from siblings like export_webhook_data, get_latest_request, and wait_for_request, making it clear this tool is for inspecting past events in a list.

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?

Provides clear guidance on when to use this tool: to inspect what already arrived, with explicit exclusions: bodies are truncated and HTML omitted, use export_webhook_data for full dump, use get_latest_request for newest item, and use wait_for_request or wait_for_email for waiting for new items. It also gives a filter example for emails.

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 carries the burden. It doesn't explicitly state whether this is read-only or if it triggers any side effects, but given the tool is simple and returns a URL, the description's clarity contributes to behavioral transparency. It also mentions 'existing webhook' implying validation might occur, which is helpful.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a short but complete paragraph, with the main sentence (returns URL) followed by a bolded 'Use when' line and a contrast with create_webhook. It's front-loaded and wastes no words.

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 an output schema (not shown but indicated as true), which likely describes the URL structure. The tool is simple, and the description covers the usage context well, referencing the alternative create_webhook for new inboxes. Could be a 5 but the 'validate' parameter unclear and no mention of error cases, though that might be outside scope.

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 50%: webhook_token has a description ('Webhook UUID returned by create_webhook'), while validate has no description. The description reinforces the purpose of webhook_token but doesn't explain 'validate'. The parameter meanings are mostly clear from the schema, and the description adds value by tying webhook_token to existing webhooks. However, the 'validate' parameter's semantics are ambiguous, so not 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?

The description clearly states the tool returns the HTTPS callback URL for an existing webhook given a token. It distinguishes itself from sibling tools by specifying that it's for existing webhooks and that create_webhook already returns the URL for new inboxes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool: when the user already has a token and needs the HTTP callback URL. It also provides a when-not-to-use by referencing create_webhook for new inboxes, though it doesn't name the exact alternative tool (it does: create_webhook).

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 exist, so the description carries full disclosure burden. It does reveal meaningful behavior—the query syntax (method:, content:) and request_type values—but omits basic semantics like the meaning of limit, sorting values, or whether the search is scoped to a single webhook (only implied via webhook_token). It's not misleading, but it leaves the agent guessing on the output shape and filter semantics.

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 tight sentences: one for purpose, one for when-to-use, one with concrete examples. Every line earns its place with zero filler. The example block is scannable and immediately illustrative.

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 7-parameter search tool with a query language, the description covers the primary use cases (find by method, keyword, type, date) and introduces the query DSL. An output schema exists, so return values needn't be specified. The main gap is absence of date-format and pagination/limit semantics, but the tool remains usable with defaults.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 14% schema description coverage, the description must compensate for 6 undocumented parameters. It helpfully decodes the query parameter syntax (method:, content:) and demonstrates request_type usage, but says nothing about date_from/date_to format, limit, or the sorting values beyond the 'newest' default. Partial compensation for a large documentation 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?

Opens with a specific verb+resource: 'Search captured events by method, body text, headers, type, or date.' The concrete examples (query='method:POST', query='content:verify', request_type='email') remove any ambiguity about what fields are searchable, cleanly distinguishing this from sibling retrieval tools like get_latest_request.

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 states when to reach for this tool: 'Use when the user asks to find POSTs, a keyword, or only emails/DNS.' This is clear, actionable when-to-use context. It doesn't name exclusions or point to alternatives like get_webhook_requests, but the trigger conditions are specific enough that an agent would rarely misfire.

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 present, so the description carries the full burden. It states the core behavior (POSTing payloads, optional delay) but does not disclose side effects, error behavior, or any prerequisites (e.g., webhook must exist). For a write operation, this is minimal but not misleading; it adds the load-test intent. It is adequate for a simple tool but could mention that it generates network traffic and may be used for testing only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loaded with the main operation and immediately followed by a clear usage note. Every sentence adds value with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (3 params, no nested objects) and the existence of an output schema, the description covers the essential purpose and usage. It lacks explicit mention of the output/return value but that is handled by the schema. It could detail payload constraints (e.g., any JSON object) but is otherwise sufficient for a straightforward webhook sender.

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 low (33%) with only webhook_token described. The description says 'optionally spaced out' which hints at delay_ms but doesn't clarify its unit or purpose beyond spacing. For payloads, 'sample JSON payloads' gives a hint but does not specify allowed structure or that any object is fine. Since coverage is low, the description should have compensated more, but it adds only minimal clarification, leaving the agent to guess about payload format and delay 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 description states a clear action: 'POST several sample JSON payloads to the webhook', which specifies the verb, resource, and scope. It also distinguishes itself from the sibling tool send_to_webhook by implying multiple requests vs single, and effectively differentiates its use case.

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?

Explicit usage guidance is given: 'Use to load-test capture, not to wait for a real site or email.' This tells the agent exactly when to invoke this tool and when not to, implying alternatives like wait_for_request or wait_for_email for real interactions.

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?

There are no annotations, so the description must carry the behavioral transparency burden. It discloses that the tool POSTs JSON, but it does not explain side effects (e.g., whether a request record is created), authentication requirements, rate limits, or what the response contains. For a send/test mutation without annotations, this is too thin.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: the first sentence states the action, and the second gives practical usage guidance. Every sentence contributes value without unnecessary 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?

The tool has three parameters including a nested object and an output schema, but the description does not cover important operational details such as how headers are used, what the response represents, or the significance of webhook_token. It is adequate for a trivial test action but incomplete for a tool with this schema complexity and no annotations.

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 33%, and the description adds little beyond 'JSON'. It does not clarify the role of data, headers, or webhook_token, nor how they relate to the HTTP request. The schema helpfully describes webhook_token, but data and headers are left under-explained.

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 clearly states the action: 'POST JSON to the webhook URL to test that capture works.' It also distinguishes this tool from related send/wait tools by mentioning 'sample payload' and contrasting with waiting for real sites or emails.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly provides a when-to-use ('when the user wants to send a sample payload') and a when-not-to-use ('not when they are waiting for a real site or email'). However, it does not name alternative sibling tools, such as send_multiple_requests or wait_for_request, so it stops short of fully explicit alternatives.

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 carries the full burden. The description only says 'Change how an existing webhook responds' which implies mutation but doesn't disclose whether updates are immediately effective, whether partial updates are possible (parameters are optional), what happens if invalid values are given, or if there are any side effects. Given that this is a mutation tool with zero annotation coverage, more detail is needed about behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, two sentences, front-loaded with the purpose. The first sentence covers the main action, the second gives usage guidance. No unnecessary fluff. Could be structured slightly better by mapping the listed aspects to parameter names, but it's passable.

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 6 parameters, low schema coverage, no annotations, and a complex mutation operation, the description is incomplete. It doesn't explain the semantics of parameters like default_status vs default_content, whether all parameters are optional (though the schema shows defaults null, so likely), what the output schema contains (though output schema exists, so that helps), or how updates are applied. Given the tool's complexity and lack of structured metadata, the description should provide more context. However, the output schema reduces some burden about return values.

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 17% (only webhook_token has a description). The tool description adds a list of fields it can change: status, body, timeout, CORS. However, it doesn't map these to the actual parameter names (default_status, default_content, default_content_type, timeout, cors). The description uses generic terms that roughly correspond but cause ambiguity. With 6 parameters and low schema coverage, the description should do more to clarify each parameter's meaning. It's borderline minimum viable.

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 clearly states the tool changes 'how an existing webhook responds' and lists the specific aspects: status, body, timeout, and CORS. This distinguishes it from sibling tools like create_webhook (creation) and send_to_webhook (sending requests). It could be more explicit about it being an update to a specific pre-created webhook, but the mention of 'existing webhook' and webhook_token clarify that.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use after create_webhook when the user wants a different canned reply.' This provides clear guidance on when to use the tool and implies a prerequisite (webhook must already exist). It doesn't explicitly exclude alternatives, but the context of sibling tools makes it obvious. The guidance could mention that other tools like get_webhook_info are for reading, not updating, but it's adequate.

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. It discloses that HTML is omitted and directs to export_webhook_data, explains the return_existing flag for pre-arrived emails, and mentions the prerequisite of creating a webhook. It does not mention any potential side effects or rate limits, but the key behavioral facts are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, three sentences, and front-loaded with the primary purpose. It includes important conditional guidance (when to use return_existing, when to create_webhook first) without excessive detail. A slight improvement could be to structure the return_existing and timeout info more prominently, but it's well-organized.

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 moderately complex with 4 parameters and a return payload including URLs and OTP codes. The description covers the main usage flow, mentions the return data, and provides pointers for additional use cases (full HTML, following links). The output schema exists, so the description needn't detail the return structure. It doesn't mention edge cases like multiple emails or filtering, but for the core use case it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 25% (only webhook_token has a description). The description adds meaning for the parameters: it explains return_existing (return_existing=true if email already arrived), timeout_seconds range (1-120s), and clarifies webhook_token format (UUID from create_webhook). This compensates for the low schema coverage, though extract_links is not explicitly explained in the description but is self-evident.

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 clearly states the tool waits for specific types of emails (sign-up, verify, magic-link, password-reset) with a timeout range. It specifies the output (subject, preview, URLs, verification codes) and names the sibling tool 'create_webhook' for prerequisite setup, distinguishing it from 'wait_for_request' and 'follow_email_link'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool (after submitting a webhook email on a website) and mentions the alternative for full HTML (export_webhook_data) and the follow_email_link tool. However, it doesn't explicitly state when NOT to use this tool versus other similar tools like wait_for_request.

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 behavioral disclosure burden. It discloses non-obvious behavior: polling waits, 1-120s request window, truncated bodies, omitted HTML, and the return_existing caveat. It does not fully explain consumption/ordering or timeout edge cases, but it provides meaningful transparency beyond 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?

The description is concise, front-loaded with the core purpose, and every sentence adds a distinct useful fact: timing, usage timing, data truncation, alternative tool, and existing-request handling. There is no fluff or tautology.

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 polling tool with an output schema and no annotations, this is nearly complete. It covers when to use it, when not to use it, an alternative for full data, and the return_existing scenario. The main remaining gap is some ambiguity around the request_type parameter, especially its 'email' enum value, since the description directs email-specific cases to wait_for_email.

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 low (25%), yet the description adds important parameter meaning: timeout is bounded to 1-120s, return_existing=true can be used when the request may already be there, and webhook_token is the UUID from create_webhook. The request_type parameter is only partially clarified by 'HTTP (or DNS)' and the explicit exclusion of email verification cases, so a small gap remains.

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?

Starts with a concrete verb and object: 'Poll until a new HTTP (or DNS) callback hits the webhook.' This clearly defines the tool's purpose and distinguishes it from sibling tools like wait_for_email, export_webhook_data, and get_webhook_requests.

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?

Provides explicit usage context: 'Use after giving a site the webhook URL.' It names clear alternatives for overlapping cases: 'use export_webhook_data for the full dump' and 'use wait_for_email instead' for verification/magic-link/password-reset mail. This is strong sibling differentiation.

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