MCP Server for webhook.site API integration with layered architecture
Scoring was not performed
No documented output schemas for any tool. LLMs cannot plan multi-step operations without knowing what fields to expect (e.g., does get_webhook_info return token, url, created_at, etc?). This forces agents to call tools blindly and guess structure.
Minimal parameter descriptions for core parameters. 'webhook_token' is described only as 'The webhook UUID', no guidance on format, where to obtain it, or what happens if invalid. 'query' in search_requests lacks detail on supported syntax/operators. Parameter descriptions average ~30 chars vs. rubric baseline of 72 chars.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 30 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
No error recovery guidance. When delete_webhook succeeds, what is returned? On failure (e.g., invalid token), does the agent know to call search or get_webhook_info first? No error classification (retryable vs. user-fixable vs. fatal).
Destructive tools (delete_webhook, delete_requests) lack confirmation or dry-run patterns. No indication that these are irreversible. Agents should be warned before calling destructive operations.
Ambiguous parameter relationships in update_webhook. Which fields are optional vs. required? Can you update just default_status without changing timeout? Description does not clarify partial vs. full updates.
create_webhook has empty input schema ({}). No way to specify custom settings without a separate create_webhook_with_config call. Tool descriptions do not guide when to use one vs. the other.
No pagination guidance in get_webhook_requests and search_requests. Do these return all results or are they capped? If capped, what is the limit? Does sorting affect pagination? Missing limit/offset parameter descriptions.
Tool naming could be more consistent. 'get_webhook_url', 'get_webhook_email', 'get_webhook_dns' expose low-level webhook.site concepts (email subdomain, DNS hook domain). Better names might be 'get_webhook_endpoints' or split into domain-specific tools to match user intent.