LeadMarina

Get search results

get_search_results

Read-only

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.

Input Schema

Name	Required	Description
`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.

Output Schema

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
`data_sources`	No	Where the sources, licences and notices are for emails and owner names that may come from open datasets and public records. Pass it on with any of this data you share.
`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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 14, 2026

addedOutput schema / properties / results / items / properties / country

Added value: +{
+  "description": "ISO 3166 alpha-2 (\"US\", \"GB\").",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / results / items / properties / postal_code
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```

Changed3 schema fields changedOct 9, 2026

addedOutput schema / properties / results / items / properties / contact_name

Added value: +{
+  "description": "The person the business's own website names as running part of it (a manager, a practice's doctor) when it names no owner.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / results / items / properties / contact_title

Added value: +{
+  "description": "That person's role, as the website gives it.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / results / items / properties / people

Added value: +{
+  "description": "Everyone the business's own website names as working there, each { name, title, kind } (kind: owner, manager, practitioner, staff).",
+  "items": {
+    "type": "object"
+  },
+  "type": [
+    "array",
+    "null"
+  ]
+}

Changed1 schema field changedOct 8, 2026

addedOutput schema / properties / data_sources

Added value: +{
+  "description": "Where the sources, licences and notices are for emails and owner names that may come from open datasets and public records. Pass it on with any of this data you share.",
+  "type": "string"
+}

Changed9 schema fields changedOct 6, 2026

addedOutput schema / properties / results / items / properties / address

Added value: +{
+  "description": "Street address from the Google listing.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / results / items / properties / claimed

Added value: +{
+  "description": "Whether the owner has claimed the Google listing.",
+  "type": [
+    "boolean",
+    "null"
+  ]
+}

addedOutput schema / properties / results / items / properties / email_status

Added value: +{
+  "description": "Email 1's SMTP verdict: safe | risky | invalid | unknown.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / results / items / properties / google_cid

Added value: +{
+  "description": "Google listing id (the query_leads google_cid field).",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / results / items / properties / maps_url

Added value: +{
+  "description": "The Google Maps link for the listing.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / results / items / properties / phone

Added value: +{
+  "description": "The Google Maps number.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / results / items / properties / phone_line_type

Added value: +{
+  "description": "Phone 1's line type: mobile, fixed_line, voip or toll_free usually; also unknown, fixed_line_or_mobile and the other values query_leads lists.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / results / items / properties / primary_email

Added value: +{
+  "description": "Email 1: the first address in emails_data, the one email_status describes. Before emails are verified, the lead's primary address.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / results / items / properties / primary_phone

Added value: +{
+  "description": "Phone 1: the first number in phones_data, the one phone_line_type describes. Before phones are verified, the lead's primary number, or its Google Maps number.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

Changed2 schema fields changedSep 4, 2026

addedOutput schema / properties / leads_remaining / description

Added 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."

addedOutput schema / properties / period

Added value: +{
+  "description": "On a rate-limited plan: { limit, used, resets_at }. Null on a metered plan.",
+  "type": [
+    "object",
+    "null"
+  ]
+}

Changed1 schema field changedSep 2, 2026

addedOutput schema / properties / next_offset

Added value: +{
+  "description": "Pass as offset to fetch the next page; null on the last page.",
+  "type": [
+    "number",
+    "null"
+  ]
+}

Changed3 schema fields changedSep 2, 2026

addedOutput schema / properties / progress

Added value: +{
+  "description": "{ done, total } rows enriched so far.",
+  "type": [
+    "object",
+    "null"
+  ]
+}

addedOutput schema / properties / queue_position

Added value: +{
+  "description": "For queued searches, the place in this account's own queue (1 = next).",
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedOutput schema / properties / stage

Added 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"
+}

Changed1 schema field changedAug 5, 2026

changedInput schema / properties / limit / description

Previous value: -"Max leads to return (default 25, max 100)."New value: +"Max leads to return (default 25, max 1000)."

First observedJul 24, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), but the description adds the non-obvious behavioral trait that results are asynchronous and progressively enriched, which drives polling. It also enumerates what each lead carries; that partially overlaps the output schema but the polling semantics are real added value.

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?

Three compact sentences, front-loaded with the core action and the polling rule right after. Minor redundancy in listing lead fields that the output schema already exposes, but nothing is wasted overall.

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 an output schema present, the description does not need to detail return values, and annotations cover safety. It closes the main gap an agent would face—that results arrive asynchronously and require polling—though it stops short of stating pagination or completion-latency expectations.

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 100%, so limit, offset, and search_id are already documented with defaults and ranges. The description adds nothing about parameter meaning or interaction (e.g. how pagination relates to the enrichment status), so the baseline 3 applies.

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?

States a specific verb (fetch) and resource (a search's leads) plus the enrichment-fill behavior, which is more precise than the generic title. It implies results come from a search created elsewhere but never names the sibling tools (search_leads, query_leads, list_searches) that an agent might otherwise pick.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The instruction 'Poll until enrichment is complete' is a genuine usage cue about when to call this tool repeatedly. However, it gives no guidance on when to prefer this over query_leads, export_leads, or list_searches, so differentiation from the sibling set is left to inference.

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

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.