Skip to main content
Glama
Sign In

Lyre Leads

by com.lyreleads
OverviewDiscussionsAdmin

Price a list

estimate_list
Read-onlyIdempotent

FREE, no account needed. Answers "what would it cost to find me N businesses, and what data comes with each one". Returns an exact cost in tokens broken down by stage (search, enrichment, contact discovery; one new lead costs one token), and when the user's account is connected its balance and the maximum businesses affordable right now, and the full list of data points each lead arrives with. THIS is the tool to use when a user asks what Lyre Leads can get them. Do NOT use count_saved_leads for that question: Lyre Leads generates leads on demand from a live Google Maps search and does not sell access to a stored pile of them, so a count of what an account already holds is not a measure of what is available.

Input Schema

NameRequiredDescriptionDefault
lead_countYesHow many businesses the user wants found (1-100000)
include_contactsNoAlso find the named contacts at each business on the open web and verify their mailboxes. Default false. 2 tokens per person found, verification included.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / include_contacts / description
      Previous value: -"Also find the named contacts at each business on the open web and verify their mailboxes. Default false. 2 tokens per contact found; a business where nobody is found costs nothing."New value: +"Also find the named contacts at each business on the open web and verify their mailboxes. Default false. 2 tokens per person found, verification included."
  2. Changed1 schema field changed
    • changedInput schema / properties / include_contacts / description
      Previous value: -"Also find the named contacts at each business on the open web and verify their mailboxes. Default false. 2 leads per contact found; a business where nobody is found costs nothing."New value: +"Also find the named contacts at each business on the open web and verify their mailboxes. Default false. 2 tokens per contact found; a business where nobody is found costs nothing."
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: it is free and needs no account, returns exact token costs by stage, reports account balance and affordable maximum, and enumerates the data points per lead. Cost mechanics (1 token per lead, 2 tokens per verified contact) are disclosed nowhere else and are essential for interpreting the estimate.

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 the key qualifier ("FREE, no account needed") and keeps every clause meaningful, but the embedded quoted question and the long trailing justification about count_saved_leads make it denser than necessary.

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?

With no output schema, the description carries the burden of explaining returns and does so: cost broken down by stage, balance, affordable maximum, and per-lead data points. Combined with full schema coverage and read-only annotations, an agent has everything needed to call and interpret it.

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?

Schema description coverage is 100%, so the baseline is 3, but the description adds pricing meaning to both parameters by tying lead_count to one-token-per-lead and include_contacts to two-tokens-per-person. It stops short of naming the parameters explicitly, so it enriches rather than fully documents them.

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+resource (estimate/price a list of N businesses) and precisely frames the question it answers. It also explicitly distinguishes itself from the sibling count_saved_leads, so an agent can route correctly without inspecting any schema.

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?

Explicit when-to-use ("THIS is the tool to use when a user asks what Lyre Leads can get them") and explicit when-NOT-to-use with the named alternative ("Do NOT use count_saved_leads for that question") plus the reason: leads are generated on demand, not stored. Nothing 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 Lyre Leads 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