Tulina

lemlist_lead

Lead lifecycle inside a campaign — read, edit, pause, qualify, remove. oto_guide op=read slug="lemlist-playbook": build order, where each id comes from, and the doc↔API gaps.

A LEAD is a person's copy inside ONE campaign (its sending state, its variables); the person themself is a contact (lemlist_contact). Creating a lead is lemlist_create_lead; releasing one held for review is lemlist_launch_lead.

Args by op:

get: lead_id or email. list: campaign_id + optional state (sent, replied, paused…) and limit. ⚠️ state defaults to "all" HERE, which is NOT lemlist's own default: without it the API filters everything out and returns an empty list that reads as "no leads on this campaign". Pass a state only to narrow deliberately.
update: campaign_id + lead_id + fields (firstName, lastName, companyName, jobTitle, preferredContactMethod).
delete: campaign_id + lead_id/email — really removes it. unsubscribe: same arguments, but the lead STAYS on the campaign, marked unsubscribed. One lemlist route serves both, and its default is the soft one; here the two are named apart so neither is a surprise.
pause: lead_id; WITHOUT campaign_id it pauses the lead in EVERY campaign, not one. resume: lead_id — undoes a pause, so lemlist starts sending to that lead again (it does not skip a review; that is lemlist_launch_lead).
interested / not_interested: lead_id or email; with campaign_id it applies to that campaign, without it to all.
vars_update: lead_id + variables. vars_delete: lead_id + variable_names (the values are erased).
import_crm: campaign_id + crm + user_id + filter_id (from lemlist_team(op="crm_filters")), optional filter_type, deduplicate.
upload_audio: lead_id + step_id + audio — the audio of a linkedinVoiceNote step. audio is a source dict: {"kind": "url", "url": …}, {"kind": "drive", "file_id": …}, {"kind": "gmail", "message_id": …, "filename": …}, {"kind": "project_file", "project_id": …, "file_id": …} or a recording's source as read ({"kind": "transit", "ref": …}). The server fetches it (≤ 20 MB) and forwards the bytes.

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": {
      "op": "<op>"
    },
    "name": "lemlist_lead"
  }
}

Input Schema

Name	Required	Description
`op`	Yes
`crm`	No
`_org`	No	Org (id) de CET APPEL. `oto_list_orgs()`.
`audio`	No
`email`	No
`limit`	No
`state`	No
`_group`	No	Équipe (id) de CET APPEL, sous son org parente.
`fields`	No
`_run_id`	No	OBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
`lead_id`	No
`step_id`	No
`user_id`	No
`_project`	No	Projet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
`_instance`	No	Instance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
`filter_id`	No
`variables`	No
`campaign_id`	No
`deduplicate`	No
`filter_type`	No
`variable_names`	No

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does unusually well: it discloses the non-obvious `state` default that silently yields an empty list, that `delete` is destructive and `unsubscribe` is soft, that `pause` without `campaign_id` affects every campaign, that `vars_delete` erases values, and that `upload_audio` fetches ≤ 20 MB server-side. It does not cover permission/auth requirements or rate limits, and there is no output schema to fall back on for return shape.

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 a one-line summary and guide pointer, then organized as a scannable per-op bullet list where each line is actionable. Some prose is wordier than needed (e.g. the sentence explaining why delete and unsubscribe are named apart), but given 13 ops and 21 parameters the length is largely justified.

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?

For a 13-op dispatcher with no annotations and 24% schema coverage, the definition covers calling correctness thoroughly: argument mapping per op, destructive semantics, defaults, and file-size limits. The main gap is return values — with no output schema, nothing tells the agent what `get`/`list`/`import_crm` hand back, nor how the per-op error surface behaves.

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?

Schema coverage is only 24% across 21 parameters, so the description must compensate — and it does: every op is mapped to its required arguments, `state` values are exemplified (`sent`, `replied`, `paused`), `fields` enumerates the writable keys, `variable_names` is explained as erasing values, and the `audio` source dict is spelled out in all five `kind` variants. This adds substantial meaning the bare schema does not carry.

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?

Opens with a specific verb set and resource: "Lead lifecycle inside a campaign — read, edit, pause, qualify, remove." It then defines the entity precisely (a lead is a person's copy inside ONE campaign; the person is `lemlist_contact`) and names the siblings that handle adjacent operations (`lemlist_create_lead`, `lemlist_launch_lead`), so an agent can separate this tool from neighbors without reading schemas.

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?

Provides per-op argument guidance for all 13 ops plus explicit when-to-use discrimination: `delete` vs `unsubscribe` (one really removes, the other keeps the lead on the campaign), `pause` vs `resume` vs `lemlist_launch_lead` (resume does not skip a review). It also points at `oto_guide op=read slug="lemlist-playbook"` for build order and flags the `state` default trap, which is exactly the kind of routing an agent needs.

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

All Tulina 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?