Dunefox Voice MCP Server

See a sample payload for an event type

get_webhook_samples

Read-only

Fetch recent real webhook events for a chosen type, shaped exactly like live delivery POSTs, so you can build and test a receiver before any production event fires.

Instructions

Recent real events of one type, in the exact shape a live delivery POSTs - useful for building a receiver before anything has fired for real.

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": {
      "event": "<event>"
    },
    "name": "get_webhook_samples"
  }
}

Input Schema

Name	Required	Description	Default
`event`	Yes	e.g. "call.analyzed" or "campaign.status_changed".
`limit`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 28, 2026

TDQS

A3.8/5.0

Behavior4/5

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

readOnlyHint already marks it as a safe read. The description adds that samples are recent real events mirroring live POSTs, which helps the agent understand the data's fidelity and intended test use. It does not cover auth or rate limits.

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

Conciseness5/5

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

A single, tightly written sentence that front-loads what the tool returns and includes only the essential use case.

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

Completeness4/5

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

No output schema exists, so the description usefully characterizes the return shape as identical to a live POST. It remains incomplete about the optional limit parameter, but otherwise covers the tool's purpose and safe read-only nature.

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

Parameters2/5

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

The event parameter has schema examples, but limit has no description in the schema. The tool description never mentions either parameter or explains that limit controls the number of samples returned, so it leaves the limit semantics undocumented.

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

Purpose4/5

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

The title and description convey that it returns sample payloads for a specific webhook event, and the phrase 'exact shape a live delivery POSTs' clarifies the return format. It does not explicitly name sibling tools or contrast with list_webhooks, so it is clear but not fully differentiated.

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

Usage Guidelines4/5

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

The description gives a clear use case: building a receiver before real events have fired. It does not specify when to avoid using it or mention alternatives, but for this narrow testing purpose that context is sufficient.

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