Skip to main content
Glama
Sign In

Emailchaser

by com.emailchaser
OverviewDiscussionsAdmin

Lead Finder: read a search

get_lead_finder_search
Read-only

Reads a Lead Finder search again by its searchId, the id returned when the search was run. While it is still running, or while its exact total is still being counted (totalStatus pending), the call waits up to about six seconds, so calling again straight away is fine. The exact count can take up to about a minute, so totalStatus can stay pending (totalIsExact false) for several calls in a row: keep calling with the same searchId until totalIsExact is true or totalStatus is done or failed, and do not give up while it is pending. Failed means the count could not be fetched, so total stays a lower bound. The people already on the page are final and usable meanwhile: show them, or add them with their refs, without waiting for the count. A finished page can be re-read for 10 minutes after it was fetched (less if it came from cache), and re-reading it in that window keeps its refs valid for another 60 minutes. After that the call answers status failed with error expired, though refs already shown stay usable until 60 minutes after they were last shown; running the search again shows them afresh and uses browsing rows. After 15 minutes the search is not found.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "searchId": "<searchId>"
    },
    "name": "get_lead_finder_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
searchIdYesThe searchId returned by search_lead_finder

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the readOnly/openWorld/non-destructive annotations: it discloses the ~6 second wait, the up-to-a-minute exact-count lag, the 10-minute re-read window, the 60-minute ref validity (and its extension on re-read), the 'status failed with error expired' outcome, the lower-bound semantics of total on failure, and the 15-minute not-found cutoff. No contradiction with 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?

Front-loaded with the purpose and the polling rule, and no sentence is pure filler. However, it is a dense run-on with nested parentheticals ('less if it came from cache', 'totalIsExact false') that makes the expiry/ref-validity rules harder to scan than they need to be.

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?

No output schema exists, so the description carries the return-value burden; it covers the important fields (totalStatus, totalIsExact, status/error, page people, refs) and their state transitions well. The main gap is result navigation: nothing explains how larger result sets or additional pages are obtained.

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 one parameter and 100% schema coverage, the schema already documents searchId; the description adds meaning by explaining that the id must be reused across repeated calls and that it has a finite lifetime (search not found after 15 minutes). This is beyond the schema's static definition, though not deeply detailed.

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 and resource ('Reads a Lead Finder search again by its searchId') and ties the key parameter back to its origin ('the id returned when the search was run', i.e. search_lead_finder). An agent can immediately distinguish this read-back call from a fresh search or an import listing.

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?

Gives explicit instructions: keep calling with the same searchId until totalIsExact is true or totalStatus is done/failed, and explicitly says not to give up while pending. It also tells the agent it may consume the page's people immediately without waiting for the count, and that re-running search_lead_finder after expiry is the recovery path.

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

All Emailchaser toolsInspect
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.

Resources