Skip to main content
Glama

pipecorn

Read-only

Pipecorn — a person's mobile phone or work email (asynchronous: submit, then read the result); a person's profile; a company's firmographics, technologies and open job postings; the account's balance.

You only pay for what is found, in Pipecorn credits: 3 a work email, 30 a phone (only when a MOBILE is found), 1 a profile or a company resolved, 1 per job posting returned; a technology stack is 3 per request. A miss costs nothing. A third party's personal email is never looked up nor served: personal_email is refused on any key, and the profile, company and job lookups come without any email or phone.

op="enrich" (default) — SUBMIT a contact lookup; answers at once with enrichment_id. find: phone, email or both (default ["phone"]). phone needs linkedin_url (a profile URL); email takes linkedin_url, or firstname + lastname + domain or company_name. phone_type="mobile" keeps looking until a provider has a mobile; phone_country_codes=["FR"] keeps phones to countries. op="result" — read it back: enrichment_id, and the same find. done: false while Pipecorn is still looking — read again in a few seconds (reads are free). Done: email, email_status, phone (as Pipecorn writes them), phone_details [{number, type}], and pipecorn_credits, what it cost. op="person" — a profile: title, positions with each company's domain, headline, location, tenure. linkedin_url, or firstname + lastname + company_name. op="company" — firmographics: industry, headcount and its growth, department headcount, revenue range, headquarters, funding, web traffic. domain, company_name and/or company_linkedin_url; country_code narrows a name. op="stack" — the technologies a company uses, with a confidence. Same company arguments. op="jobs" — a company's open job postings (title, url, location, date, hiring team). Same company arguments; posted_within_days (7, 30 by default, 60, 90, 180), limit (at most 100: billed per job, so bound it), job_title_keywords, excluded_job_title_keywords, job_country_codes; full_description=True adds each description in full. person, company, stack and jobs answer found and pipecorn_credits, and need your own Pipecorn key. timeout_s bounds their wait in seconds; no answer within it is the refusal pipecorn_timeout (it may have been billed). op="credits" — the balance: credits.enrichment is what lookups spend. op="account" — the plan and the email behind the key.

For a contact, prefer the waterfalls (waterfall_phone, waterfall_email): they submit and read this for you.

Examples — pipecorn(find=["phone"], linkedin_url="https://www.linkedin.com/in/jane-doe/", phone_type="mobile") pipecorn(op="result", enrichment_id="…", find=["phone"]) pipecorn(op="jobs", domain="acme.com", limit=20, job_country_codes=["FR"])

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

Input Schema

NameRequiredDescriptionDefault
opNoenrich
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
findNo
limitNo
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
domainNo
_run_idNoOBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
lastnameNo
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
firstnameNo
timeout_sNo
phone_typeNo
company_nameNo
country_codeNo
linkedin_urlNo
enrichment_idNo
full_descriptionNo
job_country_codesNo
job_title_keywordsNo
posted_within_daysNo
phone_country_codesNo
company_linkedin_urlNo
excluded_job_title_keywordsNo

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.2/5.0
Behavior5/5

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

Adds substantial context beyond readOnlyHint: per-item credit pricing (3 email, 30 mobile, 1 profile/company/job, 3 per stack request), 'a miss costs nothing', the `personal_email` refusal on any key, exclusion of email/phone from profile/company/job results, free re-reads, and the `pipecorn_timeout` refusal that may still be billed. The billing and polling traits are exactly what an agent needs and are not inferable from the schema.

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?

Organized per operation with op= headers and worked examples, and nearly every clause carries a fact (price, refusal, alternative). Density is high and the telegraphic fragments ('answers at once', 'Done: `email`, ...') make it slower to parse than it needs to be, but there is little outright filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With eight ops, 24 params and no output schema, the description must describe return values and largely does: `enrichment_id`, `done: false`, `email_status`, `phone_details`, `found`, `pipecorn_credits`. Remaining omissions are secondary (key/auth failure shapes, whether `enrichment_id`s expire, cross-op argument compatibility).

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 only 21%, so the description carries most of the burden and mostly does: it defines `find` values per op, the identity argument combinations for `phone` vs `email`, `phone_type='mobile'` semantics, `phone_country_codes`, `posted_within_days`, `full_description`, and warns that `limit` is billed per job. The six `_org`/`_group`/`_run_id`/`_project`/`_instance` plumbing params are left entirely to the (French) schema text, which is a gap given the low overall coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description enumerates the exact resources produced: mobile phone/work email, person profile, company firmographics, tech stack, open jobs, credits balance. It distinguishes itself from siblings by naming `waterfall_phone` and `waterfall_email` as the preferred path for contacts. It loses a point because the opening sentence is a noun-phrase fragment with no verb ('Pipecorn — a person's mobile phone or work email'), and the tool's eight operations, not its identity, carry the clarity.

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?

Each `op` gets a scoped instruction, including the two-step submit/read pattern ('read again in a few seconds') and the routing rule that contact lookups should prefer the waterfalls. Guidance for choosing this over the many apollo_*/fullenrich_*/waterfall_* siblings is only given for the contact case, not for profile, company or jobs lookups.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources