Argorant

Enrich a person or company

argorant_enrich

Destructive

Look up one person or one company from what the user already knows: an email address, a person's name together with their company's website domain, or a company domain on its own. Use it for one known person or company. To find people by job or place use argorant_preview_people, to work out the email of someone by name use argorant_find_email, and to check the user's own list of addresses use argorant_quote_verification. Give one of these at a time; an email wins if you give several. A name finds the closest match at that company, so check the result before relying on it. A person lookup costs 1 credit when it returns a working email that is new to this account, and is free when nothing is found or the account already has that email. A company domain on its own is free and returns the company profile without contact details. Phone numbers are only included when include_phones is true. They cost 10 credits per phone number returned, nothing if none is found. Ask the user before spending. More in the docs at https://docs.argorant.com/docs/agents/tools#reveal-enrich-export

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": "argorant_enrich"
  }
}

Input Schema

Name	Required	Description
`name`	No	The person's full name. Give it together with domain.
`email`	No	The person's email address. Give it on its own.
`domain`	No	The company's website domain, such as linfieldhq.com. With name it finds that person; on its own it returns the company profile for free.
`include_phones`	No	true also looks up phone numbers, at the phone price in the description. Off by default.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Goes well beyond the annotations by disclosing the credit model: 1 credit for a new working email, free on no-match or already-known emails, domain-only lookups free, phones at 10 credits each, plus an explicit 'Ask the user before spending' instruction. It also warns that name matching is fuzzy ('finds the closest match... check the result before relying on it'). It stops short of describing pagination/response shape, but the output schema covers that, and destructiveHint=true is consistent with irreversible credit spend.

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 routing, then cost rules, then a docs link — a sensible order with no filler sentences. It is dense and slightly long, and the trailing documentation URL is the only element that does not directly earn its place.

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 zero-required-parameter, open-world lookup with real monetary side effects, the description covers inputs, precedence, match reliability, cost gating, and sibling routing. Return values are covered by the output schema, so nothing an agent needs before calling is missing.

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 genuine meaning on top: parameter precedence ('an email wins if you give several'), the required pairing of name with domain, and the per-phone cost of include_phones. Only the domain format example is left to the schema.

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 ('Look up one person or one company') and immediately enumerates the three accepted input shapes (email, name+domain, domain alone). It also carves out the boundary from three named siblings, so an agent can route without opening 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 plus three explicit alternatives with their selecting conditions: argorant_preview_people for job/place search, argorant_find_email for deriving an address from a name, argorant_quote_verification for the user's own list. It even resolves the ambiguous case ('Give one of these at a time; an email wins if you give several').

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

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