AnyHook

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

The annotations indicate the tool is not read-only and not destructive. The description adds valuable behavioral context by stating that apps without destinations still log events (inspect-only) and that the app is active immediately. This goes beyond the annotations and provides crucial state changes (immediate activation, logging behavior). The only minor gap is not detailing the exact response structure beyond the inbound URL, but the key behavioral outcomes 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 and front-loaded with the core purpose. The first sentence states the primary action and essential inputs. The second sentence adds important behavioral nuance. However, some details like the PATCH example could be seen as slightly verbose, but it conveys a key usage pattern. Overall, it is efficient and structured well.

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 there is no output schema, the description mentions the return value (inbound URL) which is critical for the agent. It also handles the optional parameter behavior and active-immediately status. Sibling tools exist that might serve similar purposes, but the creation context is distinct enough. The description is sufficiently complete for an agent to call the tool 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 schema has 100% description coverage, so parameters are already well-documented (e.g., 'api_key' says it's ignored over stdio, 'source' explains signature auto-detection). The description adds important semantics by clarifying the 'destinations' parameter's optionality and its consequence (logging-only mode). This goes beyond the schema's basic field descriptions, so the description adds meaningful 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 action ('Create a new app') and specifies the key resources (name, provider source, destinations). It also highlights the unique behavior of creating an app without destinations (inspect-only logging), which distinguishes it from any other tool. This makes the purpose highly 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?

The description implicitly explains when to use this tool: to create an app that can receive events and optionally deliver them. It mentions the alternative of PATCHing the app later to add destinations, but does not explicitly name sibling tools or state when NOT to use it. Still, the context is clear enough for an agent to decide.

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?

Beyond the readOnlyHint annotation, the description discloses meaningful behaviors: inactive apps return 202 with reason app_inactive instead of relaying events, signing secrets are redacted to a boolean plus hint, and legacyInboundUrls still route after a slug change. This is exactly the behavioral context 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?

Four dense sentences with no filler. The core purpose is front-loaded, and every subsequent sentence adds decision-relevant detail about response interpretation or edge cases. Nothing is redundant with the schema or annotations.

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 carries the burden of explaining the return fields and unusual behaviors. It covers active/inactive handling, secret redaction, and legacy URLs—enough for an agent to correctly interpret results without additional assumptions.

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%, and the only parameter (api_key) is already fully documented in the schema, including when it is needed and when it is ignored. The description adds no parameter-level information, so the 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 opens with a specific verb and resource: 'List apps in your AnyHook account'. It further specifies the returned fields (inbound URLs, sources, destination URLs), which distinguishes it clearly from sibling tools like anyhook_apps_create or anyhook_events.

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 implies the tool is for enumerating apps and checking their active state, but it does not explicitly say when to use it versus alternatives or when not to use it. No sibling tool is named, so routing between tools is left to inference.

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?

Despite annotations (readOnlyHint: false, destructiveHint: false, openWorldHint: true) telling the agent it's a non-destructive, open-world operation, the description goes far beyond: it explains the key is used once and not stored, that without appSlug a new app is created and removed if the provider refuses the key, that re-running replaces the registration, and that GitHub sends a signed ping immediately. This is exactly the kind of behavioral context the annotations do not provide, and there is no contradiction with them.

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, well-structured paragraph that front-loads the main action and then adds important behavioral details in a logical order. It is dense but not wasteful; every sentence carries actionable information. A slightly tighter grouping could improve readability, but it's highly effective.

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 non-read-only, open-world tool with no output schema and fully documented parameters, the description covers everything an agent needs: the exact effect, side effects, idempotency, failure handling, provider-specific behavior (GitHub ping), and the follow-up step for forwarding. Nothing critical 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 all parameters (provider_key, appSlug, target, api_key) are documented in the schema. The description reinforces appSlug behavior and provider_key usage ('the provider is read from the key'), but adds no new syntax or format details beyond what the schema already states. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: 'Wire a provider to AnyHook in one call', and enumerates the exact effects (register webhook, save signing secret, enable signature verification). It clearly distinguishes itself from sibling tools like anyhook_apps_create by describing the end-to-end provider-side registration.

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 explains when this is used (to wire a provider), what happens with or without appSlug, and what happens on re-run. It hints that events are logged until a destination is added, but it doesn't explicitly say when to use this tool vs. anyhook_apps_create or anyhook_providers. Still, the 'afterwards' note implicitly guides the agent to a separate step for forwarding.

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?

Annotations declare readOnlyHint=true, and the description adds useful behavioral context: summaries only, no request headers or body, most-recent-first ordering, and the account/local store distinction. This goes beyond the annotation without contradicting it, though it does not describe pagination or default limit 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?

Two dense sentences with no filler. Key facts are front-loaded (list, ordering, fields), followed by the payload-routing instruction and mode behavior, all in a compact and scannable format.

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 read-only list tool with no output schema, the description covers the essential return fields, the ordering, the summary-only limitation, how to access full payloads, and the two runtime modes. The parameter schema fills in the remaining filter details, making the tool adequately complete for correct invocation.

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

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

Schema description coverage is 80%, so the schema already documents most parameters. The description adds context about account vs. local mode that clarifies mode-dependent filters, but it does not explain individual parameters beyond what the schema provides. This meets the baseline for schema-driven parameter 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?

States a specific verb and resource ('List webhook events'), specifies ordering ('most recent first') and enumerates the returned summary fields (id, app, type, status, attempt, destination status code, latency, timestamp). It explicitly distinguishes itself from anyhook_inspect by noting that only summaries are returned and payloads require a follow-up call.

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 routing guidance: 'Summaries only... call anyhook_inspect with an id from here to read one event's payload.' It also explains the account vs. local in-memory mode, helping agents understand when filters like source and status apply. It does not explicitly contrast with other sibling list tools such as anyhook_inbox or anyhook_undelivered, so it stops short of full 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?

The readOnlyHint annotation already signals a safe read operation. The description adds useful behavioral context: it explains that mail sent to the returned address generates events of type email.received, which goes beyond the annotation. It does not disclose potential errors or side effects, but given the annotation and the simplicity, it adds meaningful context.

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 sentences, front-loads the core concept (every app is an email inbox), and delivers the return value without excess. No wasted words; every clause adds 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?

For a simple read-only tool with two optional parameters and no output schema, the description covers the essential purpose, the return value (address and webhook URL), and the relationship to events. It does not detail exact response format, but that is likely not critical. The tool is adequately described for an agent to call 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 100% for both parameters (app and api_key), so the schema already documents them well. The description adds the email pattern ({user}.{app}@anyhook.net) which helps understand the app parameter's role, but it does not significantly expand on the schema descriptions. Baseline 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?

The description clearly states the tool's purpose: 'Returns the address and webhook URL for one of your apps.' It also explains the email inbox concept and how incoming mail becomes events, which distinguishes it from siblings like anyhook_events (which reads events) and anyhook_apps_list (which lists apps). The verb 'returns' is specific and the resource is well-defined.

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 implies usage: you need this address to send email that becomes events, and it points to anyhook_events for reading them. However, it does not explicitly state when to use this tool versus alternatives, nor does it give exclusions or a direct 'use this when...' condition. The context is there but not 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?

Annotations already declare readOnlyHint=true, and the description adds valuable behavioral context: payloads can be large and often contain personal data, which warns the agent about the operation's nature. It also mentions 'Account or local store' as a location qualifier. This goes beyond the annotation, though it doesn't describe error handling or response size limits.

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 sentences, front-loading the core purpose and immediately adding the key usage constraint. Every sentence earns its place, with 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?

For a simple read-only tool with one required parameter, the description is nearly complete. It covers purpose, the source of id, and important caveats about payload size and privacy. The lack of output schema is acceptable because the description implies the return contains full event detail. Minor gaps like error handling are not critical for this simple operation.

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%: both id and api_key have detailed descriptions. The description adds no new parameter semantics beyond what the schema already provides, so the baseline of 3 applies. The mention that id comes from anyhook_events is already in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides full detail for one event by id, specifically including the inbound headers and body that anyhook_events omits, plus the destination's response. This is a specific verb and resource, and it explicitly differentiates from the sibling anyhook_events by noting what it adds.

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 gives clear usage guidance: 'fetch one at a time, only when the body is needed' and warns about large payloads and personal data. It implies this tool is for when the full body is required, contrasting with anyhook_events which omits these details. However, it doesn't explicitly state alternatives for other use cases, so it's not a full 5.

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?

The description adds behavioral context beyond annotations by explaining that the request is POSTed only if targetUrl is provided, and that the response is returned. This clarifies the conditional side effect. It does not, however, disclose what happens when targetUrl is omitted (likely returns the generated request) or the return format, but the annotations already carry the destructive hint.

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 core purpose, followed by a concise conditional. No redundant words, every sentence adds 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?

The description explains the core function and the targetUrl conditional, but it does not specify the return value when targetUrl is not provided, nor the overall response format. With no output schema, this is a notable gap for an agent to know what to expect. The tool is moderately simple, but the missing non-posting behavior prevents a higher score.

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%, so all parameters are already documented. The description repeats the targetUrl behavior that the schema already states ('If set, POST the generated request to this URL and return the response') and adds no new meaning about other parameters like data or secret. 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 tool generates a webhook request with a valid signature for Stripe, GitHub, or Slack, and optionally posts it to a target URL. This is a specific verb+resource that distinguishes it from sibling tools like verify or replay, but it does not explicitly name a sibling or provide a contrast, so it misses the top score.

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

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

The description implies usage for generating test webhooks, and the conditional targetUrl behavior is clear. However, it does not explicitly state when to use this tool versus alternatives like anyhook_verify or anyhook_replay, nor does it provide exclusions or prerequisites. The guidance is implied rather than 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?

The readOnlyHint annotation already signals a safe read operation, and the description correctly aligns by saying 'List.' The description adds minimal behavioral context beyond that—no mention of response size, authentication needs, or pagination. With annotations present, this is acceptable 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?

A single, tight sentence that front-loads the verb and scope. No wasted words or redundant phrasing. It earns its place completely.

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 parameterless list tool, the description sufficiently conveys what will be returned: providers and their event types. There is no output schema, so the description helps somewhat, though it doesn't specify the exact response format (e.g., array vs object). Given the simplicity, this is a minor 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 has zero parameters, so there is nothing for the description to clarify. The input schema is empty and the description itself doesn't promise any arguments. This is the baseline for a no-parameter 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 clearly states a specific verb ('List') and resource ('webhook providers... event types'). It is distinct from mutation tools like anyhook_mock or anyhook_apps_create, but it does not explicitly differentiate from anyhook_events, which might also list event types. Still, the scope is concrete enough for an agent to understand what it returns.

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 gives no guidance on when to use this tool versus alternatives. It doesn't say 'use this to discover providers before mocking' or mention anyhook_events. The agent is left to infer that a listing tool is for discovery, which is weak.

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?

Annotations declare destructiveHint=true and readOnlyHint=false, and the description goes well beyond them: replay sits outside the monthly quota but inside a daily per-plan replay limit, quota-held events get billed as new, and non-idempotent receivers will double-process. This is exactly the kind of consequence disclosure a mutation tool 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?

Three dense sentences, front-loaded with the action before the constraints, and no filler. The trailing clause about debugging is slightly conversational but still carries the idempotency warning.

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 annotations covering the safety profile and a fully documented schema, the remaining burden is behavioral, and the description covers quota, limits, billing, and duplicate delivery. It omits what happens when a replay is rejected by the daily limit or fails mid-delivery, which is a minor gap for a two-parameter tool with 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 description coverage is 100%, so both parameters are already documented in the schema, including the quota note on 'id'. The description adds no syntax, format, or lookup guidance for the event ID, 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?

States a concrete verb and resource: 'Re-send a stored event to its destinations.' An agent can tell this is a replay operation on a single stored event. It does not, however, differentiate itself from the sibling anyhook_replay_failed, which is the closest competing tool.

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 explains costs and side effects but never states the selection condition against alternatives — notably anyhook_replay_failed, which an agent could easily confuse with this tool. Usage is only implied by the scenario described ('replaying an event that was held for quota').

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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows it mutates state. The description adds purpose context but no additional behavioral details beyond what annotations provide; no contradiction.

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 with no filler. The action and use case are stated directly and efficiently, front-loading the core purpose.

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 destructive tool with no output schema, the description explains what it does and when to use it, but it does not mention potential side effects (e.g., duplicate events, rate limits) or what happens after replay. Given the tool's simplicity, this is adequate but not fully 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 100% with both parameters described (appSlug and api_key). The tool description adds no extra meaning to the parameters 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?

States a clear action (re-send) on a specific resource (failed events) scoped to an app slug. It is unambiguous but does not explicitly differentiate from siblings like anyhook_replay or anyhook_undelivered, which might also handle events.

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 a concrete use case ('after fixing a downstream bug to recover queued work') but does not mention alternatives or when not to use this tool. The context is helpful but lacks explicit exclusions or comparisons to 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?

The readOnlyHint annotation already covers the read-only nature, and the description adds valuable context about the status filter (failed or still retrying). However, it does not disclose other behaviors such as pagination, ordering, or error conditions, so it meets but does not exceed the bar given the annotation.

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, 18 words, with no filler. The action and filter are front-loaded, and the sentence is easy to parse. Every word contributes to the meaning.

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 filtered-list tool with a readOnly annotation and one required parameter, the description provides enough to understand the core purpose but lacks guidance on parameter usage (especially limit and appSlug format) and alternatives. The missing usage guidelines and parameter semantics prevent full completeness for an agent to call it without extra schema inspection.

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% (only api_key has a description), and the tool description adds minimal parameter meaning beyond echoing 'given app' for appSlug. It does not explain limit semantics or the role of appSlug further, failing to compensate for the low schema coverage.

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 ('Show') and a resource ('events for the given app') with a clear filter ('not successfully reached any destination'). It distinguishes this from sibling list tools like anyhook_events or anyhook_inbox by explicitly scoping to undelivered events, so an agent can identify the tool's niche.

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 implies the use case (retrieve undelivered events) but does not explicitly compare with alternatives or state when not to use it. It lacks explicit exclusions or references to sibling tools, leaving the agent to infer the appropriate scenario.

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?

Annotations already declare readOnlyHint=true, so no mutation warning is needed. The description adds meaningful behavioral context by disclosing support for 20 providers, which tells the agent the provider parameter is constrained and not arbitrary. This goes beyond the schema's examples and helps clarify expected usage.

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 sentences, front-loaded with the core operation and followed by a provider list. Every phrase adds value: the verb-resource pair defines the action, and the provider list signals supported ecosystems. No redundant restatement of schema properties or annotations.

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 is adequate for basic invocation but leaves gaps. It does not specify what the tool returns (e.g., a boolean, a result object) which matters for a verification tool, and the provider list is partial ("including...") without enumerating all 20 valid options. The schema covers requestUrl's conditional requirement for Twilio/HubSpot, but the description alone would not make an agent aware of this nuance.

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

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

Schema description coverage is 100%, so each parameter is already documented in the schema (body, secret, headers, provider, requestUrl). The description adds no extra parameter-level semantics, such as format or edge cases, beyond mentioning the secret and provider support. Baseline 3 is appropriate when the schema carries the explanatory weight.

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: 'Verify a webhook signature against a secret.' This clearly distinguishes it from siblings like anyhook_inspect or anyhook_mock, which serve different purposes. The provider list also adds scope, making it evident this is a verification tool, not a general webhook utility.

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 implies when to use the tool (to validate webhook signatures) but does not explicitly compare it to alternatives or state when not to use it. Siblings like anyhook_inspect or anyhook_replay are related, yet no routing guidance is offered, so the agent must infer the tool's niche solely from its verb.

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