Server Quality Checklist

Tool Scores

• anyhook_undeliveredB
  3.3/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context by defining 'undelivered' as 'failed or still retrying,' which is a meaningful behavior beyond the tool name. However, it does not disclose read-only safety, authentication requirements, pagination, or response format, leaving notable gaps.

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

  Conciseness5/5

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

  The entire description is one focused sentence with no filler. The core filtering condition is front-loaded and every word contributes to meaning, making it a model of concise tool documentation.

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

  Completeness2/5

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

  The tool has no annotations, no output schema, and low parameter coverage; the description only covers the tool's purpose. Missing are when-to-use guidance, parameter semantics for limit and appSlug, and any return-value or error information. An agent would be under-informed for a confident invocation.

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

  Parameters2/5

  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 description does not compensate. 'Given app' loosely references appSlug but provides no format or required context, and limit/api_key semantics are left entirely to the schema. Thus the description adds minimal parameter meaning beyond what little the schema already provides.

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

  Purpose5/5

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

  The description states a specific verb ('Show'), a clear resource ('events for the given app'), and a precise status condition ('not successfully reached any destination (failed or still retrying)'). This cleanly distinguishes the tool from siblings like anyhook_events, which would list all events regardless of delivery status.

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

  Usage Guidelines2/5

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

  The description provides no explicit guidance on when to choose this tool over alternatives such as anyhook_events or anyhook_inbox. No when-to-use, when-not-to-use, or alternative tools are mentioned; usage context is only implied by the name and the status filter.

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

• anyhook_verifyB
  3.3/5.0
  Behavior2/5

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

  With no annotations, the description carries the full behavioral burden, but it only restates the verify action. It does not disclose whether the tool returns a boolean, throws on invalid signatures, or performs any side effects or network calls.

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

  Conciseness5/5

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

  Two sentences with no filler: the core operation is front-loaded, and the second sentence adds useful provider coverage information compactly. Every sentence earns its place.

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

  Completeness3/5

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

  The description plus a fully covered schema is minimally sufficient for constructing a request. However, there is no output schema and no statement about the verification result or failure behavior, so an agent must infer what happens after calling the tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline of 3 applies. The description adds provider examples that reinforce the provider parameter, but it does not provide deeper semantic value beyond what the schema already explains.

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

  Purpose4/5

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

  The description names a specific action and resource ('Verify a webhook signature against a secret') and adds provider examples, making the tool's purpose immediately clear. It does not explicitly contrast with sibling tools like anyhook_inspect or anyhook_simulate, but none of those share the verify role.

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

  Usage Guidelines3/5

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

  The provider list gives a clear condition for when the tool applies, and the core purpose implies when it should be used. However, it does not explicitly state when to prefer another anyhook tool or mention exclusions such as 'for simulating webhooks, use anyhook_simulate.'

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

• anyhook_mockA
  3.5/5.0
  Behavior4/5

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

  Without annotations, the description carries the burden of behavioral disclosure. It does well by explicitly stating the key side effect: if targetUrl is provided, the request is POSTed to that URL and the response is returned. It also highlights that the generated signature is valid, which is important for simulation. It could be more explicit about what happens when targetUrl is absent, but the core behavior is transparent.

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

  Conciseness5/5

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

  Two concise sentences, each earning its place. The main action and the conditional side effect are front-loaded, and there is no redundant or filler content.

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

  Completeness3/5

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

  The description plus schema covers the main workflow well, but there is a noticeable gap: what is returned when targetUrl is not provided? Since there is no output schema, this missing return semantics makes the tool slightly incomplete. Usage context is also absent, which matters given the number of sibling tools.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all five parameters effectively. The description adds context for targetUrl's POST behavior, but it does not go beyond the schema for provider, event, data, or secret. This is a solid baseline for a schema-heavy tool.

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

  Purpose4/5

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

  The description clearly states what the tool does: generate a webhook request with a valid signature for three named providers. It is specific and easy to understand, but it does not explicitly distinguish itself from the sibling 'anyhook_simulate' or other webhook-related tools.

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

  Usage Guidelines2/5

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

  The description explains conditional behavior ('If targetUrl is provided...') but gives no guidance on when to prefer this tool over siblings like anyhook_simulate, anyhook_verify, or anyhook_replay. There are no stated alternatives, exclusions, or use-case scenarios.

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

