Sergio by Serviche

Record a lead's outcome

set_lead_outcome

Idempotent

Records what happened with a lead, as the lead card's Close menu and taps do. tap: quoted (they have a price); booked (closes it won, on the booking when one for them exists, else on your word); confirmed_booked (the same as booked); call_back_on (date YYYY-MM-DD, or at as an ISO time: pauses the lead until then; the pause ends by itself on that date, when a message goes either way, or when a step's date is changed); not_interested (lost; lostReason is one of "Timing / availability", "Price", "Went elsewhere / not needed", "Out of scope / area", or their own words for Other; a lead that just went quiet is not lost, it goes cold on its own); keep_pursuing; acknowledge_reply (their last message needs no answer: follow-ups resume); tracked_by_mistake; dismiss_plan; replied_on_site (stepKey: the Reply step answered on a lead site); undo_close (reopens a lead Sergio closed on its own, so the same evidence never closes it again; a contact made not-a-lead becomes a lead again, and Quo follows when the business's write setting allows). Nothing is sent. Pass the same idempotency_key when retrying.

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": {
      "task_id": "<task_id>",
      "tap": "<tap>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "set_lead_outcome"
  }
}

Input Schema

Name	Required	Description
`at`	No
`tap`	Yes
`date`	No
`stepKey`	No
`task_id`	Yes
`lostReason`	No
`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.1/5.0

Behavior5/5

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

Goes well past the annotations: states 'Nothing is sent', explains that call_back_on pauses the lead and the exact conditions that end the pause, that not_interested marks a lead lost, and that undo_close reopens Sergio-closed leads so the same evidence never closes them again, plus the Quo write-setting caveat. These are real state-transition consequences an agent could not infer from readOnlyHint=false / idempotentHint=true alone.

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

Conciseness3/5

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

Front-loaded and free of filler, but the bulk is one long run-on with deeply nested parentheses that makes it hard to scan for a single tap. The content earns its place; the layout does not.

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?

Strong coverage of a complex mutation: state effects, pause semantics, idempotency retry instruction, and per-tap conditions. What is missing is any hint at what the call returns or what 'booked' does when no booking record exists, plus the meaning of task_id, and there is no output schema to fill those gaps.

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?

With only 14% schema description coverage, the description carries the burden and largely succeeds: it defines every tap value, the date/at formats for call_back_on, the allowed lostReason values plus an open 'their own words for Other' option, and what stepKey denotes. The gap is task_id, which is never identified as the lead identifier, leaving the primary addressing parameter unexplained.

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?

Opens with a specific verb and resource ('Records what happened with a lead') and anchors it to the product's own UI ('as the lead card's Close menu and taps do'), which makes the intent unmistakable. It does not explicitly name a sibling it is not (e.g. disposition_conversation, move_lead_journey, track_conversation_as_lead), so differentiation is left to the tap vocabulary.

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?

Gives concrete when-to-use rules per tap, including non-obvious ones: 'a lead that just went quiet is not lost, it goes cold on its own' steers away from not_interested, and 'the pause ends by itself ... when a message goes either way' clarifies call_back_on. It does not point to alternative tools such as hold_lead_follow_ups or acknowledge_reply vs keep_pursuing trade-offs beyond the inline hints.

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?