Enables OpenAI Codex or ChatGPT to access LeadBrew's B2B lead database through REST API calls for lead search, company lookup, and usage tracking.
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., "@LeadBrew MCP Server Find CTOs at fintech companies in New York"
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.
LeadBrew MCP Server is a Model Context Protocol server that gives AI coding assistants access to the LeadBrew B2B lead database. Search for leads, get contact information, and find companies—all through natural language.
Millions of B2B Leads - Access verified business contacts with emails and phone numbers
Company Database - Search companies by industry, size, and location
Real-time Search - Find leads by name, title, company, or industry
Free Tier - 100 leads/day included with every account
Works Everywhere - Compatible with Claude Code, Cursor, Windsurf, and more
Related MCP server: Apollo.io MCP Server
Sign up at leadbrew.co
Go to Settings → API Access
Click Generate API Key
Save your API Key and API Secret
# Clone the repository
git clone https://github.com/FlatNineOrg/leadbrew-mcp.git
cd leadbrew-mcp
# Install dependencies
npm install
# Build the server
npm run buildSee configuration instructions for your specific assistant.
Add to ~/.claude/claude_desktop_config.json:
{
"mcpServers": {
"leadbrew": {
"command": "node",
"args": ["/path/to/leadbrew-mcp/dist/index.js"],
"env": {
"LEADBREW_API_KEY": "lb_your_api_key_here",
"LEADBREW_API_SECRET": "your_api_secret_here"
}
}
}
}Add to your Cursor MCP settings (Settings → MCP Servers):
{
"leadbrew": {
"command": "node",
"args": ["/path/to/leadbrew-mcp/dist/index.js"],
"env": {
"LEADBREW_API_KEY": "lb_your_api_key_here",
"LEADBREW_API_SECRET": "your_api_secret_here"
}
}
}Add to your Windsurf configuration:
{
"mcpServers": {
"leadbrew": {
"command": "node",
"args": ["/path/to/leadbrew-mcp/dist/index.js"],
"env": {
"LEADBREW_API_KEY": "lb_your_api_key_here",
"LEADBREW_API_SECRET": "your_api_secret_here"
}
}
}
}Add to your VS Code settings:
{
"cline.mcpServers": {
"leadbrew": {
"command": "node",
"args": ["/path/to/leadbrew-mcp/dist/index.js"],
"env": {
"LEADBREW_API_KEY": "lb_your_api_key_here",
"LEADBREW_API_SECRET": "your_api_secret_here"
}
}
}
}For OpenAI-based assistants, use the REST API directly. See REST API examples.
Tool | Description |
| Search for leads by name, company, industry, position, country |
| Get full lead details including emails and phone numbers |
| Search for companies by name, industry, size |
| Get company details with employee list |
| Check your API quota and usage statistics |
You: Find CTOs at fintech companies in New York
AI: [Searches using leadbrew_search_leads]
Found 156 leads matching your criteria:
**John Smith**
Position: Chief Technology Officer
Company: PayFlow Inc (Fintech)
Country: US
LinkedIn: https://linkedin.com/in/johnsmith
Lead ID: TGVhZGJyZXdtaWtlXzEyMzQ1
**Sarah Johnson**
Position: CTO
Company: BlockPay Solutions (Fintech)
Country: US
LinkedIn: https://linkedin.com/in/sarahjohnson
Lead ID: TGVhZGJyZXdtaWtlXzY3ODkw
... and 154 more resultsYou: Get the contact details for John Smith
AI: [Uses leadbrew_get_lead with the lead ID]
**John Smith**
Position: Chief Technology Officer
Company: PayFlow Inc (Fintech)
Country: US
LinkedIn: https://linkedin.com/in/johnsmith
Emails:
- john.smith@payflow.com
- jsmith@payflow.io
Phones:
- +1 (555) 123-4567You: Find 10 marketing directors at SaaS companies with 50-200 employees
AI: [Searches with position="Marketing Director", industry="SaaS", min_size=50, max_size=200]
Found 89 leads. Here are the first 10:
1. **Emily Chen** - Marketing Director at CloudMetrics (Software/SaaS)
2. **Michael Brown** - Director of Marketing at DataSync Pro (SaaS)
3. **Jessica Williams** - Marketing Director at AppFlow Systems (SaaS)
...You: Tell me about Stripe's team
AI: [Uses leadbrew_get_company with include_employees=true]
**Stripe**
Website: stripe.com
Industry: Financial Technology
Size: 8,000+ employees
LinkedIn: https://linkedin.com/company/stripe
Employees in database: 234
Sample employees:
- Patrick Collison (CEO)
- John Collison (President)
- Claire Hughes Johnson (COO)
- David Singleton (CTO)
- Dhivya Suryadevara (CFO)You: How many leads do I have left today?
AI: [Uses leadbrew_usage]
**LeadBrew API Usage**
Today's Usage:
Leads used: 45/100
Leads remaining: 55
Requests made: 12
Last 7 Days:
Total leads: 312
Total requests: 89Search for B2B leads with various filters.
Parameters:
Parameter | Type | Description |
| string | Search query for lead name |
| string | Filter by company name |
| string | Filter by industry |
| string | Filter by job title |
| string | Country code (US, UK, DE, etc.) |
| number | Results per page (1-25) |
| number | Page number |
Get detailed information about a specific lead.
Parameters:
Parameter | Type | Required | Description |
| string | Yes | Lead ID from search results |
Returns: Full lead profile including emails and phone numbers.
Search for companies in the database.
Parameters:
Parameter | Type | Description |
| string | Company name search |
| string | Filter by industry |
| string | Country code |
| number | Minimum employee count |
| number | Maximum employee count |
| number | Results per page (1-25) |
| number | Page number |
Get company details with optional employee list.
Parameters:
Parameter | Type | Required | Description |
| string | Yes | Company ID or LinkedIn handle |
| boolean | No | Include employee list |
Check your API usage and quota.
Parameters:
Parameter | Type | Description |
| number | Days of history (1-90) |
Limit | Value |
Daily lead quota | 100 leads |
Max per request | 25 leads |
Company searches | Unlimited |
Rate limit reset | Midnight UTC |
You can also use the LeadBrew REST API directly:
curl -X GET "https://leadbrew.co/api/v1/leads?q=john&industry=Technology&limit=10" \
-H "X-API-Key: lb_your_api_key" \
-H "X-API-Secret: your_api_secret"See examples/rest-api.md for more REST API examples.
Make sure your environment variables are set correctly:
LEADBREW_API_KEY should start with lb_
LEADBREW_API_SECRET should be 64 characters
You've used your daily quota of 100 leads. The limit resets at midnight UTC.
Check that:
Your API key is active (not revoked)
The key and secret match
No extra spaces in your configuration
Documentation: leadbrew.co/api-docs
Issues: GitHub Issues
Email: support@leadbrew.co
MIT License - See LICENSE for details.
Get detailed information about a specific company including employee list.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The company ID (from search results) or LinkedIn company handle | |
| include_employees | No | Include list of employees (counts toward daily quota) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. However, it only states the basic action and does not disclose behavioral traits like read-only nature, any side effects, or rate limits beyond what is already in the schema (quota for include_employees).
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 a single sentence that is concise and front-loaded with the core purpose. No unnecessary words. It could be slightly more informative without harming conciseness, but it is efficient.
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 tool has 2 parameters and no output schema, the description gives an overview but lacks details on what fields are included in 'detailed information'. It is adequate for a simple get tool but not fully comprehensive.
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% with clear descriptions for both parameters (id and include_employees). The description does not add new information about parameters, but the schema provides sufficient meaning, so baseline score of 3 is appropriate.
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 verb 'get' and the resource 'detailed information about a specific company', with a specific feature 'including employee list'. This distinguishes it from sibling tools like search (leadbrew_search_companies) and lead (leadbrew_get_lead).
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?
The description does not provide any guidance on when to use this tool versus alternatives, such as when to use leadbrew_search_companies instead. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific lead including email addresses and phone numbers. Requires the lead ID from a previous search.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The lead ID (from search results) or LinkedIn handle |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the input requirement but does not disclose whether the operation is read-only, if authentication is needed, or any rate limits. As a retrieval tool, it should explicitly state it does not modify data.
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 two sentences long with no extraneous information. It front-loads the purpose and immediately provides the necessary usage condition. Every word adds value.
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?
For a simple tool with one parameter and no output schema, the description adequately explains what the tool returns (detailed info including email and phone) and the required input (lead ID). No additional context is needed given the low complexity.
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?
The input schema fully describes the 'id' parameter (100% coverage). The description adds minor context by reaffirming the ID comes from a previous search and implicitly allowing a LinkedIn handle, but this does not significantly enhance understanding 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?
The description clearly states the verb 'Get' and the resource 'specific lead', and specifies the contents of the returned information (email addresses and phone numbers). It distinguishes itself from sibling tools like leadbrew_get_company and leadbrew_search_leads by targeting a single lead by ID.
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?
The description advises that the lead ID must come from a previous search, providing clear usage context. However, it does not explicitly state when not to use this tool or mention alternatives such as leadbrew_search_leads for broader queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for companies in the LeadBrew database. Returns company info including name, website, industry, and size.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search query for company name | |
| page | No | Page number (default: 1) | |
| limit | No | Number of results (1-25, default: 10) | |
| country | No | Filter by country code | |
| industry | No | Filter by industry | |
| max_size | No | Maximum company size (employee count) | |
| min_size | No | Minimum company size (employee count) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as read-only nature, pagination behavior, rate limits, or authentication requirements. It only states the output fields, omitting details on how results are returned or any side effects.
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 concise with two sentences, front-loading the purpose. It wastes no words, but it could be slightly more structured by explicitly listing the return fields or parameter usage.
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 7 parameters and no output schema, the description is incomplete. It does not explain parameter behavior, pagination (though page/limit are in schema), or the structure of returned data beyond a vague list of fields. The agent lacks sufficient context to use the tool effectively without inferring from parameter names.
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?
All 7 parameters have descriptions in the input schema (100% coverage), so the schema does the heavy lifting. The description adds no additional meaning beyond listing the return fields, which are already implied by the parameter names and 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 it searches for companies and returns specific fields (name, website, industry, size). However, it does not differentiate from the sibling tool 'leadbrew_get_company', which likely retrieves a single company, leaving potential ambiguity about when to use each.
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 when-to-use or when-not-to-use guidance is provided. The description does not mention alternatives or context for use, leaving the agent to infer from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for B2B leads/contacts in the LeadBrew database. Returns name, position, company, and LinkedIn profile. Use the lead ID to get full contact details including email and phone.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search query for lead name (e.g., "John Smith") | |
| page | No | Page number for pagination (default: 1) | |
| limit | No | Number of results to return (1-25, default: 10) | |
| company | No | Filter by company name (e.g., "Google") | |
| country | No | Filter by country code (e.g., "US", "UK", "DE") | |
| industry | No | Filter by industry (e.g., "Technology", "Healthcare") | |
| position | No | Filter by job title/position (e.g., "CEO", "Marketing Manager") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses returned fields but lacks details on pagination, result ordering, or search behavior (e.g., fuzzy matching). No annotations to compensate.
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 concise sentences clearly stating purpose and providing a key usage tip, with no redundancy.
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 schema covers all parameters and no output schema needed, the description is nearly complete. Could mention possible empty results or search types, but adequate.
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?
All parameters have descriptions in schema (100% coverage), so description adds minimal additional semantics. Baseline 3 is appropriate.
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 for B2B leads in LeadBrew, lists return fields, and differentiates from sibling tools like leadbrew_get_lead and leadbrew_search_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?
Implies use case via mention of using lead ID for full details, but does not explicitly state when to use this vs alternatives or provide context like failure scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check your LeadBrew API usage and remaining quota for today.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Number of days to include in usage history (1-90, default: 7) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description indicates a read-only check but lacks details on side effects, rate limits, or auth requirements.
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?
Single, focused sentence with no unnecessary words; information is front-loaded.
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?
Adequate for a simple read-only tool with one optional parameter; could clarify what 'usage history' includes but sufficient given low complexity.
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 covers the single parameter fully (100%), but description adds no extra meaning or usage context 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?
Clear verb 'Check' and resource 'API usage and remaining quota'. Distinguishes from sibling tools focused on companies and leads.
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?
Implied usage for monitoring quota, but no explicit when-to-use or when-not-to-use guidance nor alternatives.
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.0leadbrew_get_companyleadbrew_get_leadleadbrew_search_companiesleadbrew_search_leadsleadbrew_usageEach tool targets a distinct resource/action: search vs get for companies and leads, plus a separate usage check. No overlap or ambiguity.
All tools follow a consistent 'leadbrew_verb_noun' pattern with underscores, making them predictable and easy to parse.
With 5 tools, the set is well-scoped for a B2B lead generation data provider—covering search and detail retrieval for companies and leads, plus quota monitoring.
The tool set covers core search and detail retrieval for both leads and companies, plus usage tracking. Lacks mutation endpoints (e.g., add/update lead), but this is appropriate for a read-focused API.
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.
Real-time B2B data for agents: search and enrich 1B+ people and 200M+ company profiles.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/FlatNineOrg/leadbrew-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
