Headless Lead Scraping MCP Server

by imshibaji

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.4.0
Disambiguation4/5
Each tool has a clear primary purpose, but search_web and find_leads overlap somewhat since find_leads internally uses web search. However, the descriptions clarify that find_leads is a higher-level lead-finding workflow, so ambiguity is limited.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (search_web, scrape_page, extract_leads, find_leads, list_stored_leads, filter_leads, export_leads, clear_stored_leads). This makes the toolset predictable and easy to navigate.
Tool Count5/5
With 8 tools, the scope is well-balanced: a few for data acquisition, one orchestrator, and several for managing stored leads. It's neither thin nor bloated, and each tool earns its place.
Completeness4/5
The surface covers lead discovery, extraction, storage, listing, filtering, export, and clearing. Missing individual lead deletion/update is a minor gap, but the core lead management lifecycle is well covered.
Average 3.5/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It reveals that an LLM is used, which is useful, but it does not disclose whether the operation is read-only, what 'supported lead fields' means, potential failure modes, or any rate or auth constraints. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, 13 words, with no wasted filler. The key elements (action, resource, input, method) are present and front-loaded. It is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 2 parameters and an output schema exists, which reduces the need to explain return values. However, the description lacks guidance on usage and parameter semantics, and the absence of annotations leaves transparency gaps. It is minimally viable but not fully complete for an agent to use with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no descriptions. The description adds little meaning beyond the parameter names: it references 'public page content' which maps to 'content', and 'sourceUrl' is implied but not explicitly described. For a 0% coverage case, the description should compensate, but it does not.
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?
The description clearly states the tool extracts supported lead fields from supplied public page content using a configured LLM. This distinguishes it from siblings like scrape_page (which fetches content) and find_leads (which likely searches or discovers leads). The verb 'extract' and resource 'lead fields' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives. The description implies it is used after obtaining page content, but does not mention when not to use it or reference sibling tools. With no exclusions or context, the agent is left to infer the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits itself. It mentions 'real time' and the HTTP/Playwright fallback, but omits important details such as potential rate limits, page size constraints, failure behavior for non-public pages, or whether the action is non-destructive. The 'public' qualifier hints at access restrictions, but significant behavioral disclosure is missing.
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?
The description is two sentences, front-loaded with the primary action, and contains no redundant wording. Its brevity is a strength, though it could have included more parameter or usage details without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters, no annotations, and a hidden output schema, placing a heavy burden on the description to provide operational context. It does not explain when to use this versus siblings, how parameters interact, or any behavioral caveats. The presence of an output schema partially covers return values, but overall the context is incomplete for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters, so the description must compensate. It only implicitly references the URL ('Fetch a public webpage') and the useBrowser parameter via 'Playwright,' but does not explain waitForMs or the exact role of useBrowser. This leaves two of the three parameters semantically under-defined for the agent.
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?
The description's first sentence, 'Fetch a public webpage in real time,' uses a specific verb and resource, clearly distinguishing this from sibling tools like search_web or extract_leads. It also adds the technical approach (HTTP/Playwright) to further clarify the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Uses HTTP first and Playwright for JavaScript-rendered pages' provides some context on when browser rendering is invoked, but there is no explicit guidance on when to prefer scrape_page over search_web or other siblings, nor any exclusions or prerequisites. This is sufficient for basic context but lacks clear alternative selection rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey side effects. It states the tool writes a file to disk, but does not disclose overwrite behavior, required permissions, return value, or whether filtering affects only the output or also the stored data. This is a write operation that lacks transparency about its consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, front-loaded with the verb and resource. No extraneous info, and the key details (export, stored leads, optional filter, CSV/JSON, on disk) are all present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 12 parameters, no annotations, and an output schema (not described). The description does not cover the filtering semantics, output behavior, or file handling. A minimal viable description would at least mention that the output schema provides a file path or result, and that filter parameters narrow the exported set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description was expected to compensate. It mentions optional filtering and the two output formats, but does not explain the 12 parameters (e.g., keyword, hasEmail, minConfidence) or how they interact. The phrase 'optionally filtered' provides only a hint.
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?
The description uses a specific verb ('Export') and resource ('stored leads'), states the output format ('CSV or JSON') and destination ('on disk'). This clearly distinguishes the tool from siblings like list_stored_leads or filter_leads, which do not persist to disk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when needing to export leads to a file), but does not explicitly mention alternatives or exclusions. There is no comparison with list_stored_leads or filter_leads, nor guidance on when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavioral traits. It conveys that this is a read operation, implying non-destructive behavior, but does not mention pagination, side effects, or the effect of the limit parameter. Minimal disclosure beyond the verb 'read'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant or unnecessary words. It clearly and efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description is too sparse. It does not explain that this lists all stored leads, how the limit parameter affects results, or the read-only nature. Given the presence of many sibling tools and no annotations, this leaves significant gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a 'limit' parameter with no description (0% coverage). The tool description does not mention this parameter or explain its meaning. Since schema coverage is low, the description fails to compensate for the lack of parameter documentation.
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?
The description 'Read leads stored locally by this MCP server' uses a specific verb ('Read') and resource ('leads stored locally'), clearly distinguishing it from sibling tools like search_web and clear_stored_leads by specifying local storage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as filter_leads or export_leads. It offers no exclusions or contextual cues for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose side effects and safety. It states the filtering operation but does not say whether the tool is read-only, how results are returned, or any pagination/limit behavior. The phrase 'Filter stored leads' implies a non-mutating query, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently names the action and key filtering dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description captures the core filters but omits important context: the limit parameter, whether all filters are optional, and how filters interact. An output schema exists, so return values don't need description, but for an 11-parameter tool, the description is minimally viable rather than fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning by grouping parameters into three categories: keyword, required field presence (has* flags), and minimum confidence (minConfidence). However, it does not explain the limit parameter or how the filters combine (AND/OR), so it only partially compensates for the schema's lack of descriptions.
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?
The description uses the specific verb 'Filter' and identifies the resource as 'stored leads,' with explicit criteria (keyword, required field presence, minimum confidence). This clearly distinguishes it from siblings like list_stored_leads, which lists leads, and search_web, which is web search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (filtering stored leads) but provides no explicit guidance on when to use this vs alternatives like list_stored_leads, nor any exclusions or prerequisites. There is no 'use this when...' language, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of disclosing behavior. It clearly states a destructive action ('Delete all'), which conveys that it is a mutating operation. However, it does not explicitly mention irreversibility, the requirement for confirmation, or any side effects beyond the deletion itself. The description essentially restates the tool name and title without adding further context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is well-structured and front-loaded. It contains no filler or redundant information, earning its place as an efficient summary of the tool's purpose.
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?
For a simple one-parameter destructive tool, the description is mostly sufficient. It accurately conveys the primary action and scope. However, it lacks any mention of when to use the tool or the confirmation safety mechanism, which would be helpful given the absence of annotations and the existence of sibling tools that might be confused with it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'confirm' with a const value of true, which is self-explanatory. The description does not mention the parameter at all, and schema description coverage is 0%. However, the schema's 'const' and 'required' fields sufficiently convey that confirmation must be true, so the schema compensates for the lack of description-level parameter guidance.
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?
The description 'Delete all locally stored lead records' uses a specific verb ('Delete') with a clear resource and scope ('all locally stored lead records'). It distinguishes itself from siblings like list_stored_leads (read-only) and export_leads (reads/exports) by clearly indicating a destructive operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does it mention prerequisites such as exporting or listing leads first. Sibling tools like list_stored_leads and export_leads exist, but the description does not address when deleting is appropriate or what safety checks to perform.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the full burden, and it delivers by outlining the process: browser-rendered Google Maps, crawling, LLM verification, deduplication, filtering, and local storage. It does not mention rate limits, authentication, or potential failure modes, so it is strong but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first front-loads the primary purpose and sources, and the second efficiently condenses the pipeline. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex – multi-source aggregation, crawling, extraction, filtering, storage – and the description provides a solid high-level overview. However, it leaves gaps such as how 'limit' interacts with the pipeline, what 'maxSearchQueries' controls, and the exact output shape (though an output schema exists). For an agent to invoke it correctly with parameters, more detail would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains the 'requiredFields' param ('filters by requiredFields'), leaving 'limit', 'location', and 'maxSearchQueries' unexplained except by their schema names. This is insufficient for a tool with five parameters.
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?
The description states a specific action ('Find leads'), defines the resource ('Google Maps places first... then live web search engines'), and clearly distinguishes itself from sibling tools by describing a full end-to-end pipeline. The priority order and sources make it unmistakable what this tool does.
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?
The description conveys when to use this tool by presenting it as the comprehensive lead-finding solution, implicitly suggesting it over simpler siblings like search_web or extract_leads. However, it does not explicitly state when not to use it or what alternatives to choose for narrower tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the burden. It does disclose the key trait that no API key or SDK is required, and that googlemaps is browser-rendered. However, it does not mention rate limits, result format, pagination, or potential delays from browser rendering, leaving some ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and contains no redundant information. Every clause adds value (source list, prioritization, API key requirement).
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?
Given the output schema exists, the description need not explain return values. It covers the essential context: what the tool searches, the source priorities, and an important behavioral fact (no API key). Minor omissions like rate limits or engine defaults keep it slightly short of a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It lists the engine names and their prioritization, which effectively explains the `engines` parameter. However, it does not explicitly discuss `query` or `maxResults`, though these are self-evident from the schema (min length, min/max bounds). Partial compensation only.
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?
The description clearly states a specific verb and resource: 'Search the live web'. It also distinguishes from sibling tools by specifying the scope (prioritized sources) and excluding others (search engines vs scraping/lead tools). This makes the purpose unambiguous.
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?
It provides clear context on when to use this tool: for live web searches across specific engines, with a prioritization order. It does not explicitly state when not to use it or list alternatives, but among the sibling tools (scrapers, lead management) it is obviously the only search tool, so usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![leads-scrapper-mcp MCP server](https://glama.ai/mcp/servers/imshibaji/leads-scrapper-mcp/badges/card.svg)](https://glama.ai/mcp/servers/imshibaji/leads-scrapper-mcp)

Score Badge

Copy to your README.md:

[![leads-scrapper-mcp MCP server](https://glama.ai/mcp/servers/imshibaji/leads-scrapper-mcp/badges/score.svg)](https://glama.ai/mcp/servers/imshibaji/leads-scrapper-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/imshibaji/leads-scrapper-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server