leadmarina

Export leads to a destination

export_leads

Idempotent

Push leads into a connected destination: 'close' (CRM — uses the account's saved field mapping), 'ghl' (GoHighLevel sub-account), 'google_sheets' (new spreadsheet, or pass spreadsheet_id for one LeadMarina created before), or a file — 'csv' | 'xlsx' | 'json' (emailed to the account owner + download link). Exports EITHER one search's leads (pass search_id) or the whole library (set all=true, optionally narrowed with the same filters as query_leads). LIMITS PER CALL, which differ by destination because CRMs take one API call per lead: csv/xlsx 50,000 · json 25,000 · google_sheets 5,000 · close/ghl 1,000. For a big library going to a CRM, export csv and import the file instead. If more leads match than the limit, the response sets truncated=true — relay that to the user, the export was partial. Previously exported leads are UPDATED in place (matched by Google CID) — never duplicated; the user's own CRM notes/columns are never touched.

Input Schema

TableJSON Schema

Name	Required	Description
`all`	No	Export the whole library instead of one search.
`filters`	No	With all=true: narrow the library using query_leads-style filter rows.
`search_id`	No	Export this search's leads.
`destination`	Yes	Where the leads go.
`spreadsheet_id`	No	google_sheets only: add to this existing LeadMarina-created sheet instead of a new one.

Output Schema

TableJSON Schema

Name	Required	Description
`file`	No	File exports only: the file name.
`note`	No
`limit`	No	The per-call limit that applied, when truncated.
`outcome`	Yes	Human-readable result, e.g. added/updated counts.
`warning`	No	Present when truncated: what happened and how to get the rest.
`exported`	Yes	Leads sent to the destination.
`truncated`	No	True when more leads matched than this destination's limit — the export was PARTIAL.
`download_url`	No	File exports only: 7-day download link.

TDQS

A5/5.0

Behavior5/5

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

Adds extensive behavioral context beyond annotations: per-destination rate limits, file delivery via email/download link, in-place update semantics (never duplicated), preservation of user's CRM notes/columns, and the truncated=true response flag requiring relay to the user. This goes far beyond the basic annotations and concurs with idempotentHint.

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

Conciseness5/5

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

The description is dense but every sentence earns its place, covering purpose, destination details, selection modes, limits, fallback advice, and update behavior. It is logically ordered and front-loads the core purpose before elaborating on constraints.

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?

Given the tool's complexity (multiple destinations, modes, limits, side effects), the description fully prepares an agent: it covers selection, filtering, error/partial export signaling, update semantics, and cross-tool references (query_leads-style filters). The presence of an output schema reduces the need to describe return payloads, and the description covers the remaining operational concerns.

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?

Even though schema coverage is 100%, the description enriches every parameter: clarifies destination enum values (e.g., google_sheets can create new or reuse spreadsheet_id), explains search_id vs all vs filters semantics, and specifies per-destination limits that affect parameter usage.

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 description opens with a specific verb, 'Push leads into a connected destination,' and enumerates all destination types (close, ghl, google_sheets, csv/xlsx/json). It clearly distinguishes the tool from siblings like query_leads or search_leads, which read/query leads rather than export them.

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 explicit guidance on when to use which path: pass search_id for one search, set all=true for the whole library, and use filters with all=true. It also gives an explicit alternative instruction: 'For a big library going to a CRM, export csv and import the file instead' due to per-call limits.

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

All leadmarina tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0

Disambiguation5/5

Each tool has a distinct purpose: search_leads runs live searches while query_leads filters collected leads; create/delete/update_automation form a clear lifecycle; list_* tools target different resources. Descriptions explicitly disambiguate potential overlaps like search/query and list_searches/list_views.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., create_automation, list_integrations, export_leads). The verbs are semantically appropriate (get, list, search, query, create, update, delete, enrich, export) and the pattern is uniform throughout.

Tool Count5/5

13 tools is well within the ideal range and covers the full lead-generation workflow without redundancy. Each tool addresses a concrete need, from searching and enrichment to export and automation management.

Completeness5/5

The tool set covers the entire lifecycle: search_leads and enrich_domains acquire leads, get_search_results and query_leads retrieve them, export_leads pushes them out, and automations re-run searches on schedule. Integration checking and balance are also included, leaving no obvious dead ends or missing essential operations.

Resources

Need Help?