Storefinch

Find emails on business websites

find_emails

Read-onlyIdempotent

Find contact emails a business publishes on its own website, for leads whose data has no email (only about a third do). For each id it reads the homepage and up to two contact or about pages on the same site, honoring robots.txt, and returns up to 5 emails, addresses on the business's own domain first, each with the page it was found on and whether its domain accepts mail (a DNS check; no mailbox is probed and nothing is sent). It also returns opening hours and social profiles the site publishes. Results are cached 30 days and added to get_place and later exports. Up to 10 ids per call, each counting as one call; places without a website return no_website. Run verify_websites first if you only want live sites.

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": {
      "place_ids": "<place_ids>"
    },
    "name": "find_emails"
  }
}

Input Schema

Name	Required	Description	Default
`place_ids`	Yes	Up to 10 place ids from search_places, export_leads or get_place.
`force_recheck`	No	Ignore results cached in the last 30 days and fetch again.

Output Schema

Name	Required	Description	Default
`results`	Yes	One per place id, in the order given.
`quota_remaining`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 7, 2026

addedOutput schema / $defs / EmailResult / properties / opening_hours

Added value: +{
+  "description": "Opening hours the site publishes in schema.org data, e.g. \"Mon, Tue 08:00-17:00\".",
+  "items": {
+    "type": "string"
+  },
+  "title": "Opening Hours",
+  "type": "array"
+}

addedOutput schema / $defs / EmailResult / properties / socials

Added value: +{
+  "description": "Social profile links found on the site.",
+  "items": {
+    "type": "string"
+  },
+  "title": "Socials",
+  "type": "array"
+}

AddedNov 6, 2026

TDQS

A4.6/5.0

Behavior4/5

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

The description goes well beyond the annotations, disclosing crawl scope (homepage plus up to two contact/about pages on the same site), robots.txt compliance, the five-email cap with own-domain prioritization, a DNS mail-acceptance check with the explicit note that no mailbox is probed and nothing is sent, 30-day caching, and side effects on get_place and exports. The only mild tension is that results being 'added to get_place and later exports' is a persistence side effect alongside readOnlyHint=true, though it is disclosed rather than hidden.

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?

The content is front-loaded with purpose and scope, then moves through behavior, limits, and the alternative tool. It is a single dense block and somewhat long, but nearly every clause carries decision-relevant information, so little is wasted.

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?

An output schema exists, so return-value details need not be in the description, yet the tool still summarizes the key return shape (emails with source page and domain mail status, opening hours, social profiles) and the no_website outcome. Combined with the per-call id limit and rate-cost note, an agent has everything needed to invoke it correctly.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains what a place id represents (from search_places, export_leads or get_place), reinforces the 10-id limit and that each id counts as one call, and the caching/force_recheck relationship is made concrete through the stated 30-day cache. It does not spell out force_recheck by name, leaving that mapping to be inferred.

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?

The description states a specific verb and resource (find contact emails published on a business's own website) and narrows the target population to leads that have no email, noting only about a third do. It is clearly separable from siblings like verify_websites and get_place, both of which are named in context.

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?

Usage is explicit: use this for leads lacking email data, and 'Run verify_websites first if you only want live sites' names the alternative tool and the condition that selects it. Input sources are also named (search_places, export_leads, get_place), so the agent knows where ids come from.

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

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

Resources

Need Help?