EvenLeads

Find customers for a business

find_customers

Start a new search for potential customers of the user's business: recent public posts by people who are asking for, or want to buy, what the business sells. Only for finding new customers when the user asks for that; it does not list or rank leads the user already has. A search saves a campaign in the user's EvenLeads account, uses one search from their plan and takes one to three minutes. Takes a plain description of the business (and its website if known) and returns a search id right away with the first results as they arrive. The user must be signed in with EvenLeads.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "find_customers"
  }
}

Input Schema

Name	Required	Description
`website`	No	The business website, if the user gave one.
`business`	No	What the business sells and to whom, in the user's own words. One to three sentences is enough.
`campaign_id`	No	Only when the user explicitly asks to run a new search on one of their existing campaigns, by its campaign id. Not for showing that campaign's leads.
`ideal_customers`	No	Optional: who the best customers are (industry, size, situation).

Output Schema

Name	Required	Description	Default
`leads`	No
`search`	No
`dashboard_url`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 15, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only declare non-read-only, open-world, non-idempotent; the description adds the side effects the agent actually needs: a campaign is saved to the user's account, one search is consumed from the plan, and the call takes one to three minutes. It also discloses auth requirement (user must be signed in) and the async return pattern (search id immediately, first results streaming in).

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-loads purpose, then constraints, then cost and return behavior in a logical order with no filler. It is slightly padded by restating the title's premise at the start, but every remaining sentence carries operational information.

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?

For a long-running, plan-consuming, state-mutating search tool, the description covers prerequisites, cost, latency, and return shape, so an agent can decide and invoke without surprises. An output schema exists, so the brief mention of the returned id and streaming results is sufficient rather than redundant.

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 each parameter is already documented, and the description only restates the business/website inputs without adding format or syntax detail. It adds nothing about ideal_customers or campaign_id beyond what the schema says, so baseline 3 applies.

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 plus the target object: "recent public posts by people who are asking for, or want to buy, what the business sells." It also explicitly carves out what it is not ("does not list or rank leads the user already has"), which separates it from lead-listing siblings.

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?

"Only for finding new customers when the user asks for that" plus the exclusion of existing-lead listing gives clear when and when-not guidance. It stops short of naming the sibling tools (e.g. get_my_leads, list_my_campaigns) that an agent should switch to for the excluded case, leaving that routing to inference.

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

All EvenLeads 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.