Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Prospeo MCP Server Find the professional email for the person at linkedin.com/in/johndoe"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Official Model Context Protocol (MCP) server for Prospeo — giving AI tools native access to B2B lead search and enrichment.
Works with any MCP-compatible client: Claude, Cursor, Windsurf, Claude Code, and more.
Search Suggestions — Free helper to resolve canonical filter values for locations, job titles, technologies, industries, NAICS, and SIC codes (no credits consumed)
Enrich Person — Find professional email and mobile phone from a name, LinkedIn URL, or email
Bulk Enrich People — Enrich up to 25 people in a single call — the canonical follow-up to search_person
Enrich Company — Get full company profile: headcount, industry, revenue, tech stack, funding, social links
Bulk Enrich Companies — Enrich up to 25 companies in a single call from a list of names or domains
Search People — Query Prospeo's professional database with filters (job title, seniority, location, company size, etc.)
Search Companies — Query Prospeo's company database with filters (industry, headcount, technology, revenue, etc.)
Account Info — Check credits remaining, plan, and renewal date (free, no credits consumed)
Related MCP server: LeadSpark MCP
Connect directly to Prospeo's hosted MCP server — no installation needed.
Server URL:
https://mcp.prospeo.ioAuthentication is handled via OAuth or by passing your API key in the X-KEY header. Supported by Claude.ai, Claude Desktop, and other remote MCP clients.
Run the server locally in stdio mode. Requires Node.js 18+.
claude mcp add prospeo --env PROSPEO_API_KEY=your_api_key -- npx -y @prospeo/prospeo-mcp-serverAdd to your claude_desktop_config.json:
{
"mcpServers": {
"prospeo": {
"command": "npx",
"args": ["-y", "@prospeo/prospeo-mcp-server"],
"env": {
"PROSPEO_API_KEY": "your_api_key"
}
}
}
}Add to your MCP settings (refer to your client's documentation):
{
"prospeo": {
"command": "npx",
"args": ["-y", "@prospeo/prospeo-mcp-server"],
"env": {
"PROSPEO_API_KEY": "your_api_key"
}
}
}Variable | Required | Default | Description |
| Yes (stdio mode) | — | Your Prospeo API key. Get one at app.prospeo.io/api |
| No |
| Logging level: |
Resolve canonical filter values before building a search. Free endpoint — does not consume credits. Rate limited to 15 req/sec.
Call this first whenever the user mentions a location, technology, industry, job title, or NAICS / SIC code — guessing strings (e.g. "SF" vs "San Francisco, California, United States") causes empty searches.
Supported types: location, job_title, technology, industry, naics, sic.
Find the professional email address and/or mobile phone number for a person. Use bulk_enrich_person instead when you have multiple people to enrich (same per-record cost, one call instead of many).
Required input (at least one):
linkedin_url — Person's LinkedIn profile URL
email — Known email address
person_id — From a prior search_person result
first_name + last_name + company_name or company_website
Enrich up to 25 people in a single call — the canonical follow-up to search_person. Pass each result's person_id as a record; the matched.identifier in the response equals that person_id so you can stitch results back to the original list.
Per-record credit cost is identical to enrich_person (1 credit per matched email, 10 per matched email + mobile). Returns a compact response per record (no job_history, no skills, abbreviated company summary) — use enrich_person if you need the full profile for a specific person.
Get a full company profile including headcount, industry, revenue, tech stack, funding, social links, attributes, and job postings.
Required input (at least one):
company_website (recommended, most accurate)
company_name
company_linkedin_url
company_id — From a prior search or enrich result
Enrich up to 25 companies in a single call — the canonical lookup tool when you already have a list of company names or domains (CRM exports, account lists, competitor maps). Returns the full company profile per match. 1 credit per matched company. identifier defaults to company_id when provided so chaining from search_company results is trivial.
Search Prospeo's professional database using typed filters. Returns up to 25 results per page. Costs 1 credit per page of results.
Filters include: person_job_title, person_seniority, person_location_search, company_industry, company_headcount_range, company_technology, person_search, person_name, person_job_change, person_contact_details, and more.
Search Prospeo's company database using typed filters. Returns up to 25 results per page. Costs 1 credit per page of results.
Filters include: company_industry, company_headcount_range, company_location_search, company_technology, company_revenue, company_funding, company_intent, company_icp, company_lookalike, company_key_execs, company_website_traffic, company_integrations, and more.
Check your Prospeo account status — credits remaining, plan name, renewal date, and team size. Free endpoint, no credits consumed.
Prompt:
Find the professional email for the person at linkedin.com/in/johndoe
What happens: The server calls enrich_person with the LinkedIn URL and returns the person's verified professional email, current job title, company, and phone number if available.
Prompt:
Give me a full profile of stripe.com — headcount, funding, tech stack, everything
What happens: The server calls enrich_company with the domain and returns the company's industry, employee count, revenue range, technologies used, funding rounds, social links, and headquarters location.
Prompt:
Find VP-level people in SaaS companies with 50-200 employees in the US
What happens: The server calls search_person with seniority, industry, headcount, and location filters. Returns up to 25 matching professionals per page with name, title, company, email, and LinkedIn URL.
Prompt:
Search for companies that use Salesforce and have more than 500 employees
What happens: The server calls search_company with technology and headcount filters. Returns matching companies with domain, industry, size, location, and tech stack details.
Prompt:
How many Prospeo credits do I have left?
What happens: The server calls get_account_info and returns your current plan, credits remaining, renewal date, and team size — without consuming any credits.
The hosted server supports two authentication methods:
OAuth 2.0 — Used by Claude.ai and Claude Desktop. The OAuth consent flow is handled automatically when connecting through the MCP directory.
API Key header — Pass your API key in the X-KEY header for direct programmatic access.
Pass your API key via the PROSPEO_API_KEY environment variable. The server validates the key on startup and exits with a clear error if it's missing.
See our privacy policy: https://prospeo.io/privacy-policy
Email: support@prospeo.io
Helpdesk: https://help.prospeo.io
MCP Documentation: https://prospeo.io/mcp-docs
REST API Documentation: https://prospeo.io/api-docs
Issues: https://github.com/prospeo-v2/prospeo-mcp-server/issues
MIT
Enrich a company — return its full profile (headcount, industry, revenue, tech stack, funding, social links, HQ phone). Provide at least one identifier: company_website (most accurate), company_linkedin_url, company_name, or company_id (from a prior search result). Credits: 1 per successful match. No charge if no match is found. Check free_enrichment in the response to confirm whether credits were deducted.
| Name | Required | Description | Default |
|---|---|---|---|
| company_name | No | Company name, e.g. Acme Inc | |
| company_website | No | Company website domain, e.g. acme.com | |
| company_linkedin_url | No | Company LinkedIn URL | |
| company_id | No | Prospeo company_id from a prior Enrich Person or Search result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant context beyond annotations: cost per match, no charge on failure, and the free_enrichment field to check. Also lists output fields, all consistent with readOnlyHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with purpose, then identifier requirements and credit policy. No wasted words, each sentence adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, inputs, output fields, and cost. Lacks error handling details (e.g., what happens if multiple matches found), but given the annotations and simple parameter set, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds value by specifying parameter precedence (company_website most accurate) and explicitly stating that at least one identifier is needed, a constraint not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enriches a company by returning a full profile with specific data fields (headcount, industry, etc.). It differentiates from siblings like enrich_person and search_company by focusing on company enrichment with detailed output, and includes identifier requirements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like search_company or enrich_person. While it mentions identifier preferences and credit costs, it lacks comparative context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enrich a person — return their full profile with verified email and/or mobile, job history, and current company. Provide at least one identifier: linkedin_url, email, person_id (from a prior search result), or full_name/first_name+last_name plus company_name/company_website. Credits: 1 for email, 10 for email + mobile (set enrich_mobile=true; email is included free when mobile is requested). Credits are only deducted when the requested contact data is actually returned. No charge if no person is matched, and no charge if only_verified_email/only_verified_mobile is set but no verified contact exists. Check free_enrichment in the response to confirm.
| Name | Required | Description | Default |
|---|---|---|---|
| linkedin_url | No | LinkedIn profile URL, e.g. https://www.linkedin.com/in/johndoe | |
| No | Person's email address | ||
| person_id | No | Prospeo person_id from a prior Search Person result | |
| first_name | No | Person's first name | |
| last_name | No | Person's last name | |
| full_name | No | Person's full name (alternative to first_name + last_name) | |
| company_name | No | Current employer name | |
| company_website | No | Company website domain, e.g. acme.com | |
| company_linkedin_url | No | Company LinkedIn URL | |
| only_verified_email | No | Only return the result if a verified email is found | |
| enrich_mobile | No | Also look up the person's mobile phone number (costs 10 credits; email is included at no extra cost when mobile is requested) | |
| only_verified_mobile | No | Only return the result if a verified mobile is found (automatically enables enrich_mobile) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes credit system, when charges apply, and response field free_enrichment. Adds context beyond annotations (readOnlyHint, etc.). No contradiction with annotations; readOnlyHint aligns with read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Succinctly packs purpose, identifier requirements, and billing details. Slightly long but every sentence adds value. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately describes return value (full profile with email/mobile, job history, company) and includes free_enrichment field. No output schema, so description compensates reasonably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema by explaining the credit cost relationship between enrich_mobile and email, and the free_enrichment check. Schema already covers parameter descriptions, but description adds usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool enriches a person by returning full profile with verified contact info. Distinguishes from siblings like search_person (which searches) and enrich_company (which enriches companies).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies required identifiers (linkedin_url, email, person_id, or name+company) and conditions for credit charges. Lacks explicit when-not-to-use or comparison to alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check your Prospeo account status — credits remaining, plan name, renewal date, and team size. Free endpoint, does not consume credits. Useful to verify the API key works or check remaining quota.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds that it's free and does not consume credits, which is helpful behavioral context beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters or output schema, the description lists what the tool returns, which is sufficient for an agent to understand the tool's output. Complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description has no need to explain them. Baseline 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks account status, listing specific fields like credits, plan, renewal date, and team size. It distinguishes from sibling tools (enrich/search) which operate on different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description specifies two use cases: verifying API key works and checking remaining quota. It also notes the endpoint is free and does not consume credits, giving clear context. No explicit when-not-to-use, but siblings are clearly different.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Prospeo's company database using typed filters. Returns up to 25 results per page (max 1000 pages). Costs 1 credit per page that returns results. Each result is a summary (name, website, industry, size, revenue, location, funding, keywords). Pass company_id to enrich_company for the full profile (tech stack, description, job postings, attributes — not included in search). Use filters like company_industry, company_headcount_range, company_location_search, company_technology, company_revenue, company_funding. At least one positive (include) filter is required.
| Name | Required | Description | Default |
|---|---|---|---|
| filters | Yes | All company search filters. At least one positive (include) filter is required. Use company_industry, company_headcount_range, company_location_search, company_technology, etc. | |
| page | No | Page number (1–1000). Each page returns up to 25 results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive nature; description adds per-page limits, max pages, credit cost, and result summary detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single, well-structured paragraph with front-loaded purpose, no redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex filter schema and no output schema, description covers usage, constraints, cost, result summary, and directs to enrich_company for more data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds context: required include filter, lists common filter names, and states result content, providing value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool searches Prospeo's company database with filters, distinguishing it from enrich_company and search_person.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions requirement for at least one positive filter, credit cost per page, and points to enrich_company for full profiles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Prospeo's professional database using typed filters. Returns up to 25 results per page (max 1000 pages). Costs 1 credit per page that returns results. Each result includes person fields (name, title, location, linkedin_url) and a company summary. email and mobile are returned as obfuscated previews (revealed=false, address/number masked) with the status field populated (VERIFIED / UNVERIFIED / null) — inspect status to assess coverage before enriching. Pass person_id to enrich_person to reveal the actual values (enrich_person credits apply there, not here). Combine person filters (person_job_title, person_seniority, person_location_search) with company filters (company_industry, company_headcount_range, company_technology) to narrow results. At least one positive (include) filter is required.
| Name | Required | Description | Default |
|---|---|---|---|
| filters | Yes | All search filters. At least one positive (include) filter is required. Mix person-specific filters (person_job_title, person_seniority, etc.) with company filters (company_industry, company_headcount_range, etc.) to narrow results. | |
| page | No | Page number (1–1000). Each page returns up to 25 results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false. Description adds critical behavioral details: credit cost per page with results, obfuscation of email/mobile with status field, and the need to call enrich_person for full values. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but well-structured, front-loading key info (purpose, pagination, credits). Every sentence adds value, though it could be slightly more compact without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensively covers input, behavior, output schema (via description), pagination, costs, and cross-reference to enrich_person. For a complex tool with many filters and no separate output schema, it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% via description field. The description adds meaning: explains filter structure, required positive filter, pagination, credit cost, and output details (obfuscated previews with status). Adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it searches Prospeo's professional database using typed filters, returns person data with pagination, and distinguishes from sibling tools like search_company and enrich_person.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on filter combination, required positive filter, credit cost, and directs to enrich_person for revealing email/mobile. Could mention not to use for company-only search, but sibling distinction is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.3enrich_companyenrich_personget_account_infosearch_companysearch_personEach tool has a unique purpose: search vs enrich vs account info, and company vs person are clearly separated. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern (e.g., enrich_company, search_person, get_account_info), making them predictable and easy to understand.
5 tools cover the essential operations for a data enrichment API: search and enrich for both companies and persons, plus account status. Well-scoped and not excessive.
The tool surface provides search and enrichment for the two main entity types (company, person) and account info. No obvious gaps for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search companies, enrich contacts, and reveal emails and phones from your AI agent.
Find verified B2B emails and phone numbers; search and enrich people and companies for prospecting.
Search B2B contacts, enrich verified emails and phone numbers, and export results.
Search and enrich B2B people & companies — 70+ filters (funding, linkedin, industry, country, ...).
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/prospeo-v2/prospeo-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
