ZenMode

Find new signal leads (spends credits)

find_signal_leads

Looks for new people showing buying intent, from every source Signals watches, as the Signals tab's "Find leads" does, in two calls. 1 credit = 1 person found. Researching a lead for a campaign costs 1 credit more, whether or not Signals found them, and is given back if the research does not end in a researched note. Drafting a lead's note and follow-ups on the Signals tab (research_signal_lead) costs nothing. Pass people: how many new people to look for (25, 50 or 100 or any number; default 50; never more than the credits left pay for). Without confirm_token it only runs a preflight and spends nothing: it returns the count, what it can cost, the credits left, the most people the credits cover and a confirm_token (valid 10 minutes, tied to this account and that count). With that confirm_token it searches. The search runs in the background on ZenMode's side and keeps searching, up to the number of people agreed, after the person leaves the Signals tab or this conversation; leads appear in their Signals list as they are found. The answer says status "running" with a progress line to tell the person, and calling again with the same confirm_token only reads its progress (it spends nothing more). If it cannot run in the background, it reads one source per call and answers done: false while more remain; the same confirm_token continues the same search for up to 30 minutes. Either way it never spends past the agreed figure. At 0 credits no token is issued and the answer says where to get more. Nothing is added to a campaign and nobody is contacted.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "find_signal_leads"
  }
}

Input Schema

Name	Required	Description
`people`	No	How many new people to look for. Default 50; held to what the credits left pay for. Each person found costs the find credit (lib/credits.ts).
`max_credits`	No	Older name for people, still accepted. people wins when both are given.
`confirm_token`	No	From the preflight, only after the person said yes.
`idempotency_key`	No	Optional. A unique string you make up for this exact change (8 to 128 letters, digits, - _ . :). If the call is repeated with the same key and the same arguments within 24 hours, nothing happens twice and the first result is returned again. Use a fresh key for every new change.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026
RemovedOct 25, 2026
AddedOct 25, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only say readOnlyHint=false and destructiveHint=false, which does not convey the credit economy or the two-phase protocol. The description goes well beyond that: 1 credit per person found, a refundable extra credit for research, the preflight-spends-nothing guarantee, a 10-minute account-and-count-bound token, background continuation after the user leaves, progress-only re-calls, and a hard 'never spends past the agreed figure' cap. That is exactly the behavioral context an agent needs before spending a user's credits.

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 text is long but front-loads purpose and cost before mechanics, and nearly every sentence carries operational information (cost, token validity, fallback, progress polling). It is a single undifferentiated block, though, and the sentence about research credits being refunded mixes in a sibling tool's pricing in a fairly convoluted way; paragraph breaks or bullets would improve scanability.

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, and the description compensates fully: it enumerates the preflight return (count, cost, credits left, max people covered, confirm_token), the running response (status 'running' plus a progress line), the fallback response (done: false), and the zero-credit response. For a mutating, credit-spending, two-phase tool, nothing an agent needs to call it correctly appears to be 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 100%, so the baseline would be 3, but the description adds real meaning: it explains what people means behaviorally (default 50, capped by remaining credits, e.g. 25/50/100) and, critically, the confirm_token lifecycle (issued by preflight, valid 10 minutes, bound to account and count) that the schema only hints at. The remaining parameters, max_credits and idempotency_key, are left entirely to the schema, which is acceptable given its quality.

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 first sentence names a specific verb and resource ('looks for new people showing buying intent, from every source Signals watches') and ties it to the Signals tab's 'Find leads', so it is clearly a discovery/prospecting tool. It also contrasts itself with research_signal_lead (free drafting) and distinguishes 'new people' from the existing-lead tools. It stops short of explicitly naming search_signal_leads as the sibling for already-known leads, leaving that disambiguation to the agent.

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?

Usage is fully spelled out: call without confirm_token to run a free preflight, then call again with the token only after the person agreed, and calling again with the same token merely reads progress. It states the fallback path (one source per call, done: false, 30-minute window), the 0-credit case, and explicitly what this tool never does ('Nothing is added to a campaign and nobody is contacted'). There is essentially no ambiguity about when to invoke it or what the alternative is.

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

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