Tommos

Set a lead's status

set_the_lead_status

Idempotent

Set a lead's status, as the contact page does: new (New), qualified (Qualified), disqualified (Disqualified: a person who does not fit the company's ideal customer, or spam), sql (SQL), client (Client), no_response (No response), not_interested_now (Not interested now: a person who fits, and does not buy now). not_interested_now holds the lead's job until look_again_on; with no date, Tommo names it now. Disqualified, no_response or client ends every open job on the lead; disqualified also cancels the future meetings with the lead named in meetings_shown, and Google tells each guest; a future meeting not named there, or one the calendar refused to cancel, comes back as an error with its key, and the status is written; new, qualified or sql opens the lead's job when none is open (a person working it by hand). While the lead has an open deal, the status follows the deal: only sql passes, and any other is refused in words. The change is on the lead's timeline under whoever made it.

Input Schema

Name	Required	Description
`status`	Yes
`because`	No	Why, in a few words, for the timeline
`contact_id`	Yes	The contact's id
`look_again_on`	No	With not_interested_now only: the date Tommo looks at the lead again, as 2027-02-16, a day still ahead
`meetings_shown`	No	With disqualified: the keys of the future meetings to cancel, as an earlier answer named them

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 23, 2026

addedInput schema / properties / look_again_on

Added value: +{
+  "description": "With not_interested_now only: the date Tommo looks at the lead again, as 2027-02-16, a day still ahead",
+  "type": "string"
+}

changedInput schema / properties / status / enum

Previous value: -[
-  "new",
-  "qualified",
-  "disqualified",
-  "sql",
-  "client",
-  "no_response"
-]New value: +[
+  "new",
+  "qualified",
+  "disqualified",
+  "sql",
+  "client",
+  "no_response",
+  "not_interested_now"
+]

Changed1 schema field changedOct 19, 2026

addedInput schema / properties / meetings_shown

Added value: +{
+  "description": "With disqualified: the keys of the future meetings to cancel, as an earlier answer named them",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

First observedOct 7, 2026

TDQS

A3.7/5.0

Behavior1/5

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

The description says disqualified "cancels the future meetings" and "Google tells each guest," which indicates destructive external side effects. The annotations declare destructiveHint=false and openWorldHint=false, directly contradicting those behavioral claims.

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 purpose is front-loaded and nearly every sentence conveys distinct behavioral information about statuses, side effects, or deal constraints. However, the description is a single dense paragraph that would be easier to scan with structure or bullets.

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?

Given the tool's complexity, the description is complete enough: it covers status meanings, conditional parameters, destructive side effects on meetings, guest notification behavior, error outcomes, deal constraints, and timeline recording. No output schema exists, so the level of return-behavior detail provided is appropriate.

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

Parameters5/5

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

The description adds substantial meaning beyond the schema: it defines every status value, explains that look_again_on applies only to not_interested_now, specifies meetings_shown for disqualified, and clarifies when status changes are refused due to an open deal. This goes well beyond the 80% schema coverage.

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 description states a specific verb and resource: "Set a lead's status," and enumerates the exact status values, making the core action unambiguous. It does not explicitly distinguish this from sibling tools such as update_contact, so it stops short of full sibling differentiation.

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 gives clear context for when each status applies and includes a key exclusion: "While the lead has an open deal, the status follows the deal: only sql passes, and any other is refused in words." It also conditions look_again_on and meetings_shown on specific statuses, but does not name alternative tools or explicitly say when not to use this tool versus update_contact.

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

All Tommos 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.

Set a lead's status

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources