Skip to main content
Glama

List leads

list_leads
Read-only

CRM leads of the active workspace, newest first. Read-only. CRM ONLY: mailing-list / shop contacts are another store (email_marketing_summary) — no CRM leads never means an empty base. Filters: 'status', 'source' ('discovery' = imported prospect, 'quiz' = site quiz), 'created_after' / 'created_before' ('YYYY-MM-DD' inclusive by day, or ISO-8601). Paging: 'limit' (1..100, default 20) + 'offset' (or 'cursor'). Returns {leads: [{id, number, name, company, status, source, created_at}], total (all matching), has_more}. More filters (see each property): 'custom' / 'custom_range' / 'custom_exists' (filterable fields of crm_list_fields, at most 8 conditions), 'q', 'city', 'tags', 'pipeline' + 'pipeline_stage' / 'stage_category', 'has_channel' / 'channel_status'. 'fields' shapes the rows (a pipeline lead always carries pipeline and stage).

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": "list_leads"
  }
}

Input Schema

NameRequiredDescriptionDefault
qNoFree text: company / name / e-mail substring, or an exact phone (any format), domain or ЄДРПОУ.
cityNoThe lead's city (exact, case-insensitive; a list = any of; 'Ки*' = prefix).
modeNo'summary' = counts by status/source + the top 5 rows (a few KB).
tagsNo
limitNo
cursorNonext_cursor from the previous page (instead of offset).
customNoEquality on the workspace's own fields (crm_list_fields), e.g. {"niche": "printing", "site_status": ["none", "broken"]}: a list = any of, 'x*' = prefix; an unknown or non-filterable key → unknown_field.
fieldsNo'custom' / 'tags' ADD that data to each row; any other names keep ONLY those keys (plus id) — e.g. ['company','status'] for a compact list.
offsetNo
sourceNo
statusNo
pipelineNoOnly leads of this pipeline (crm_pipeline_get); 'inbound' = «Вхідні заявки».
has_channelNoLeads that have a contact point of each of these kinds.
custom_rangeNoRanges on number / money_eur / date fields: {"setup_amount": {"gte": 300, "lte": 1000}}.
created_afterNo
custom_existsNoField keys that must have a value.
channel_statusNoContact point status per kind, e.g. {"telegram": "available"} (a list = any of): unverified (nobody checked), available, not_found, unknown, invalid, opted_out.
created_beforeNo
pipeline_stageNoStage slug(s) of 'pipeline' (any of).
stage_categoryNoStage category(ies): sourcing, enrichment, channel_check, proposal, approval, outreach, follow_up, reply, terminal.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

The annotations already cover read-only and non-destructive behavior, while the description adds ordering, default page size, offset/cursor paging, total and has_more return shape, and row-shaping behavior. It also warns that no CRM leads does not mean an empty contact base, which is useful operational context beyond the annotations.

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 definition front-loads purpose and scope, then groups filters, paging, and return shape efficiently for a 20-parameter tool. The phrasing is dense and one warning sentence is confusingly worded, but there is little wasted text.

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?

For a complex, high-parameter listing tool with no output schema, the description supplies the missing return shape, paging model, CRM scope, and important filter semantics. Remaining gaps are minor and largely covered by the input schema.

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?

With 20 parameters and 65% schema description coverage, the description adds meaning for several key inputs: source enum interpretation, inclusive date formats, limit default, custom filter cap, and fields row shaping. It still defers many property-level details to the schema with 'see each property', so it is not fully exhaustive.

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?

The opening sentence names the resource (CRM leads), the workspace scope, and the newest-first ordering, and explicitly distinguishes it from email_marketing_summary for mailing-list or shop contacts. An agent can identify the tool and its scope without opening a sibling 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?

It gives a clear when-not: CRM leads only, with email_marketing_summary named for non-CRM contacts. However, it does not explicitly route between this tool and other lead-oriented siblings such as search_leads or leads_summary, so the guidance is strong but not complete.

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.

Resources