Webhooks designed for agents. Create inboxes, wait for events, list and extract them.
Scored across 6 tools
Each tool targets a distinct action: inbox create/delete and event get/list/wait are clearly separated. extract_field is the only slightly fuzzy one — it's a body-parsing helper rather than a fetch, which could momentarily be confused with get_event, but the description clarifies its purpose.
All six tools follow a strict snake_case verb_noun pattern (create_inbox, delete_inbox, extract_field, get_event, list_events, wait_for_event). No style mixing or vague bare verbs.
Six tools is well-scoped for a webhook inbox service, with no filler or redundant entries. Each tool maps to a real workflow step: provision, tear down, read, poll, and parse.
The core lifecycle (create inbox, list/get/wait for events, delete inbox with events) is covered, but there is no get_inbox/list_inboxes to rediscover an inbox since the read token is shown only once, and no way to delete or acknowledge individual events. These are minor gaps an agent can mostly work around.
Create a webhook inbox. Returns its ingest URL and a read token (shown once).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the return payload (ingest URL and read token) and the critical one-time visibility of the token, but says nothing about auth requirements, whether the inbox starts receiving immediately, expiry, or any cap on inbox count.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and followed by the return contract. Nothing is redundant and nothing is buried.
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 and no annotations, so the description must describe the result itself; it names two returned values but omits any inbox identifier and lifecycle details. Adequate to call the tool, but incomplete for an agent that must subsequently use the returned inbox.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate beyond the input schema, and the baseline for a 0-param tool applies. No misleading parameter claims are made.
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 ('Create a webhook inbox'), which is clearly distinct from the read/delete siblings such as delete_inbox, list_events, and wait_for_event. It does not explicitly name or route against those siblings, which keeps it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no prerequisite statement, and no mention of the sibling tools that consume the inbox (wait_for_event, list_events). The usage is only inferable from the verb 'Create'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an inbox and its events. Auth: Authorization Bearer read token header.
| Name | Required | Description | Default |
|---|---|---|---|
| inbox_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full load. It does disclose two useful traits: the operation cascades to events and requires a Bearer read token. However, it omits whether deletion is permanent/irreversible, what happens to related resources beyond events, and error behavior 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?
Two short sentences, front-loaded with the action and its destructive scope, with no filler. The auth sentence is terse but earns its place as the only operational note.
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 single-parameter tool with no annotations and no output schema, the description covers the cascade and auth but leaves irreversibility, preconditions, and the parameter's nature unstated. It is minimally usable but thin for a delete 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 0% and the single parameter inbox_id is undocumented in both schema and description. The description adds no information about the identifier's format or how to obtain it, so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Delete an inbox') plus an important side effect ('and its events'), which clearly separates it from create_inbox and the event-reading siblings. It does not explicitly name a sibling, but the verb makes the intent 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?
There is no guidance on when to use this versus alternatives, no prerequisite checks (e.g., must the inbox be empty), and no caution about when not to call it. An agent must infer everything about the decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pull a JSON path out of an event body. Auth: Authorization Bearer read token header.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | ||
| inbox_id | Yes | ||
| json_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the required Authorization Bearer read token, but it does not state that the operation is read-only, what happens if the JSON path is absent or invalid, or what form the result takes.
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 short sentences with the core action front-loaded and no wasted wording. The auth note is compact and immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three required parameters, zero schema descriptions, no annotations, and no output schema, the description is too sparse. It explains the core action and auth but leaves parameter meanings, return behavior, and failure behavior undocumented.
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 compensate for all three required parameters. It mentions the event body and JSON path conceptually, but does not explain the inbox_id parameter or give format guidance for any 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 states a specific verb and resource: pull a JSON path out of an event body. That is clear enough to distinguish it from the sibling tools, which all deal with inboxes or events rather than field extraction. It does not explicitly name a sibling or scope boundary, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_event or list_events, nor any exclusions or preconditions. The only usage-adjacent information is the auth header requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one event by id. Auth: Authorization Bearer read token header.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | ||
| inbox_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description does add one piece of genuine behavioral context: the read-scoped Bearer token requirement. However, it says nothing about what happens when the event does not exist, whether results are scoped to inbox, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the purpose front-loaded and no filler. The telegraphic "Auth: ..." fragment is dense but functional rather than wasteful.
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?
A tool with two required undocumented parameters, no annotations, and no output schema needs more than one sentence of purpose plus an auth note. The role of inbox_id and the not-found behavior are the main gaps an agent would hit in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate and it only partially does — "by id" clarifies event_id, but inbox_id, which is also required, is never explained as a scoping/tenancy key. Half the required surface remains opaque.
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?
"Get one event by id" states a specific verb and resource plus the lookup key, which implicitly separates it from list_events. It stops short of naming or contrasting with any sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the phrase "by id" suggests fetching a single known event rather than enumerating them. There is no explicit when-to-use, when-not-to-use, or pointer to list_events / wait_for_event for the alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List events in an inbox. Auth: Authorization Bearer read token header.
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | ||
| limit | No | ||
| inbox_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. It usefully discloses the Authorization Bearer read token requirement, but omits pagination behavior, ordering, rate limits, and whether after/limit affect the returned result set, which leaves the read behavior under-described.
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 short sentences with the purpose front-loaded and no filler. The auth sentence is terse but useful, and the definition is concise rather than bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter list tool with no annotations and no output schema, the definition is missing essential context: pagination, filtering, expected result shape, and relationship to sibling read tools. Auth is covered, but not enough to ensure 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 0%, and the description does not explain the after or limit parameters. Only inbox_id is indirectly implied by 'in an inbox,' so the description adds very little meaning beyond the parameter names.
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: list events in an inbox. It clearly distinguishes the tool from create_inbox and delete_inbox, but does not explicitly differentiate it from sibling read tools such as get_event or wait_for_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus get_event or wait_for_event, nor any guidance on pagination or filtering workflow. Usage is only implied by the phrase 'in an inbox' and the list verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for the next event in an inbox after a cursor, up to 30s. Auth: Authorization Bearer read token header.
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | ||
| inbox_id | Yes | ||
| timeout_ms | No | ||
| body_contains | No |
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 does disclose the auth requirement (Bearer read token header) and that the call blocks up to 30s, which is valuable, but it omits what happens on timeout, whether the call is safe to retry, and how the returned event relates to the cursor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the blocking behavior and time cap front-loaded, followed by the auth requirement. Nothing is wasted or buried.
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 no annotations, no output schema, and four undocumented parameters, the definition leaves too much open: the return shape, the timeout result, and the filter semantics. It is insufficient for a blocking, stateful call an agent may need to retry.
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 0%, yet the description explains only two of four parameters in passing: 'after a cursor' maps to after and 'up to 30s' maps to timeout_ms. The required inbox_id and the body_contains filter get no explanation, and no format or default details are added.
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: 'wait for the next event in an inbox after a cursor,' with the 30s cap. This implicitly separates it from get_event/list_events (a blocking pull versus a plain fetch), though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to choose a blocking wait over get_event, list_events, or polling. The 'up to 30s' cap hints at long-poll semantics but does not say whether a timeout is an error, an empty result, or when repeated waiting is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_inboxdelete_inboxextract_fieldget_eventlist_eventswait_for_event
Add one secure layer between your agents and this server.