• anyhook_replay_failedA
  3.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full behavioral burden. It explains the action and intent, but does not disclose potential side effects such as duplicate downstream delivery, retry limits, rate limits, or whether the operation is reversible.

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

  Conciseness5/5

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

  Two short, purposeful sentences with no filler. The core behavior is front-loaded, and the second sentence adds practical context without redundancy.

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

  Completeness3/5

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

  Minimally adequate for a tool with one required parameter and a clear scope. However, with no output schema and no annotations, an agent gets little guidance about expected return values, errors, or consequences of replaying all failed events.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline applies. The description mentions the app slug but adds no meaning beyond the schema, which already documents api_key and appSlug clearly.

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

  Purpose5/5

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

  Description uses a specific verb 'Re-send' and defines the exact resource: 'every failed event for the given app slug.' The title's 'Bulk-replay' helps distinguish it from narrower siblings like anyhook_replay and anyhook_undelivered.

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

  Usage Guidelines4/5

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

  Gives a concrete use case: 'useful after fixing a downstream bug to recover queued work.' It does not explicitly contrast with sibling tools, but the bulk scope makes the intended situation clear 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.

• anyhook_apps_createA
  3.9/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full disclosure burden and handles it well: it discloses activation timing ('active immediately'), the non-obvious behavior that apps without destinations still log every event but deliver nowhere, and how to update destinations via PATCH. Minor gaps remain — no idempotency, rate-limit, or failure-mode information.

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

  Conciseness4/5

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

  Four sentences in a logical order (what → return value → activation timing → conditional no-destination behavior), with no filler. The final sentence is long and carries an inline PATCH payload, but that payload is directly actionable and earns its place.

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

  Completeness4/5

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

  The description covers the critical return value (inbound URL), the activation semantics, and the edge behavior of the optional destinations parameter against a fully documented schema. The main gap is the absence of a full response shape, which matters more because there is no output schema, but the named return value is the one a caller actually needs.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline of 3 applies. The description adds a little semantic value by tying the optional destinations parameter to the inspect-only logging behavior, but it largely restates the parameter list the schema already documents.

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

  Purpose5/5

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

  The description uses a specific verb-resource pairing ('Create a new app') and enumerates its key inputs (name, provider source, destinations) plus its primary output (the inbound URL). This makes it immediately distinguishable from the sibling list tool anyhook_apps_list and from the event/inspection tools.

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

  Usage Guidelines3/5

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

  The scenario of creating an app without destinations (inspect-only logging) is described, which implies a legitimate use case, and the follow-up PATCH for later delivery is given. However, no explicit guidance contrasts this tool against alternatives (e.g., anyhook_apps_list for listing, anyhook_quickstart for keys) and no exclusions are stated.

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

• anyhook_simulateA
  3.9/5.0
  Behavior4/5

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

  With no annotations, the description carries the full disclosure burden. It states the key side effect ('insert it into the local memory store') and the operational restriction (local only, not remote). It does not disclose response shape, persistence, or whether secret validation occurs, but for a local simulation tool the disclosed insert behavior and mode restriction are the most important traits.

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

  Conciseness5/5

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

  Two sentences with no wasted words: the core action and purpose are first, followed by a precise exception and alternative. This is concise, front-loaded, and easy to scan.

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

  Completeness2/5

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

  For a tool with no output schema, no annotations, and zero param descriptions, the description leaves out too much for confident invocation. An agent still lacks parameter semantics, expected provider/event values, and any indication of return data or system effects beyond 'insert into local memory store.'

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

  Parameters1/5

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

  Schema description coverage is 0% and the description provides no parameter meaning at all. It never explains what 'provider', 'event', 'data', or 'secret' represent, which values are expected, or how they affect the simulated webhook. The enum for provider is visible in the schema, but the description adds no semantic value.

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

  Purpose5/5

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

  The description names a specific verb and resource: 'Generate a mocked webhook AND insert it into the local memory store'. It also states the purpose (exercise list/inspect flows) and explicitly separates it from the sibling anyhook_mock by noting remote-mode usage, so an agent can distinguish the tool without opening the schema.

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

  Usage Guidelines5/5

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

  It tells the agent exactly when to use the tool: to exercise list/inspect flows without a real provider. It also gives an exclusion and alternative: 'Not available in remote mode, use anyhook_mock + your real inbound URL there.' This explicit when/when-not guidance is stronger than typical sibling descriptions.

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

• anyhook_providersA
  4/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the full burden. The verb 'List' implies a read-only, non-destructive operation, but the description does not disclose details such as whether the provider list is static or dynamic, whether authentication is needed, or what the returned structure looks like.

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

  Conciseness5/5

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

  One sentence, front-loaded with the action and resource, and no filler. It efficiently conveys the core purpose without wasting tokens.

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

  Completeness4/5

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

  For a zero-parameter enumeration tool, the description is reasonably complete: it names the output domain (providers and event types) and the scope (AnyHook mocking). Since there is no output schema, a bit more detail about the returned format could help, but the low complexity keeps this from being a major gap.

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

  Parameters4/5

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

  The tool takes zero parameters, so parameter documentation is not needed. The baseline for zero-parameter tools is 4, and the description correctly focuses on what the list contains rather than on inputs.

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

  Purpose5/5

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

  The description uses a specific verb ('List') and names the exact resource: webhook providers supported by AnyHook, plus their available event types. This clearly distinguishes it from siblings like anyhook_mock or anyhook_inspect, which do different operations.

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

  Usage Guidelines3/5

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

  The intended use is implied: an agent should call this when it needs to know which providers or event types are supported. However, no alternatives are mentioned, and there is no explicit guidance on when not to use it or how it relates to siblings like anyhook_events.

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

