MCP Gateway with JSON-RPC, WhatsApp, Twilio & Notion webhooks for lead ingestion, webhook validation, and n8n workflow automation
Server implements 7 tools with mixed quality. Strengths: all tools have descriptions (100-200+ chars), most parameters are typed and described, and the schema structure is present. Critical weaknesses: (1) naming convention violations, 4 of 7 tools lack action verbs (health_ping should be check_health; health_env should be check_env_health; lead_ingest should be validate_and_ingest_lead; n8n_workflow_trigger should be trigger_n8n_workflow). (2) Output schemas are completely undocumented, no tool declares what it returns, making it impossible for LLMs to plan downstream calls or validate responses. (3) Parameter descriptions are inconsistent, some are good (e.g., lead_ingest's source_system enum guidance), but others lack detail (n8n_workflow_trigger's 'payload' is just 'JSON payload to send to n8n webhook' with no structure hint). (4) No error handling guidance, tools provide no recovery hints or error classifications. (5) Two tools (lead_ingest, n8n_workflow_trigger) are write operations but lack confirmation/dry-run patterns. Average per-tool score: 58/100.
Report the MCP gateway environment health: lists any missing required or optional environment variables.
Ping the MCP gateway to check if it is alive and responding. Returns a pong status.
Validate and simulate a lead ingest through the MCP gateway. Creates an OHID (identity) and persists the lead in-memory. Requires source_system, source_lead_id, channel, first_name, and last_name.
POST an arbitrary JSON payload to the n8n workflow webhook URL configured on the MCP gateway. Useful for triggering automation workflows from the agent.
Validate a Notion webhook signature (HMAC-SHA256, Notion-Signature header) against the gateway's NOTION_WEBHOOK_SECRET.
Validate a Twilio webhook request signature (HMAC-SHA1, base64-encoded) against the gateway's TWILIO_AUTH_TOKEN. Parses the payload into a structured Twilio webhook model.
No output schemas documented for any tool. LLMs cannot plan downstream tool calls or validate responses. Missing: return type annotations, field names, and data structures for all 7 tools.
Naming violations: 4 tools lack action verbs. 'health_ping' → 'check_health', 'health_env' → 'check_env_health', 'lead_ingest' → 'ingest_lead', 'n8n_workflow_trigger' → 'trigger_n8n_workflow'. LLMs infer intent from verb prefix.
Write operations (lead_ingest, n8n_workflow_trigger) lack confirmation/dry-run patterns. Agents cannot safely preview consequences before destructive calls. No guidance on idempotency or retry behavior.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 56 | - | v1 |
Validate a WhatsApp Cloud API webhook signature (HMAC-SHA256, X-Hub-Signature-256) against the gateway's WHATSAPP_APP_SECRET. Extracts messages from the webhook payload.
No error handling or recovery guidance in any tool description. Tools lack categorization (retryable vs fatal), no suggestions for next steps on failure (e.g., 'If validation fails, check X-Twilio-Signature matches TWILIO_AUTH_TOKEN'). Agents cannot self-correct.
n8n_workflow_trigger payload parameter lacks structural guidance. Description says 'JSON payload' but does not specify if it should be an object with specific fields, an array, or any shape. LLMs will hallucinate payloads.
lead_ingest accepts 'source_system' and 'channel' as free-form strings despite enum guidance in description. No actual JSON Schema enum constraint, so LLMs can pass invalid values like 'FACEBOOK' or 'EMAIL' and fail at runtime.
Webhook validator tools do not document what constitutes a valid vs invalid signature or what error recovery looks like. If validation fails, should the agent retry? Request a new signature? These patterns are missing.