Event-gateway, hookdeck router, and outpost agent skills for Hookdeck webhook handling and event management
This server exhibits severe quality issues across all six tools. Tool definitions are minimalist with critical gaps: (1) Most tool names lack action verbs, 'webhook' and 'verify_hookdeck_signature' are weak (verify is acceptable but webhook is a noun); (2) Descriptions are present but generic and lack LLM-optimization guidance; (3) Input schemas visible but critically incomplete, parameters lack type definitions in most cases (e.g., 'rawBody' typed as 'Buffer' and 'Request' are non-JSON-Schema types); (4) No output schemas documented for any tool; (5) No error handling guidance; (6) Tool definitions appear inferred from example files rather than explicitly registered in an MCP manifest. The codebase shows example implementations in Express, FastAPI, and Next.js, but no clear MCP server registration layer visible. Per HARD SCORING RULES: tools with non-JSON-Schema types cannot score above 30 on schema, and tools inferred rather than explicitly registered cap at 50 overall.
Publish a typed event for a team's tenant. Topic must exist in the Outpost project.
Idempotently ensures an Outpost tenant exists for the given team. Call this whenever a team is created or on first contact.
Verify Hookdeck webhook signature
Verify Hookdeck webhook signature
Hookdeck webhook handler endpoint for receiving and processing events
Hookdeck webhook handler endpoint for receiving and processing events
Input schemas use non-JSON-Schema types (Buffer, Request objects) instead of primitive JSON types. 'rawBody' typed as 'Buffer' and 'request' typed as 'Request' are framework-specific types, not JSON Schema. LLMs cannot validate or construct these inputs.
No output schemas documented for any tool. LLMs cannot plan downstream tool calls or extract the right data without knowing what fields to expect.
Tool names lack clear action verbs. 'webhook' is a noun, not a verb, it should be something like 'handle_webhook' or 'receive_webhook'. 'verify_hookdeck_signature' and 'verifyHookdeckSignature' are acceptable but could be 'validate_*'. Weak naming forces LLMs to read descriptions to understand intent.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 36 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Descriptions are generic and lack LLM-optimization guidance. 'Verify Hookdeck webhook signature' (26 chars) is under the 50-character sweet spot and does not explain WHEN or WHY an LLM should call this tool vs. calling it as middleware. 'Idempotently ensures an Outpost tenant exists...' (79 chars) is better but still lacks example context or dependency hints.
Parameter descriptions are minimal or absent. 'rawBody' described as 'Raw request body' does not explain format, encoding, or expected size. 'signature' lacks explanation of the header name or validation algorithm. 'data' in publishEvent is just 'Event data payload', no schema, no required fields, no type hints for the LLM.
No error handling guidance. If verifyHookdeckSignature fails, the LLM has no direction on whether to retry, ask the user, or treat it as unrecoverable. If publishEvent fails due to a missing topic, there is no recovery hint.
Tool definitions appear inferred from example files in skills/ directories rather than explicitly registered in an MCP manifest. No clear MCP server entry point visible. This violates the explicit registration requirement and suggests the server is not a true MCP implementation yet.
No input validation rules documented. 'teamId' in upsertTenant has no min/max. 'topic' in publishEvent has no length or format constraints. Free-form 'data' object in publishEvent invites hallucinated payloads.
Duplicate tools with naming inconsistency. 'verifyHookdeckSignature' (camelCase) and 'verify_hookdeck_signature' (snake_case) appear to be the same tool. 'webhook' and 'webhook (FastAPI variant)' suggest framework-specific variants rather than a unified tool. LLMs will conflate these and waste reasoning cycles.