• anyhook_eventsA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden and does well: it discloses that events are summaries only, excludes request headers and body, orders results, and states which storage backend is used. It could add more about auth requirements or response envelope, but the core behavior is transparent.

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

  Conciseness5/5

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

  The description is compact and information-dense, with the most important facts about ordering and field selection front-loaded. Every sentence earns its place: list content, payload pointer, and storage-mode caveat.

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

  Completeness4/5

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

  For a list tool with five optional parameters and no output schema, the description gives a solid picture of what the response contains and how to access richer data. It could be more complete by explaining the response envelope or mentioning the api_key requirement in prose, but the schema covers those gaps reasonably well.

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

  Parameters3/5

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

  Schema description coverage is 80%, so most parameters already carry meaningful descriptions. The prose adds context about the returned fields and query intent but does not substantially deepen understanding of individual parameters like limit or source beyond what the schema provides.

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

  Purpose5/5

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

  The description names a specific verb and resource, states ordering (most recent first), and enumerates the exact fields returned. It clearly differentiates itself from anyhook_inspect by noting these are summaries only and pointing to inspect for payloads.

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

  Usage Guidelines4/5

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

  It explicitly tells the agent to use anyhook_inspect with an id from this tool when full payload details are needed, which is a clear when-to-use alternative. It also explains the account-vs-local mode context, but it does not exhaustively cover all sibling tools such as anyhook_undelivered or anyhook_replay_failed.

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

• anyhook_replayA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral disclosure burden. It explicitly addresses quota impact and repeat-call safety, which are the main side-effect concerns for a replay operation. It does not mention permissions or error behavior, but the key non-destructive and low-cost traits are conveyed.

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

  Conciseness5/5

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

  Two concise sentences with no filler. The core action is front-loaded, and the important quota/safety caveat is placed immediately after, making the key information easy to scan.

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

  Completeness4/5

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

  For a simple tool with two parameters and no output schema, the description adequately covers the purpose and a critical side-effect. It lacks explicit return-value or error-handling guidance, but the low complexity and clear required id make the tool invocable with confidence.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already fully documents both id and api_key. The description adds no parameter-level detail beyond what the schema provides, 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.

  Purpose5/5

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

  Description states a specific action ('Re-send') and resource ('a stored event to its destinations'), clearly distinguishing it from the sibling anyhook_replay_failed, which would target failed events. The title 'Replay an event' aligns with the description rather than merely restating it.

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

  Usage Guidelines4/5

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

  Description gives clear usage context: it is safe to call repeatedly while debugging and does not consume monthly event quota. It does not explicitly name alternative tools or state when not to use it, but the debugging-oriented guidance is actionable and clear.

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

• anyhook_inspectA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral disclosure burden. It usefully reveals that results can include large, potentially personal payloads and advises fetching one event at a time. It stops short of explicitly stating read-only behavior or idempotence, but 'Inspect' and the described output imply a non-mutating lookup.

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

  Conciseness4/5

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

  The first two sentences are concise, informative, and front-loaded with purpose and usage guidance. The final fragment 'Account or local store' is cryptic and does not clearly earn its place, creating minor confusion. Overall the description is still compact and mostly effective.

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

  Completeness4/5

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

  For a single-event lookup with no output schema and no annotations, the description provides a reasonable picture of what is returned: inbound headers, body, and destination response. It also covers operational context around payload size and privacy. Missing details include explicit error/authentication behavior, but the schema addresses the api_key parameter directly.

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

  Parameters3/5

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

  Schema coverage is 100%, so the schema already documents both id and api_key. The description adds little parameter-level meaning beyond restating that the operation is keyed by id. It does reinforce the relationship to anyhook_events, but this is not substantial parameter semantics.

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

  Purpose5/5

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

  The description uses a specific verb and resource: 'Full detail for one event by id.' It also distinguishes itself from anyhook_events by stating that it includes the inbound headers and body that anyhook_events omits, plus the destination's response. This makes the tool's purpose immediately unambiguous.

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

  Usage Guidelines5/5

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

  The description gives explicit usage direction: 'fetch one at a time, only when the body is needed.' It also contrasts with anyhook_events, implying that the list endpoint should be used when body detail is not required. The warning about large payloads and personal data further guides responsible invocation.

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

