Sergio by Serviche

Start a campaign (after your person confirms)

start_campaign

Idempotent

Starts a draft or paused campaign on your person's order, as Start campaign does: it enrolls the people waiting and drafts their first message; starting sends nothing by itself. First call without confirm_token: nothing changes; you get a preview (every message's exact words, how many people it reaches now, the audience rules, and whether the business's Sending lets a person's messages go out) and a confirm_token. Show your person the preview word for word, and only after they say yes, call again with the same arguments and the SAME idempotency_key, plus confirm_token. If the preview says Sending is switched off, tell your person that plainly with the link; only the owner turns it on, in Sergio, and you never change it. A campaign with a message Sergio sends on its own is the owner's to start, in the app. To send the drafted messages once it has started, use send_campaign_messages.

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": {
      "campaign_id": "<campaign_id>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "start_campaign"
  }
}

Input Schema

Name	Required	Description
`campaign_id`	Yes
`confirm_token`	No	From the preview, after your person said yes. Leave it out to get the preview.
`idempotency_key`	Yes	Your id for this operation (8-128 of A-Z a-z 0-9 . _ : -). Reuse it on every retry of the same operation; use a new one for a new operation.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare non-read-only, idempotent, non-destructive, open-world, but the description adds what those hints cannot: the first call is a true no-op, starting itself sends nothing, the preview enumerates message wording, reach count, audience rules and Sending status, and the idempotency key must be reused across the preview-to-confirm transition. It also discloses the escalation path when Sending is off, which is behavioral context absent from any structured field.

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 its side effect, then the two-phase procedure, then the edge cases and sibling handoff. Every sentence carries operational weight, though a few phrases ('as Start campaign does', 'in Sergio') add product jargon that slightly slows parsing.

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

Completeness5/5

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

There is no output schema, so the description compensates by enumerating exactly what the preview returns, and it covers preconditions, confirmation gating, permission limits, and the next-step tool. For a confirmation-gated mutation with three parameters, nothing an agent needs in order to call it safely is missing.

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 67% and both optional-mechanism parameters already have inline descriptions, but the description adds non-obvious cross-call semantics the schema does not: the same idempotency_key and the same arguments must be reused on the confirm call, and confirm_token only exists after a preview. campaign_id is left implicit, which is a minor gap given it is the obvious required UUID.

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?

States a specific verb and resource plus the precondition state: 'Starts a draft or paused campaign on your person's order.' It also immediately discloses the side effect ('it enrolls the people waiting and drafts their first message') and explicitly distinguishes itself from send_campaign_messages, so an agent can separate it from create_campaign, edit_campaign, and send_campaign_messages without opening any schema.

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

Usage Guidelines5/5

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

Gives a full decision procedure: first call without confirm_token to get a preview, show it to the person word for word, only call again after an explicit yes with the same arguments plus confirm_token. It also names exclusions — campaigns with an autonomous Sergio message are the owner's to start in the app, and Sending being off is an owner-only action — and routes to send_campaign_messages for the follow-up step.

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

All Sergio by Serviche 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?