Tulina

lemlist_get_leads

Read-only

List all leads for a campaign with their state (sent, replied…).

⚠️ Goes through the JSON export, NOT get_all_leads: the latter calls the export without state, hence with lemlist's default — which filters everything out and returns an empty list that reads as "no leads". A one-lead campaign thus came back empty (signal 719) while the single-lead route returned it just fine, and the guide announced the forcing as a given for the whole connector. export_campaign_leads carries the default state="all", verified live on 2026-08-31: we take the surface that has the guard rather than rebuild one.

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": {
      "campaign_id": "<campaign_id>"
    },
    "name": "lemlist_get_leads"
  }
}

Input Schema

Name	Required	Description
`_org`	No	Org (id) de CET APPEL. `oto_list_orgs()`.
`_group`	No	Équipe (id) de CET APPEL, sous son org parente.
`_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.
`_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')`.
`campaign_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, and the description is consistent with that. The genuinely useful behavioral disclosure is that the wrong route applies lemlist's default `state` filter and returns an empty list that reads as "no leads" — a real failure mode. However, most of the warning is incident archaeology (signal 719, a verification date, commentary on what "the guide" announced) that describes the connector's history rather than the tool's behavior.

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

Conciseness2/5

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

The first sentence is a clean front-loaded statement of purpose, but roughly two thirds of the text is a maintainer-facing postmortem: a signal number, a live-verification date, and a rationale about taking "the surface that has the guard rather than rebuild one." None of that helps an agent decide or call the tool, and it crowds out what an agent actually needs (pagination, response shape, behavior on unknown campaign).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description should say more about what a lead row contains and whether the list is paginated — it only mentions "state." The required `campaign_id` is left undescribed and the empty-versus-error distinction is raised but not resolved. For a six-parameter list tool the essential call contract is present, but the return-side completeness is thin.

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 description coverage is 83%, so the five `_org`/`_group`/`_run_id`/`_project`/`_instance` context parameters are already documented in the schema and need no help. The required `campaign_id` has no schema description at all, and the description only implies it by saying "for a campaign" — no format, no lookup hint, no statement about what happens when the id is unknown. Baseline 3 fits, with a small unaddressed gap on the one required parameter.

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?

"List all leads for a campaign with their state (sent, replied…)" gives a concrete verb, resource, and the shape of what comes back. It is not fully 5 because the sibling differentiation it offers is against `get_all_leads` and `export_campaign_leads`, neither of which appears in this connector's visible tool list, so the contrast cannot be acted on directly.

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?

The warning effectively tells the agent which internal route to prefer and why the alternative silently yields an empty list, which is real usage guidance. It stops short of an explicit when-to-use/when-not rule against the visible siblings (`lemlist_lead`, `lemlist_get_activities`, `lemlist_campaign`), so an agent still has to guess how to fetch a single lead versus all leads.

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?