Inspect a specific event

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.

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.

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.

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.

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.

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.