Retrieve a team's webhooks with endpoint URLs, subscribed events, and status. Browse results with cursor pagination.
List the team's webhooks (endpoint, subscribed events, status).
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Cursor: id of the last item of the previous page (forward paging) | |
| limit | No | Page size, 1-100 (default 20) | |
| before | No | Cursor: id of the first item of the previous page (backward paging; not with after) |
Changes observed during successful MCP inspections.
v0.3.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already declares this is a non-mutating read, so the safety profile is covered by annotations. The description contributes the returned field set, which is genuinely useful since there is no output schema, but says nothing about volume, pagination semantics, or auth/scope requirements.
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 front-loaded sentence with no filler; the resource and the payload contents are stated immediately and nothing is repeated from the schema.
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, fully documented, read-only list tool with annotations covering safety and a complete input schema, this is nearly sufficient. The one small gap is that it never signals that results are paginated, though the schema's cursor parameters make that discoverable.
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?
All three pagination parameters are fully documented in the schema (100% coverage), including cursor direction and limit bounds, so the baseline of 3 applies. The description adds no parameter-level meaning beyond that, and none is needed.
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 (List) and resource (the team's webhooks) and even enumerates the key fields returned (endpoint, subscribed events, status), so an agent knows exactly what it gets. There is no sibling webhook tool to distinguish it from, so the only thing keeping it short of a 5 is the absence of any scoping detail (e.g., team-only vs. all).
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 explicit when-to-use statement, no prerequisites, and no mention of alternatives. For a plain list tool the usage is strongly implied by the verb, which matches the 'implied usage' bar, but the description does nothing to clarify context such as when to page versus fetch a single webhook.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.