• anyhook_apps_listA
  4.4/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden, and it excels: it discloses that inactive apps answer handshakes but discard event POSTs with 202 and reason app_inactive, that signing secrets are redacted to has_signing_secret plus a 4-char hint (plaintext only via rotation), and that legacyInboundUrls keep routing after a slug change. These are non-obvious behaviors an agent must know to interpret the returned list correctly.

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

  Conciseness5/5

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

  Three dense sentences with zero filler and the core purpose front-loaded in the first sentence. The second sentence explains the operational meaning of isActive, and the third clarifies secret redaction and legacy URL routing — both are decision-relevant. Every sentence earns its place.

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

  Completeness4/5

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

  With no output schema, the description must explain return-value semantics, and it covers the critical fields well: isActive behavior, secret redaction, and legacyInboundUrls handling. The only gap is operational detail such as pagination or result limits, which matters for a list tool but is absent. For a simple one-parameter call, what is present is otherwise sufficient.

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

  Parameters3/5

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

  Schema description coverage is 100%: the only parameter, api_key, is already fully documented, including when it is needed over HTTP, when it is ignored over stdio, and its expected format. Per the rubric, the baseline is 3 when schema coverage is high and the description need not repeat it. The description adds nothing parameter-specific, but none is required.

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

  Purpose5/5

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

  The first sentence names a specific verb and resource ('List apps in your AnyHook account') and enumerates the return contents (inbound URLs, sources, destination URLs). This distinguishes it from sibling mutation/event tools like anyhook_apps_create and anyhook_events at a glance — the agent knows exactly what this tool is for without opening any schema.

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

  Usage Guidelines4/5

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

  The use case is clearly stated up front: this is the read-only account-overview tool that lists apps and their routing/status details. The context is unambiguous enough that an agent knows to reach for this when it needs an inventory of apps or app-level state. However, it does not explicitly disqualify alternatives or name when-not-to-use cases, which prevents a 5.

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

• anyhook_inboxA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden. It discloses the non-obvious email-to-event behavior (mail sent to the address becomes an email.received event) and states the return value, while implying a read-only operation by 'Returns'. It does not cover edge cases like no apps configured, but the core behavior is transparent.

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

  Conciseness5/5

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

  Three sentences, front-loaded with the inbox model, then the concrete return, then the quickstart fallback. No filler or repetition of schema details.

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

  Completeness4/5

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

  The low-complexity tool has no output schema, so the description correctly explains the returned concept (address plus webhook URL) and provides the address pattern and event type. A minor gap is the lack of the exact response field names/shape, but this is not critical for invocation.

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

  Parameters3/5

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

  Both parameters are already documented in the schema with high coverage (app slug source and default, api_key usage over HTTP vs stdio), so the description need not repeat them. It adds the conceptual link that an app's inbox address is derived from the app, but no additional parameter syntax.

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

  Purpose5/5

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

  The description names a concrete deliverable ('the address and webhook URL for one of your apps') and grounds it in a clear model (every app is an email inbox at {user}.{app}@anyhook.net). This differentiates it from siblings like anyhook_events, which reads generated events, and anyhook_quickstart, which provisions an account.

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

  Usage Guidelines5/5

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

  It explicitly routes agents without an account to anyhook_quickstart ('No account yet? anyhook_quickstart returns an inbox_address directly') and points to anyhook_events for reading the resulting email.received events. This is enough for an agent to choose between this and the nearby alternatives.

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

• anyhook_quickstartA
  4.5/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses the ephemeral nature, the auto-connection side effect to the MCP session, the self-deletion of unclaimed workspaces, and the 7-day expiration, which are exactly the behavioral traits an agent needs to know.

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

  Conciseness5/5

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

  Every sentence earns its place: it front-loads the core action, lists return values, explains the claim/expiration lifecycle, and notes the session auto-connect. It is information-dense without being verbose.

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

  Completeness5/5

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

  Despite lacking an output schema, the description explicitly names the three return fields and their meaning. It also covers lifecycle, side effects, and follow-up actions, making the definition complete for an agent to invoke the tool correctly with zero required parameters.

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

  Parameters3/5

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

  Schema description coverage is 100%, and the schema already explains both optional parameters ('source' and 'destination_url'). The description adds no additional parameter-level detail, so the baseline of 3 is appropriate; the schema does the heavy lifting.

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

  Purpose5/5

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

  The description uses a specific verb ('creates'), names the resource (free ephemeral relay endpoint plus API key), and clearly differentiates this from siblings by emphasizing zero-config bootstrap with no signup. It also enumerates the exact return fields, leaving no ambiguity about what the tool does.

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

  Usage Guidelines4/5

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

  The description gives clear usage context: use this when you need a quick, account-free endpoint, then relay the claim_url before the session ends and note the 7-day expiry. It does not explicitly name alternative sibling tools or state when not to use them, but the context is strong enough for an agent to make a reasonable selection.

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