The Generect Live API MCP Server provides B2B lead generation and company intelligence tools:
Search for leads (search_leads): Find leads using ICP filters such as job title, location, company name, company LinkedIn URL/ID, and industry. Supports pagination and compact output.
Search for companies (search_companies): Discover companies using keywords, location, headcount ranges, industries, and company types, with options to derive companies from leads as a fallback.
Generate email addresses (generate_email): Generate a professional email for a person by providing their first name, last name, and company domain (e.g., generect.com).
Get lead by LinkedIn URL (get_lead_by_url): Retrieve detailed profile information using a LinkedIn profile URL, with optional data for posts, comments, people also viewed, and inexact company matching.
Health check (health): Verify that the Generect API is reachable and functioning correctly, optionally against a specific LinkedIn profile URL.
All tools support configurable timeouts.
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., "@Generect Live API MCP Server search for leads with title CEO in SaaS companies"
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.
B2B lead and company data for AI agents — search, preview, enrich, email and phone lookup over the Generect API.
Built so an agent can work without burning a customer's balance: sizing an audience is free, every tool says up front whether it costs money, and every response reports what was actually charged.
Sign up and get your API key at https://beta.generect.com
This MCP server implements OAuth 2.1 authorization as specified by the Model Context Protocol.
Use our hosted MCP server with any OAuth-compliant MCP client:
{
"mcpServers": {
"generect": {
"url": "https://mcp.generect.com/mcp",
"type": "http"
}
}
}When you first connect, the client will initiate an OAuth flow:
You'll be redirected to the authorization page
Enter your Generect API token from beta.generect.com
Authorize the client to access your API
The client receives an access token and can now use the MCP tools
Endpoint | Description |
| Protected Resource Metadata (RFC 9728) |
| Authorization Server Metadata (RFC 8414) |
| JSON Web Key Set for token verification |
| Authorization endpoint (login + consent) |
| Token endpoint |
| Dynamic Client Registration (RFC 7591) |
If your MCP client cannot complete the OAuth flow, you can pass the API key directly via the Authorization header. The server accepts any of:
Authorization: YOUR_API_KEY
Authorization: Bearer YOUR_API_KEY
Authorization: Token YOUR_API_KEY
Authorization: Bearer Token YOUR_API_KEY (legacy)Example for mcp-remote:
{
"mcpServers": {
"generect": {
"command": "mcp-remote",
"args": [
"https://mcp.generect.com/mcp",
"--header",
"Authorization: Bearer YOUR_API_KEY"
]
}
}
}For local development or when OAuth is not needed:
Requirements: Node >= 18
Configure environment:
GENERECT_API_BASE=https://api.generect.com
GENERECT_API_KEY=Token <api-key>
GENERECT_TIMEOUT_MS=300000
JWT_SIGNING_KEY=<your-secret-key-for-jwt-signing>
TOKEN_ENCRYPTION_KEY=<32-byte-hex-key-for-token-encryption>Local dev (optional)
npm install
npm run dev:httpBuild and start (stdio server)
npm run build && npm startThe server emits one structured JSON log line per event to stderr (stdout is reserved for the MCP stdio protocol). Metadata logging is on by default; set MCP_LOG=0 to disable it entirely.
Privacy — payloads are redacted by default. Request/response payloads can contain personal data of prospects (names, company domains, generated emails). By default these values are not logged verbatim: each is reduced to a non-identifying shape marker (e.g. "first_name": "<str:4>"), so you can see which fields were sent without recording the data itself. Set MCP_LOG_PAYLOADS=1 to log payloads verbatim — intended for short-lived debugging, with the data owner's consent.
Events:
| When | Key fields |
| LLM invokes a tool |
|
| Outbound call to Generect API |
|
| Generect API responded |
|
| Result returned to the LLM |
|
| Failure |
|
reqId correlates a tool_call with its tool_result. Set MCP_DEBUG=1 for additional verbose output.
The hosted server runs under PM2 (not Docker). View logs on the host with:
pm2 logs generect-mcp # live
pm2 logs generect-mcp --err # errors only
grep tool_call ~/.pm2/logs/generect-mcp-out.log # only LLM tool inputsEvery tool states in its own description whether it is free or billable, and every
response carries a cost block with the amount the API actually charged. Tools
accept timeout_ms.
Free — start here
Tool | What it does |
| How many leads match an ICP + what the next step costs at your rates. Run before |
| Same, for companies. |
| Balance, month-to-date usage, and this account's real per-operation prices. |
| Poll a bulk job (the work was billed at submit time). |
| List/create/update/delete/test webhook endpoints. |
| Liveness + credential check against a free endpoint. Safe for monitors. |
Billable
Tool | Billed |
| per returned row |
| per returned row |
| per returned row (cheapest way to see real people) |
| per record found |
| per resolved profile — the cheapest call here; an unresolvable reference is free |
| per record found |
| per valid email found |
| per email submitted — every address, whatever the verdict |
| per phone found — the most expensive operation here |
| per record, reserved at submit time |
Every search/enrich runs against either the cached database (sub-second, cheaper,
free counts) or a live LinkedIn lookup (5–60s, pricier, billable counts, every
filter). Tools take mode: "auto" | "database" | "realtime":
auto (default) tries the cheap path and escalates only if the API says a
filter you passed does not exist there. The escalation is reported in the
response, never silent.
database never escalates: if a filter is unsupported you get an error, not a
bigger bill.
Counting is the exception — a realtime count costs money, so count_leads /
count_companies refuse to run one unless you ask for mode: "realtime"
explicitly. They tell you which filters forced the choice instead.
count_leads (free) → preview_leads (cheap) → search_leads (per row)
→ generate_email on the ids you keptget_balance before and after a batch gives you an exact spend figure to report.
Tools give an agent the ability to call Generect; a skill gives it the procedure.
skills/generect-lead-workflows documents the flows above so an autonomous agent
follows them without being told each time:
npx skills add generect/generect_mcp --skill generect-lead-workflowsSee skills/README.md. Release process and the full list of places a version has to land: RELEASING.md.
{
"mcpServers": {
"generect-liveapi": {
"command": "node",
"args": ["./node_modules/tsx/dist/cli.mjs", "src/server.ts"],
"env": {
"GENERECT_API_BASE": "https://api.generect.com",
"GENERECT_API_KEY": "Token YOUR_API_KEY",
"GENERECT_TIMEOUT_MS": "300000"
}
}
}
}Add to ~/.claude/claude_desktop_config.json (or via UI → MCP Servers). Recommended: run via npx so users don't install anything globally.
{
"mcpServers": {
"generect-api": {
"command": "npx",
"args": ["-y", "generect-ultimate-mcp@latest"],
"env": {
"GENERECT_API_BASE": "https://api.generect.com",
"GENERECT_API_KEY": "Token YOUR_API_KEY",
"GENERECT_TIMEOUT_MS": "300000",
"MCP_DEBUG": "0"
}
}
}
}macOS note: If Claude shows "spawn npx ENOENT" or launches an older Node via nvm, set command to the absolute npx path and/or override PATH:
{
"command": "/usr/local/bin/npx",
"env": { "PATH": "/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin" }
}Alternative without npx:
npm i -g generect-ultimate-mcpThen use:
{ "command": "/usr/local/bin/generect-mcp", "args": [] }The hosted server (https://mcp.generect.com) runs under PM2 on the host, fronted by nginx (TLS). The process is defined by ecosystem.config.js:
npm ci && npm run build
pm2 start ecosystem.config.js # or: pm2 reload ecosystem.config.js
pm2 save # persist the process list for reboot
# once, as root, so it survives reboots:
# pm2 startup systemd -u mcp_user --hp /home/mcp_userSingle instance only. OAuth state (registered clients, auth codes) and MCP sessions are held in memory, so the server must run as one instance. Scaling horizontally requires a shared store (e.g. Redis) first — see ecosystem.config.js.
Required secrets (fail-closed). In production (NODE_ENV=production) the server refuses to start unless JWT_SIGNING_KEY is set to a strong, non-default value; it never falls back to a hardcoded default or an ephemeral key. TOKEN_ENCRYPTION_KEY, if set, must be exactly 64 hex characters (32 bytes).
Docker is supported for local/alternative runs. Build locally:
docker build -t ghcr.io/generect/generect_mcp:local .Run the server in a container (note: the same production secrets are required — an insecure default will cause the container to exit at startup):
docker run --rm \
-e NODE_ENV=production \
-e GENERECT_API_BASE=https://api.generect.com \
-e GENERECT_API_KEY="Token YOUR_API_KEY" \
-e JWT_SIGNING_KEY="a-strong-random-secret" \
-e TOKEN_ENCRYPTION_KEY="0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef" \
-e OAUTH_BASE_URL=https://your-domain.com \
-p 3000:3000 \
ghcr.io/generect/generect_mcp:localSome MCP clients allow spawning the server via SSH, using stdio over the SSH session. Example config:
{
"mcpServers": {
"generect-remote": {
"command": "ssh",
"args": [
"user@remote-host",
"-T",
"node",
"/opt/generect_mcp/dist/server.js"
],
"env": {
"GENERECT_API_BASE": "https://api.generect.com",
"GENERECT_API_KEY": "Token YOUR_API_KEY",
"GENERECT_TIMEOUT_MS": "300000"
}
}
}
}All three default to free API calls only — a smoke test should never quietly bill whoever runs it.
Health check (account, price book, free cached count):
npm run health -- <api-key>Which filters the free cached index supports right now (free counts only):
npm run probe -- <api-key>Call tools via a local MCP client. Free tools by default; --paid adds one
3-row search and one email lookup, and the run prints what it spent:
npm run mcp:client -- <api-key>
npm run mcp:client -- <api-key> --paidOAuth tokens are JWTs signed by the server and contain your encrypted API token
Token encryption uses AES-256-GCM with a key from TOKEN_ENCRYPTION_KEY (or derived from JWT_SIGNING_KEY)
Fail-closed secrets — in production the server refuses to start with a missing or well-known-default JWT_SIGNING_KEY, and never publishes symmetric key material in the JWKS
Bounded, refreshable tokens — access tokens expire (default 30 days, ACCESS_TOKEN_TTL_SECONDS) and are renewed via a refresh_token grant; refresh tokens are rotated on use and revocable at POST /oauth/revoke (RFC 7009). Tokens issued before this change remain valid (no forced re-auth)
PKCE is required for all authorization code flows (S256 method), and re-checked on the consent POST as well as the initial redirect — a code intercepted by a rogue app that claims the same URI scheme is useless without the verifier
Dynamic Client Registration allows any MCP client to self-register, but is now rate-limited per IP (MCP_REGISTER_RATE_MAX, default 60/hour) and the client store is capped (MCP_MAX_CLIENTS, default 5000, LRU eviction that never drops an in-use client)
Redirect URIs: open by default, so any client can connect (MCP_REDIRECT_POLICY=open). Accepted: any https URL, http only on loopback/private addresses, and an app's own private-use URI scheme (cursor://…, vscode://…, com.example.app:/cb — RFC 8252 §7.1). Refused regardless of policy: cleartext http to a public host, #fragments, embedded credentials, over-long URIs, and browser-executable schemes (javascript:, data:, file:, …) — that URI is navigated to from our own origin, so those would be XSS. Loopback callbacks match on everything but the port (RFC 8252 §7.3), since a native app's listener gets an ephemeral one. Set MCP_REDIRECT_POLICY=strict to fall back to the first-party allowlist (*.generect.com, claude.ai, linear.app, plus MCP_ALLOWED_REDIRECT_DOMAINS / MCP_ALLOWED_REDIRECT_SCHEMES)
SSRF-guarded metadata fetches — the client-id-metadata-document flow (MCP_ENABLE_CIMD, default on) fetches only https URLs that resolve exclusively to public IPs, with no redirect following, a hard timeout, and a response-size cap (blocks loopback / RFC1918 / link-local / cloud-metadata targets)
Token validation fails closed — if Generect cannot confirm a token during login (upstream error), the server declines to mint an access token instead of assuming validity
Audience + algorithm pinning ensures tokens are only used with this MCP server and only via the expected signing algorithm
Var | Default | Effect |
|
| Access-token lifetime |
|
| Refresh-token lifetime |
|
| Cap on the in-memory DCR client store |
|
| Max |
|
| Rate-limit window |
|
| Allow client-id-as-metadata-URL (SSRF-guarded) |
|
|
|
| — | Extra allowed redirect hostnames, |
| — | Extra allowed private-use URI schemes, |
| — | Legacy: opens https callbacks under |
Log privacy — prospect payloads are redacted from logs by default (MCP_LOG_PAYLOADS=1 to opt in)
Related MCP server: scrapercity-cli
/oauth/authorize does not ask for a password. It hands off to a page in the
product where the user is already signed in, and that page posts a freshly
minted API token back to /oauth/broker. Two env vars decide which page that is,
and they must be changed together:
Var | Effect |
| Where |
| The only |
Moving consent from one host to the other by editing only MCP_CONSENT_URL
leaves the broker refusing the new page with
403 {"error":"forbidden","error_description":"Origin not allowed to broker consent."},
after the user has already clicked Approve. Change both lines, then prove it:
# expect 400 invalid_handoff (origin accepted), NOT 403 forbidden
curl -s -X POST https://mcp.generect.com/oauth/broker \
-H 'Content-Type: application/json' -H "Origin: <the new consent origin>" \
-d '{"handoff":"nonexistent-probe","deny":true}'CORS is not the control here — the server reflects any Origin (bearer auth,
no cookies), so a working preflight proves nothing about the broker.
mcp.generect.com runs pm2, not Docker (.github/workflows/deploy-prod.yml
is the unused Docker path). Single instance, always: OAuth state and MCP sessions
live in memory, so a second worker split-brains auth.
ssh root@chronos # 65.21.69.164
su - mcp_user && source ~/.nvm/nvm.sh # node via nvm
cd ~/generect_mcp
cp -r dist dist.bak.$(date +%H%M%S) # what previous deploys did; keeps a rollback
git pull && npm ci && npm run build
$EDITOR .env # consent vars, redirect policy
pm2 reload generect-mcp && pm2 list # version column should show the new oneThen verify from outside the box — pm2 list showing online is not evidence
that the new behaviour is live:
curl -s https://mcp.generect.com/health
curl -s -o /dev/null -w '%{redirect_url}\n' \
"https://mcp.generect.com/oauth/authorize?client_id=<id>&redirect_uri=…&response_type=code&code_challenge=…&code_challenge_method=S256"Generate email by first/last name and domain via Generect Email Generator
| Name | Required | Description | Default |
|---|---|---|---|
| first_name | Yes | First name of the person | |
| last_name | Yes | Last name of the person | |
| domain | Yes | Company domain without protocol (e.g., generect.com) | |
| timeout_ms | No | Request timeout in milliseconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the basic function, such as error handling or rate limits.
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, efficient sentence. However, it could be more structured to include usage hints.
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?
Without annotations or output schema, the description fails to explain what the tool returns, error scenarios, or timeout handling, leaving significant gaps.
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%, so baseline is 3. The description adds no additional meaning beyond what the schema already provides for each parameter.
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 generates an email using first/last name and domain, which is distinct from sibling tools like search_leads or get_lead_by_url.
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 provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Lead by LinkedIn URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | LinkedIn profile URL (e.g., https://www.linkedin.com/in/username/) | |
| comments | No | Include comments data | |
| inexact_company | No | Allow inexact company matching | |
| people_also_viewed | No | Include people also viewed | |
| posts | No | Include posts data | |
| timeout_ms | No | Request timeout in milliseconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose behavioral traits like error handling, rate limits, or side effects. It simply states the tool gets a lead, offering no behavioral insight.
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 extremely concise at 5 words, with no wasted text. It front-loads the purpose, though it could benefit from slight expansion.
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 6 parameters and no output schema, the description provides minimal context. It does not explain return values or the effect of optional parameters, leaving some gaps.
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% and all parameters have descriptions. The tool's own description adds no additional meaning beyond the schema, but the baseline of 3 is appropriate as the schema does the heavy lifting.
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 'Get Lead by LinkedIn URL' clearly indicates the tool retrieves a lead using a LinkedIn URL. However, it does not differentiate from sibling tools like search_leads, which also deal with 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?
No guidance is provided on when to use this tool versus alternatives such as search_leads or other siblings. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Health check Generect API via a quick lead-by-link request
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | LinkedIn profile URL to validate (defaults to a public profile) | |
| timeout_ms | No | Request timeout in milliseconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden for behavioral disclosure. It implies a read-only health check but does not explicitly state that no resources are modified, nor does it describe potential side effects, error conditions, or the nature of the response.
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 efficient and front-loaded. However, it contains a typo ('Generect' instead of likely 'Generate'), which slightly detracts from professionalism without obscuring meaning.
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?
The tool has no output schema and 2 optional parameters. The description does not explain what the tool returns (e.g., status code, success flag) or how to interpret results. Additional context about the lead-by-link endpoint and typical usage is missing, leaving the agent underinformed.
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% and both parameters ('url' and 'timeout_ms') are already described in the schema with clear explanations. The description adds no additional semantic value beyond what the schema provides, so a 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 states the tool performs a health check using a 'lead-by-link request', which clearly identifies the action and resource. However, it does not explicitly differentiate from the sibling tool 'get_lead_by_url', leaving some ambiguity about the exact distinction.
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 guidance is provided on when to use this tool versus its siblings (e.g., get_lead_by_url). The description does not specify that this is a lightweight connectivity check, nor does it exclude scenarios where more detailed lead data is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for companies by ICP filters
| Name | Required | Description | Default |
|---|---|---|---|
| company_types | No | Company types | |
| get_max_companies | No | Get maximum companies | |
| headcounts | No | Headcount ranges | |
| industries | No | Industries | |
| locations | No | Locations (Countries, e.g "United States") | |
| keywords | No | Keywords | |
| limit_by | No | Number of results to return | |
| offset_by | No | Offset for pagination | |
| compact | No | Return compact summary instead of full JSON | |
| fallback_from_leads | No | If no companies, derive from leads by keywords | |
| timeout_ms | No | Request timeout in milliseconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states the basic purpose and fails to mention critical traits such as read-only nature, pagination behavior (despite parameters like 'limit_by' and 'offset_by'), data freshness, or permission requirements. This lack of detail limits transparency.
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, clear sentence that conveys the core purpose without extraneous words. While it is efficient, it could be slightly longer to include essential behavioral hints without becoming verbose. For a straightforward search tool, this level of conciseness is adequate but not exemplary.
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 complexity (11 parameters, no output schema, no annotations), the description is insufficient. It does not explain the return format, default behavior, ordering, or how parameters interact. An agent would struggle to use the tool effectively without additional inference or trial and error.
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 has 100% description coverage for all 11 parameters, so the tool description does not need to elaborate further. The description mentions 'ICP filters', which broadly aligns with parameters like industries, locations, etc., but adds no additional semantic value beyond what the schema already provides. 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 action ('Search'), the resource ('companies'), and the method ('by ICP filters'). It effectively distinguishes from the sibling 'search_leads' tool, which targets leads. The term 'ICP filters' is specific enough for an AI agent to understand the tool's purpose.
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 implies usage when searching for companies via ICP criteria, but it does not explicitly state when to use this tool over alternatives like 'search_leads'. There is no guidance on exclusions or prerequisites, leaving the agent to infer context from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for leads by ICP filters
| Name | Required | Description | Default |
|---|---|---|---|
| job_title | No | Job title filter (e.g., CEO, CTO, Engineer) | |
| locations | No | Location filter (e.g., San Francisco, New York) | |
| lead_industries | No | Industry filter (e.g., Technology, Healthcare) | |
| company_id | No | LinkedIn company id | |
| company_link | No | LinkedIn company URL | |
| company_name | No | Company name | |
| limit_by | No | Number of results to return | |
| offset_by | No | Offset for pagination | |
| without_company | No | Search leads without filrest by companies | |
| compact | No | Return compact summary instead of full JSON | |
| timeout_ms | No | Request timeout in milliseconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors. It is silent on key aspects: whether the search is read-only, how pagination works (despite limit/offset params), timeout behavior, and response structure. The agent is left guessing about side effects and constraints.
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 very concise (8 words), but for a tool with 11 parameters and no annotations, it is overly sparse. Important context like pagination or output format is omitted, making it less useful despite brevity.
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?
Despite exhaustive schema coverage, the description fails to explain how to chain filters, handle pagination, or interpret results. No output schema exists, and the description does not compensate. The tool's complexity (11 params) demands more explanatory context.
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%, so the schema provides adequate meaning for all 11 parameters. The description adds only the phrase 'ICP filters', which loosely groups the filters but adds no new semantic value beyond what the parameter descriptions offer.
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 states a clear verb ('Search') and resource ('leads') with a filtering criterion ('by ICP filters'). However, it does not differentiate from sibling tools like 'search_companies' or 'get_lead_by_url', leaving ambiguity about when to use this specific tool.
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 guidance is provided on when to use this tool versus alternatives (e.g., 'search_companies' for company-level search, 'get_lead_by_url' for single lead lookup). There is no mention of prerequisites or exclusions.
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.
v0.1.0generate_emailget_lead_by_urlhealthsearch_companiessearch_leadsEach tool serves a distinct purpose: email generation, lead lookup by URL, health check, company search, and lead search. No functional overlap.
Tool names follow different patterns: 'generate_email' (verb_noun), 'get_lead_by_url' (verb_noun_with_modifier), 'health' (noun), 'search_companies' and 'search_leads' (verb_noun). The inconsistency, especially the standalone 'health', reduces predictability.
Five tools is a well-scoped number for a lead generation API, covering essential operations without being overwhelming.
The tools cover core lead generation workflows: searching leads/companies, fetching details, generating emails, and health check. Minor gaps like missing update or delete operations but acceptable for the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Managed LinkedIn MCP server for AI agents: search, connect, message and enrich on accounts you own.
MCP server for Tomba email finder, verification, and contact enrichment API
Remote MCP server to enrich company profiles with structured B2B data and confidence scores.
MCP server for LeadDelta — manage LinkedIn connections and CRM data via AI assistants.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/generect/generect_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
