Verified local-business leads: search any niche + city, query your library, export to your CRM.
Create an automation: re-run a search on a schedule and send the results somewhere automatically. Pass cities as plain strings (e.g. ['Austin, TX', 'Dallas, TX']) — they're resolved for you. IT SPENDS LEADS ON EVERY RUN, one per result, so confirm the niche, cities and cadence with the user before creating one. A destination of 'close', 'ghl' or 'google_sheets' requires that integration to be connected already (Close also needs one manual export first to save its field mapping); 'csv' | 'xlsx' | 'json' emails a file and needs nothing set up. Up to 20 automations, 25 cities each.
| Name | Required | Description | Default |
|---|---|---|---|
| cities | Yes | Cities to search, e.g. ['Austin, TX'] (max 25). | |
| cadence | Yes | How often it repeats. | |
| keyword | Yes | The niche to search, e.g. 'roofing contractor'. | |
| start_at | No | ISO timestamp for the first run. Defaults to now (runs on the next tick, within 15 min). | |
| destination | No | Where each run's leads go. 'none' just saves them to the library. | |
| spreadsheet_id | No | google_sheets only: append to this existing LeadMarina-created sheet. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| note | No | |
| cities | No | |
| cadence | No | |
| keyword | No | |
| destination | No | |
| next_run_at | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a write operation with open world implications, but the description goes further by disclosing that each run spends leads (one per result), which is a critical side effect. It also reveals nuances like 'Close also needs one manual export first to save its field mapping' and that 'csv' | 'xlsx' | 'json' require no setup, adding substantial behavioral 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long and front-loaded with the primary purpose. It packs in essential warnings and limitations without excessive fluff, though the capitalized warning sentence ('IT SPENDS LEADS ON EVERY RUN...') may be slightly jarring but effectively emphasizes the risk. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with an output schema, the description covers all major aspects: what the tool does, cost implications, integration requirements, and limits. It does not need to explain return values because the output schema exists. The inclusion of the 20-automation limit and 25-cities-per-run cap adds important context that would otherwise be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds extra meaning by clarifying that cities can be passed as plain strings and are resolved automatically, and by explaining that certain destinations require existing integrations while others do not. This goes beyond the schema's basic descriptions, though it does not cover every parameter in equal depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Create an automation: re-run a search on a schedule and send the results somewhere automatically,' which uses a specific verb (create) and resource (automation) and explains the core functionality clearly. It distinguishes from sibling tools like delete_automation, update_automation, and list_automations by focusing exclusively on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: it creates scheduled recurring searches and requires user confirmation due to lead spending. It also mentions integration prerequisites and limits (up to 20 automations). However, it does not explicitly name alternatives (e.g., update_automation for modifying existing automations), so it stops 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.
Permanently delete an automation. This cannot be undone — confirm with the user first, and prefer update_automation with active=false if they only want it to stop for now. Leads already collected by past runs are kept; only the schedule is removed.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The automation id from list_automations. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| note | No | |
| deleted | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and readOnlyHint=false, but the description adds substantial context: the deletion is irreversible, leads already collected are retained, and only the schedule is removed. This goes well beyond the annotations and fully discloses the operational impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly written sentences, each earning its place: the first states the action, the second adds critical safety guidance, and the third clarifies behavioral consequences. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive mutation, the description fully covers prerequisites (confirmation), alternatives (disable instead of delete), effects (schedule removed, leads kept), and irreversibility. An output schema exists, so return-value details are not required. The description is self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single required parameter, id, and explicitly states it comes from list_automations. The description does not add parameter-specific details, but with complete schema coverage the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Permanently delete an automation,' using a specific verb and resource while clearly distinguishing this from the sibling update_automation. It also clarifies the destructive nature, leaving no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool and when not to, recommending update_automation with active=false as a less destructive alternative for temporary suspension. It also instructs the agent to confirm with the user first, providing direct guidance for safe invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Already have businesses? Pass up to 10 website domains to run the full enrichment + verification pipeline on them (verified emails + phones, owner name, socials). Costs 1 lead per domain. Returns a search_id to poll with get_search_results.
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes | Business domains, e.g. ['acme.com'] (max 10). |
| Name | Required | Description |
|---|---|---|
| enriching | Yes | Domains accepted (balance-capped). |
| next_step | No | |
| search_id | Yes | |
| enrichment | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the mutability hints, and the description adds important behavioral details: the cost of 1 lead per domain, the asynchronous nature (returns a search_id to poll), and the pipeline stages (enrichment + verification). This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each carrying distinct information: the use case, the pipeline outputs, and the cost/return behavior. It is front-loaded with the main purpose and contains no filler words or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no nested objects, and an output schema, the description covers the input constraints, the processing pipeline, the cost, and the follow-up mechanism (get_search_results). It is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'domains' parameter, which already includes an example and maximum count. The tool description restates the 10-domain limit but does not add extra semantics beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enriches up to 10 business domains by running a full enrichment + verification pipeline, listing specific outputs (verified emails, phones, owner name, socials). It distinguishes itself from sibling tools like search_leads by focusing on existing domains rather than querying for new leads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening 'Already have businesses?' sets the use case for enriching existing domains, and the mention of cost per domain and polling with get_search_results gives operational context. It does not explicitly exclude alternatives or state when not to use, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| 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. |
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.
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.
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.
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.
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.
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.
What the account has left, and when it resets. On a plan with a rate limit (no monthly quota) this is the leads left in the current 7-day period; on a metered plan it is the monthly allotment remaining.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | No | |
| plan | Yes | |
| period_used | No | |
| period_limit | No | |
| leads_remaining | Yes | |
| period_resets_at | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds valuable context: it explains the reset behavior and how balance differs by plan type, going beyond the binary annotations. No contradiction; it enriches understanding of the tool's output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly worded sentences, with the core purpose ('what the account has left, and when it resets') front-loaded. The second sentence clarifies plan-specific nuances without redundancy. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema available, the description fully covers what the tool does and how to interpret the result. It clarifies reset timing and plan distinctions, leaving no ambiguity about the return value's meaning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so baseline is 4 per rubric. The description adds no parameter details because none exist, but it effectively explains what the returned value represents, which is more relevant than parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: reporting remaining lead balance and reset timing. It distinguishes between rate-limited (7-day period) and metered (monthly) plans, providing specificity beyond the title. No sibling tool covers balance queries, so it stands apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: check balance to know remaining leads before operations. It does not explicitly contrast with alternatives, but given the sibling list contains no similar tools, that omission is acceptable. It clearly explains when the value applies (current period) without needing exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a search's leads with verification filled in as enrichment progresses. Poll until enrichment is 'complete'. Each lead includes verified emails (SMTP status), verified phones (line type + carrier), owner name where identified, socials, and the business profile.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max leads to return (default 25, max 1000). | |
| offset | No | Pagination offset (default 0). | |
| search_id | Yes | The search_id returned by search_leads or enrich_domains. |
| Name | Required | Description |
|---|---|---|
| query | No | |
| stage | No | queued | discovering | enriching | verifying | complete | failed | cancelled. 'verifying' means every row is delivered and contacts are being verified — often the longest phase, not a stall. |
| period | No | On a rate-limited plan: { limit, used, resets_at }. Null on a metered plan. |
| results | Yes | |
| showing | No | Range shown, e.g. '1–25'. |
| location | No | |
| progress | No | { done, total } rows enriched so far. |
| search_id | Yes | |
| enrichment | Yes | 'pending' or 'complete'. |
| next_offset | No | Pass as offset to fetch the next page; null on the last page. |
| total_leads | Yes | |
| queue_position | No | For queued searches, the place in this account's own queue (1 = next). |
| leads_remaining | No | Leads spendable now. On a plan with no monthly quota this is what is left in the current 7-day period, not a monthly balance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and non-destructive annotations, the description adds significant behavioral detail: it discloses the asynchronous nature of enrichment, instructs the agent to poll, and explains what data becomes available. This helps the agent understand partial results and that verification data appears over time rather than all at once.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the core action, the second gives the essential polling guidance, and the third summarizes what is returned. Every sentence earns its place with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and annotations, the description is complete enough for an agent to select and use the tool correctly. It covers the key behavioral nuance of polling, states what data is included, and leaves limit/offset and return structure to the schema where they belong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters clearly. The description does not add extra meaning about limit, offset, or search_id beyond what are already in the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Fetch a search's leads with verification filled in as enrichment progresses.' It clearly identifies this tool as the one that returns leads for a specific search, which differentiates it from siblings like search_leads, query_leads, and export_leads. The polling instruction and the list of returned fields reinforce exactly what the tool accomplishes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: results become populated as enrichment progresses and the agent should 'Poll until enrichment is complete.' It does not explicitly state when to prefer this tool over query_leads or export_leads, but the intended polling workflow is evident and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The account's automations — saved searches that re-run on a schedule and export themselves. Shows each one's niche, cities, cadence, destination, whether it's active, when it next runs, and how the last run went.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| automations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is established. The description adds meaningful context by explaining what automations are (scheduled searches that export themselves) and what status information is returned. It does not add details like pagination or rate limits, but given the annotation coverage, the bar is met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and then provides specific details about returned fields. Every word contributes value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and an existing output schema, the description is complete. It defines the domain concept (automations), states what is listed, and enumerates the output fields, leaving no significant ambiguity about the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is fully covered (100%) by virtue of being empty. The description adds no parameter details because none exist, which matches the baseline expectation for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly identifies the tool as listing the account's automations (scheduled searches that re-run and export themselves) and enumerates the exact fields shown (niche, cities, cadence, destination, active status, next run, last run). This distinguishes it from sibling list_searches, which likely lists one-off searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: an agent would use this to inspect scheduled search automations. However, there is no explicit statement about when to choose this over list_searches or other alternatives, nor any exclusions. The definition of automations provides implicit guidance but not direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which export destinations this account has connected (Close, GoHighLevel, Google Sheets) and whether each is ready to receive leads. Check this BEFORE export_leads or create_automation with a CRM destination — those fail if the integration isn't connected, and Close additionally needs one manual export first to save its field mapping. File destinations (csv/xlsx/json) always work and need nothing connected.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| integrations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds valuable context: that export_leads/create_automation fail without integration and that Close requires a manual export first. This goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the purpose and then provides essential usage guidance. Every clause contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and an output schema present, the description fully covers purpose, usage timing, and edge cases (Close's manual export requirement, file destinations always working). No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has 0 parameters, so baseline is 4. The description uses this freedom to explain the meaning of 'connected' and 'ready', adding semantic context even though no parameters need clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists connected export destinations (Close, GoHighLevel, Google Sheets) and their readiness for receiving leads. It uses specific resource names and distinguishes itself from sibling export/automation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to check this tool before export_leads or create_automation with CRM destinations, noting these fail without a connected integration. Also states file destinations always work, providing clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The account's recent searches (id, niche, location, result count, when) — use a search_id with get_search_results or export_leads.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max searches (default 10, max 25). |
| Name | Required | Description |
|---|---|---|
| searches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds value beyond this by clarifying account scoping ('the account's recent searches'), listing the return fields, and indicating how the results should be used downstream, which are behaviors not captured by 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the main purpose and returned fields, followed by a concise usage clause. Every word contributes useful information with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, existing output schema, read-only annotations), the description provides all essential context: what it returns, account scope, and how the results connect to sibling tools. This is fully complete for the tool's complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single 'limit' parameter, including its default (10) and max (25) values. The description does not repeat or extend the parameter semantics, so it adds no extra meaning beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List recent searches') and the resource ('account's recent searches'), and enumerates the returned fields (id, niche, location, result count, when). It differentiates from sibling tools by explicitly mentioning that search_ids from this tool are used with get_search_results or export_leads, making its role distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context by explaining that the search_id obtained from this tool is used with get_search_results or export_leads, which positions list_searches as the entry point for those operations. It does not provide explicit exclusions or alternative scenarios, but the guidance is clear and helpful for an agent deciding when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The account's saved views from the leads table — each a named set of filters the user already built (e.g. 'Roofers with a mobile number'). Returns each view's filter conditions in the exact shape query_leads and export_leads accept, so "export my Hot Leads view to Close" works without rebuilding the filters by hand.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| views | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is well covered. The description adds valuable behavioral context by stating the output format is compatible with query_leads and export_leads, and clarifies that views are user-defined named filters. This goes beyond the annotations and helps the agent understand the data and its reuse. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences. It front-loads the purpose, provides an example, and explains the key integration point without unnecessary elaboration. Every sentence contributes meaning and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, an existing output schema, and read-only annotations, the description covers all essential aspects: what is listed, the format compatibility, and the practical use case. It does not discuss pagination or limits, but these are likely in the output schema. Overall, it is complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description correctly focuses on output rather than inputs. Schema description coverage is 100% by default, and the description adds no parameter details because none are needed. The baseline of 4 is appropriate for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists the account's saved views from the leads table, each being a named set of filters, with a concrete example ('Roofers with a mobile number'). This distinguishes it from sibling tools like list_searches by specifying 'saved views' as the resource. The verb 'list' is unambiguous and directly matches the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the returned filter conditions are in the exact shape query_leads and export_leads accept, implying this tool is used to retrieve saved views before querying or exporting them. It does not explicitly state when not to use it or compare it to alternatives, but the context makes the primary use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search ALL leads the account has ever collected (across every search) with filters and sorting — no new search is run and no leads are spent. Filter fields include: name, category, city, state, rating, reviews, website, claimed, owner_name, phone_1, email_1, email_status, phone_1_type, google_cid. Operators: contains, not_contains, is, is_not, starts_with, gt, gte, lt, lte, is_empty, is_not_empty, is_true, is_false. Combine rows with conj 'and'/'or'. Example: find rated-4.5+ plumbers in Austin with a verified email: filters=[{field:'category',operator:'contains',value:'plumb'},{field:'city',operator:'is',value:'Austin',conj:'and'},{field:'email_status',operator:'is',value:'safe',conj:'and'}].
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort keys, e.g. [{id:'reviews',dir:-1}]. Optional. | |
| limit | No | Max leads to return (default 25, max 1000). | |
| cursor | No | Opaque pagination cursor from a previous call. | |
| filters | No | Filter conditions (optional — omit for everything, newest data first). |
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| returned | Yes | |
| next_cursor | No | Pass back as 'cursor' for the next page. |
| total_matching | No | Exact match count (first page only; absent on later pages). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful behavioral context: this operates on previously collected leads, runs no new search, and spends no leads. This goes beyond the structured annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence carries essential information: core behavior, scope, filter fields, operators, conjunction rules, and a worked example. The most important differentiators are front-loaded, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with rich filtering and sorting behavior, the description covers the full set of filter fields, operators, conjunction logic, and the 'no cost' behavior. Pagination and limit details are already in the input schema, and an output schema exists, so nothing necessary for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds substantial value by enumerating the allowed filter fields and operators, explaining conjunction semantics, and giving a concrete example. This meaningfully exceeds what the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') with a clearly defined resource: ALL leads the account has ever collected, across every search. It also states the scope and differentiates itself from search tools by noting no new search is run and no leads are spent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this is for querying the existing lead library rather than triggering a new search, explicitly noting that no leads are spent. It doesn't name an alternative tool directly, but the context makes the appropriate use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a live search for local businesses by niche + city (e.g. query 'electrician', location 'Austin, TX'). Returns the first batch immediately with a search_id; more results are found and verified in the background — every email is SMTP-checked and every phone verified with line type + carrier. Spends 1 lead per result. Poll get_search_results until enrichment is 'complete'.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Business niche/category keyword, e.g. 'electrician'. | |
| location | No | City, e.g. 'Austin, TX'. Ignored if location_code is given. | |
| location_code | No | Optional exact location code (skips the city lookup). |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| location | No | |
| next_step | No | |
| search_id | Yes | |
| enrichment | Yes | 'pending' until background verification finishes. |
| leads_remaining | No | Leads spendable now. On a plan with no monthly quota this is what is left in the current 7-day period. |
| delivered_so_far | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond annotations by disclosing that searches are live, results are verified in the background, every email is SMTP-checked, every phone is verified with line type and carrier, and the tool spends 1 lead per result. This gives the agent essential cost and async-behavior context that annotations do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three focused sentences with no filler. It front-loads the core action and example, then adds the async behavior, verification details, cost, and next-step polling instruction in a compact, logical order.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only one required parameter and a strong output schema, the description fully covers what the agent needs to know: how to start the search, what is returned immediately, what happens in the background, the cost per result, and how to retrieve the full results. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents query, location, and location_code. The description adds a concrete example and shows the relationship between query and location, but it does not materially expand on the schema definitions; the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Run a live search'), a precise resource (local businesses), and the required inputs (niche + city). It immediately conveys this is an asynchronous search that returns a search_id, clearly distinguishing it from sibling tools like get_search_results or list_searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational guidance: it returns a first batch immediately, then tells the agent to poll get_search_results until enrichment is complete. It does not explicitly enumerate when not to use alternatives, but the polling instruction and cost warning make the intended workflow clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause an automation (active=false) so it stops running and stops spending leads, or resume it (active=true). Pausing is the safe way to stop an automation you might want back — use delete_automation only when the user wants it gone for good.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The automation id from list_automations. | |
| active | Yes | false to pause, true to resume. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| note | No | |
| active | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutability (readOnlyHint=false), idempotency (idempotentHint=true), and non-destructiveness (destructiveHint=false). The description adds context beyond these: pausing stops the automation from running and 'stops spending leads', which is a meaningful incidental effect. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action. Every clause contributes to understanding: the mechanism (active flag), the consequence (stops spending leads), and the alternative (delete_automation). No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with full schema coverage, an output schema, and solid annotations, the description covers all necessary context: what the tool does, when to use it vs an alternative, and the practical effect. No important gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both id and active. The description reinforces the active mapping (false to pause, true to resume) and adds a slight nuance about stopping lead spending, but does not substantially enrich parameter meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verbs 'pause' and 'resume' with the resource 'automation', and explicitly maps them to the active field values. It distinguishes from sibling delete_automation by noting when to use which, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use pause/resume vs delete: 'Pausing is the safe way to stop an automation you might want back — use delete_automation only when the user wants it gone for good.' This provides direct alternatives and clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
get_search_results2 fields changedOutput schema / properties / leads_remaining / descriptionAdded value: +"Leads spendable now. On a plan with no monthly quota this is what is left in the current 7-day period, not a monthly balance."Output schema / properties / periodAdded value: +{
+ "description": "On a rate-limited plan: { limit, used, resets_at }. Null on a metered plan.",
+ "type": [
+ "object",
+ "null"
+ ]
+}search_leads1 field changedOutput schema / properties / leads_remaining / descriptionAdded value: +"Leads spendable now. On a plan with no monthly quota this is what is left in the current 7-day period."get_balance3 fields changedOutput schema / properties / period_limitAdded value: +{
+ "type": "number"
+}Output schema / properties / period_resets_atAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / period_usedAdded value: +{
+ "type": "number"
+}get_search_results1 field changedOutput schema / properties / next_offsetAdded value: +{
+ "description": "Pass as offset to fetch the next page; null on the last page.",
+ "type": [
+ "number",
+ "null"
+ ]
+}get_search_results3 fields changedOutput schema / properties / progressAdded value: +{
+ "description": "{ done, total } rows enriched so far.",
+ "type": [
+ "object",
+ "null"
+ ]
+}Output schema / properties / queue_positionAdded value: +{
+ "description": "For queued searches, the place in this account's own queue (1 = next).",
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / stageAdded value: +{
+ "description": "queued | discovering | enriching | verifying | complete | failed | cancelled. 'verifying' means every row is delivered and contacts are being verified — often the longest phase, not a stall.",
+ "type": "string"
+}create_automationdelete_automationexport_leads4 fields changedInput schema / properties / all / descriptionPrevious value: -"Export the whole library instead. Exports write a file, so there is no row cap."New value: +"Export the whole library instead of one search."Output schema / properties / limitAdded value: +{
+ "description": "The per-call limit that applied, when truncated.",
+ "type": "number"
+}Output schema / properties / truncatedAdded value: +{
+ "description": "True when more leads matched than this destination's limit — the export was PARTIAL.",
+ "type": "boolean"
+}Output schema / properties / warningAdded value: +{
+ "description": "Present when truncated: what happened and how to get the rest.",
+ "type": "string"
+}list_automationslist_integrationslist_viewsupdate_automationexport_leads1 field changedInput schema / properties / all / descriptionPrevious value: -"Export the whole library instead (max 1000 leads)."New value: +"Export the whole library instead. Exports write a file, so there is no row cap."get_search_results1 field changedInput schema / properties / limit / descriptionPrevious value: -"Max leads to return (default 25, max 100)."New value: +"Max leads to return (default 25, max 1000)."query_leads1 field changedInput schema / properties / limit / descriptionPrevious value: -"Max leads to return (default 25, max 100)."New value: +"Max leads to return (default 25, max 1000)."enrich_domainsexport_leadsget_balanceget_search_resultslist_searchesquery_leadssearch_leadsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Finds, filters, and verifies local-business leads; every email carries a verification receipt.
Local business lead extraction with email + phone enrichment from Google Maps.
B2B and local lead gen: verified emails, site contacts, Maps and Yellow Pages leads.
Search local businesses, manage saved leads, and draft cold-outreach email from your workspace.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource or action: live search, querying collected leads, domain enrichment, exports, automations, integrations, and account balance are clearly separated. Even the similar-sounding search_leads and query_leads are unambiguous because one runs a new paid search and the other filters existing leads.
All tool names follow a consistent verb_noun snake_case pattern: create_automation, delete_automation, update_automation, list_searches, query_leads, export_leads, get_balance, etc. The naming style is uniform and predictable across the entire set.
Thirteen tools is well-scoped for a lead-generation and enrichment server. Each tool covers a meaningful operation without redundancy, and the count stays within the ideal range for an agent to navigate comfortably.
The tool surface covers the full lead lifecycle: searching, enriching, querying, exporting, managing automations, checking integrations, and monitoring balance. It also includes the safe pause/resume distinction for automations, avoiding dead ends in common workflows.