Cito API

test_webhook

Send a test to a webhook now and report what happened: status, statusCode, latencyMs and a plain-English diagnosis to relay. With event, sends a real recent sample of that event, signed and marked as a test (test: true, data.test: true, X-Cito-Test: true); without it, a short ping. API calls: 1.

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": {
      "id": "<id>"
    },
    "name": "test_webhook"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	The webhook id, from list_webhooks or create_webhook. Never invent one.
`event`	No	Event to sample, from list_webhook_events.

Output Schema

Name	Required	Description
`ok`	Yes	true if the tool succeeded
`data`	No	Result payload when ok is true; null on error
`meta`	Yes
`error`	No
`partial`	No
`pagination`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4/5.0

Behavior4/5

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

Beyond the annotations (destructive=false, openWorld=true), it discloses that real signed payloads leave the system, that they are flagged as tests in both body and header, and that it costs exactly one API call. It does not say whether a failed test is recorded in webhook_deliveries or whether latency is measured server-side, which is the remaining behavioral gap.

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?

Front-loaded with the action and the outcome, then the event/no-event branch, then the cost figure. Dense but every clause carries information; only the nested parenthetical of test flags is slightly cramped.

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?

With an output schema present, the description needn't enumerate return fields, and it still names them in passing. Both parameters are covered and the test-payload semantics are explained; only failure handling and interaction with delivery history are left unstated.

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

Parameters4/5

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

Schema coverage is already 100%, but the description adds real meaning the schema lacks: the semantic consequence of supplying event (a signed, recent sample of that event type) versus omitting it (a short ping). That is a conditional behavior, not a restatement of the field docs.

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?

"Send a test to a webhook now and report what happened" gives a specific verb (send test) and resource (webhook), and the test-marking detail (test: true, X-Cito-Test: true) distinguishes it from replay_webhook and webhook_deliveries without naming them. Naming the closest sibling explicitly would push this to a 5.

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?

It clearly states the branch condition: pass event for a real sampled payload, omit it for a short ping. What is missing is routing guidance against alternatives like replay_webhook or explain_webhook_setup, so the agent must infer when a test is preferable to a replay.

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

All Cito API tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?