seven-mcp

Official

Overview Schema Source Related Servers Discussions Admin

create_webhook

Register a new webhook to receive event notifications such as SMS delivery reports or MO messages. Specify target URL and event type to trigger callbacks.

Instructions

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "target_url": "<target_url>",
      "event_type": "<event_type>"
    },
    "name": "create_webhook"
  }
}

Input Schema

Name	Required	Description
`target_url`	Yes	Webhook URL to receive events
`event_type`	Yes	Event type to trigger webhook (e.g., sms.mo, dlr)
`request_method`	No	HTTP method for webhook requests
`event_filter`	No	Filter events by phone number or other criteria
`headers`	No	Custom HTTP headers to send with webhook requests. Multiple headers separated by line breaks

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.1May 29, 2026

TDQS

C2.9/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description bears full responsibility for behavioral disclosure. It fails entirely, offering no information about side effects, authentication requirements, rate limits, or what happens after registration (e.g., immediate activation).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no fluff. It is appropriately front-loaded and easy to read. However, it could be slightly more informative without losing brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and annotations, the description is incomplete. It does not explain what the tool returns (e.g., webhook ID), validation rules, or potential errors. For a tool with 5 parameters and no output documentation, more context is needed for an agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with each parameter well-described in the schema (e.g., target_url, event_type with enums). The description adds no additional meaning beyond the schema, which is acceptable per the baseline rule for high coverage. However, no extra clarification is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Register a new webhook' clearly states the action (register/create) and the resource (webhook). It effectively distinguishes from sibling tools like delete_webhook, list_webhooks, and create_contact, making the tool's purpose immediately obvious.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives or prerequisites. There is no mention of conditions such as needing an active account or number, nor any when-not-to-use advice. The description lacks any usage context beyond the bare action.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.