Headless Lead Scraping MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LLM_MODEL | Yes | Model identifier, e.g., qwen3. | |
| LLM_API_KEY | Yes | API key for the LLM endpoint. Use a dummy value like 'ollama' or 'lm-studio' for local servers. | |
| LLM_BASE_URL | Yes | Base URL of the OpenAI-compatible API endpoint. | |
| LLM_PROVIDER | Yes | LLM provider identifier: ollama, lmstudio, openai, or any OpenAI-compatible provider. | |
| SEARCH_ENGINES | No | Comma-separated list of search engines to use, in priority order (e.g., googlemaps,yahoo,duckduckgo,bing,startpage). | |
| MAPS_SEARCH_URL | No | URL template for Google Maps search (e.g., https://www.google.com/maps/search/). | |
| MAPS_MAX_RESULTS | No | Maximum number of results to retrieve from Google Maps. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_webA | Search the live web across prioritized sources: googlemaps (browser-rendered local places) first, then web engines (yahoo, duckduckgo, bing) and related engines (startpage). No search API key or search provider SDK is required. |
| scrape_pageB | Fetch a public webpage in real time. Uses HTTP first and Playwright for JavaScript-rendered pages. |
| extract_leadsB | Extract supported lead fields from supplied public page content using the configured LLM. |
| find_leadsA | Find leads in priority order: Google Maps places first (browser-rendered, incl. phone/website/address), then live web search engines, then related search engines. Crawls relevant pages, extracts and verifies leads with the LLM, deduplicates, filters by requiredFields, and stores them locally. |
| list_stored_leadsB | Read leads stored locally by this MCP server. |
| filter_leadsA | Filter stored leads by keyword, required field presence, and minimum confidence. |
| export_leadsB | Export stored leads (optionally filtered) to a CSV or JSON file on disk. |
| clear_stored_leadsA | Delete all locally stored lead records. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
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.
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.
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.
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.