Skip to main content
Glama

Research a signal lead and write their messages

research_signal_lead

Researches one signal lead and drafts their texts (a connection note and follow-ups, or an opening note for an existing connection), the same way the Signals tab does. Spends no credits: drafting on the Signals tab is free (owner 2026-10-22); researching a lead for a campaign is what costs a credit. Every lead always gets drafts: when research or a draft does not pass the checks, they are written about the person only, and with no AI available from a plain template using their own details. When the lead already has drafts, returns them as they are. A confirm_token from an older preflight is accepted and ignored. Nobody is contacted.

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": {
      "lead_id": "<lead_id>"
    },
    "name": "research_signal_lead"
  }
}

Input Schema

NameRequiredDescriptionDefault
lead_idYesThe lead id, from search_signal_leads.
confirm_tokenNoNot needed any more (no credit is spent); accepted and ignored.
idempotency_keyNoOptional. 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.

  1. Added
  2. Removed
  3. Added

TDQS

A4.1/5.0
Behavior4/5

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

Adds substantial behavior beyond the annotations: no credits are spent, a failed research/draft check still yields a template draft from the person's own details, existing drafts are returned unchanged, and 'Nobody is contacted.' The annotations only declare a non-read-only, non-destructive, closed operation, so this description earns its credit.

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-loads what the tool does and the key fact (free, always produces drafts) before the edge cases. It is slightly dense — the credit explanation and its dated justification could be tightened — but no sentence is filler.

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 no output schema, the description does some of that work by explaining that drafts come back as-is or as template fallbacks. What it lacks is any sense of the response shape (single draft object, list of follow-ups, IDs), which is the main remaining gap for a tool with no output schema.

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

Parameters3/5

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

Schema coverage is 100%, so lead_id, confirm_token and idempotency_key are already fully documented in the schema, including the 'accepted and ignored' note. The description adds nothing about parameter formats beyond what is already structured, which matches the baseline 3.

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 ('Researches one signal lead') plus the concrete artifact produced ('drafts their texts (a connection note and follow-ups, or an opening note for an existing connection)'). That output framing is enough to separate it from retrieval siblings like get_signal_lead or search_signal_leads without opening either schema.

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 clear context for calling: it is free, every lead always gets drafts, and when drafts already exist they are returned as-is rather than regenerated. It does not explicitly route the agent elsewhere for editing an existing draft (e.g. set_lead_messages), so the alternative path is left implicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.