Skip to main content
Glama

Metadata MCP Connector

Get Converted Leads Summary (Smart Leads aggregates)

get_converted_leads_summary
Read-only

Read aggregate counts and rates for the account's converted leads using optional date, campaign, channel, and audience filters. Returns totals, MQL rates, unique leads and domains, channel mix, enrichment and marketing-automation coverage, and triggered/influenced opportunity aggregates where available. No individual lead rows are returned. This summary can establish a baseline for lead analysis; get_converted_leads provides paginated rows where access permits.

Input Schema

NameRequiredDescriptionDefault
idsNoRestrict the summary to specific lead IDs.
emailNoFilter by lead email (partial match).
adNameNoFilter by the ad (library) name that captured the leads (partial match).
syncMANotrue = only leads synced to marketing automation; false = only unsynced.
tagIdsNoFilter by tag IDs on the leads' experiments.
endDateNoLeads created on/before this date. ISO 8601; date-only is accepted.
keywordNoFilter by the exact search keyword that captured the leads.
channelsNoFilter by acquisition channel(s).
jobTitleNoFilter by lead job title (partial match).
lastNameNoFilter by lead last name (partial match).
statusesNoLead statuses to include. The platform Leads tab defaults to ACTIVE. Omit to include all.
companiesNoFilter by exact company names.
countriesNoFilter by exact lead country names.
firstNameNoFilter by lead first name (partial match).
offerNameNoFilter by the offer name tied to the leads' experiments.
startDateNoLeads created on/after this date. ISO 8601; date-only is accepted.
matchTypesNoFilter by keyword match type (search channels).
modifiedByNoFilter by the platform user email who last modified the leads (partial match).
campaignNameNoFilter by campaign name (partial match).
contentTypesNoData-completeness filter: only leads that HAVE this content.
qualityTypesNoQuality-signal filter (opportunities, MQL date/score).
audienceTypesNoFilter by audience type of the leads' experiments (e.g. FIRMOGRAPHIC_INCLUDE, CONTACT_LIST, BUYER_INTENT, NATIVE_LINKEDIN).
isAutoUpdatedNotrue = only auto-enriched leads.
businessEmailsNoFilter by exact business email addresses (OR within the list).
experimentNameNoFilter by experiment name (partial match).
isFullyEnrichedNotrue = only fully enriched leads; false = only not fully enriched.
isManuallyUpdateNotrue = only manually enriched/edited leads (platform parameter name is 'isManuallyUpdate').
customAudienceNameNoFilter by targeted audience name (partial match).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds real context beyond that: enumerated return categories, the caveat that some opportunity aggregates exist only 'where available', and the no-row guarantee.

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?

Four sentences, front-loaded with the purpose before the return summary and the sibling comparison. The return-field enumeration is somewhat list-like but each clause maps to a distinct aggregate group, so little is wasted.

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 and 28 parameters, the description usefully enumerates the return contents (totals, MQL rates, channel mix, enrichment coverage) and flags conditional availability. It could say more about default filtering behavior, but covers what the structured fields do not.

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% across all 28 optional parameters, so the schema carries the burden. The description only broadly characterizes filter families (date, campaign, channel, audience) and adds little syntax or filtering-behavior detail beyond the schema.

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 (read aggregate counts and rates) and resource (the account's converted leads), and explicitly names what it is not: 'No individual lead rows are returned.' This cleanly separates it from row-returning siblings and the referenced get_converted_leads.

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?

Names the alternative ('get_converted_leads provides paginated rows where access permits') and positions this tool as a baseline for lead analysis, giving a clear selection cue. No explicit 'when not to use' beyond that, keeping it short of a 5.

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