Desearch

Company Enrich

company-enrich

Start a paid job billed to the user's Desearch balance: collect public contact data for companies you already know, by domain. Send 1-200 domains or URLs; each is reduced to its host without www., lowercased, and deduplicated, and the task reads every one. Returns a task_id at once, with the task's status and reserved_cost_usd. You get one company per domain with the same fields as company-search but no fit score (score is null). The task's count is the number of domains left after deduplication. Cost: the call reserves one company per domain sent at the Company Enrich per-company price at the time of the call (reserved_cost_usd; prices at https://desearch.ai/pricing). When the task ends you pay only for the companies it delivered (final_cost_usd; a minimum of 1; a task that delivers none is free) and the rest of the reservation, including duplicate domains, is returned. Data: Desearch reads public data only: each company's own website (its homepage and its contact, about, team, and imprint pages), public web search results, and public LinkedIn profiles of its leaders. Each company comes back with its location, public emails, phones, and social profiles, and its leaders (roles) with their title, LinkedIn profile, and emails. Every contact keeps the page it came from (source_url). Leader emails can be inferred from the company's address pattern (source: inferred, with a confidence), and every email is checked (verification: valid, invalid, risky, or unknown). Companies stay readable for 30 days after the task ends. The task runs in the background: poll company-search-status with the task_id to read progress and the companies delivered so far. Each company is delivered first with enrichment status partial, and the later stages (contact pages, leaders, inferred emails, email checks) fill it in until it is complete. Use company-search-pause, company-search-resume, or company-search-cancel to pause, resume, or cancel it. Do not start the same task twice; send idempotency_key so a retry returns the first task instead of charging again. To find companies from a description, use company-search instead.

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": {
      "domains": "<domains>"
    },
    "name": "company-enrich"
  }
}

Input Schema

Name	Required	Description
`roles`	No	The leaders to look for: any of 'ceo', 'founder', 'cto', 'cfo', 'coo', 'cmo', 'president', 'owner', 'managing_director' (API default ['ceo', 'founder', 'cto', 'cfo']). A managing director (Geschäftsführer) counts as 'ceo' when 'ceo' is asked for.
`domains`	Yes	1-200 company domains or URLs, example: ['acme.com', 'https://www.beta.io/about']. Each is reduced to its host without www. and lowercased; duplicates are removed.
`metadata`	No	Your own labels for this task, example: {"campaign": "q4-outbound"}. Up to 10 keys; keys are 1-40 characters of a-z, 0-9, '_', '.', '-'; values are strings of up to 200 characters. Returned on the task; filter company-search-tasks by it. The task does not use it.
`infer_emails`	No	Guess leaders' emails from the company's address pattern (for example first.last), learned from the addresses found on its site (API default true). Inferred emails say source: inferred and carry a confidence: high when the pattern was learned from this company's own addresses, low for a common pattern.
`verify_emails`	No	Check every email: syntax, mail server (MX) and, for inferred ones, a web search (API default true). Each email then has a verification: valid, invalid, risky, or unknown. Set false to finish sooner without it.
`idempotency_key`	No	Any unique string for this task, for example a UUID. Sending the same key again returns the first task and is not charged again.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well past the annotations (which only say not read-only, open-world, non-idempotent): it discloses the billing model (reservation at per-company price, final_cost_usd with a minimum of 1, free if none delivered, duplicates refunded), 30-day data retention, asynchronous background execution with partial-to-complete enrichment progression, and the double-charge risk mitigated by idempotency_key. This is exactly the surplus context the annotations cannot carry.

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 purpose, then cost, then data, then lifecycle — a sensible order for a paid async job. It is long and a few sentences (e.g. the separate restatement of how count is computed) could be folded, but nearly every sentence carries billing, lifecycle, or data-provenance information an agent needs before spending money.

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 non-read-only, open-world, async, billable tool with no output schema, the description supplies the immediate return (task_id, status, reserved_cost_usd), the eventual result shape (mapped to company-search fields minus fit score), provenance of each contact, and the polling/pause/cancel path. Nothing material is missing for correct invocation.

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 operational meaning beyond the schema: domains are reduced to hosts without www., lowercased and deduplicated, every domain is still read, and duplicates affect the reservation but not the task count. The roles param's effect on returned leaders is also implicitly covered by the leaders/roles output description.

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?

Opens with a specific verb and resource: 'Start a paid job ... collect public contact data for companies you already know, by domain.' It explicitly carves out the boundary against the closest sibling, telling the agent to use company-search to find companies from a description instead. No ambiguity about what is produced.

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?

States when to use it (companies you already know, by domain), when not to (company-search for discovery), the required scale (1-200 domains), and the full follow-up workflow: poll company-search-status, pause/resume/cancel via named siblings, send idempotency_key to avoid double charging. Alternatives and exclusions are named outright.

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

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