Click on "Deploy 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., "@Scout MCP Server Search the web for the latest on the EU AI Act and summarize the top 5 sources."
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.
Give your coding agent the live web. Scout's MCP server adds web search, scraping to Markdown, structured extraction, crawling, screenshots, and company lookup as tools any MCP client can call: Claude Code, Codex, Gemini CLI, Antigravity, Cursor, Windsurf, and Claude Desktop.
It has zero dependencies — the MCP protocol is implemented in a few hundred lines of plain JavaScript, with no build step and nothing pulled from npm at install time. When you run it, the only code that runs is the code in this repo. See SECURITY.md.
Tool | What it does |
| Search the live web; ranked results as JSON. |
| Fetch a page as clean, LLM-ready Markdown (handles JS + bot defenses). |
| Pull structured data from one or more URLs against an objective. |
| Crawl a site from a start URL, bounded by |
| Capture a page screenshot. |
| Company profile from a domain (name, industry, socials, logo). |
| Answer a question by reading a page and the pages it links to. |
| Build a list of entities matching a natural-language query. |
Related MCP server: markfetch-mcp
Create an API key at platform.usescout.sh/settings and set it as SCOUT_API_KEY. Every example below uses npx, so there's nothing to install first.
claude mcp add scout --env SCOUT_API_KEY=sk_your_key -- npx -y @scout-ai/mcpAdd to ~/.codex/config.toml:
[mcp_servers.scout]
command = "npx"
args = ["-y", "@scout-ai/mcp"]
env = { SCOUT_API_KEY = "sk_your_key" }Add to ~/.gemini/settings.json:
{
"mcpServers": {
"scout": {
"command": "npx",
"args": ["-y", "@scout-ai/mcp"],
"env": { "SCOUT_API_KEY": "sk_your_key" }
}
}
}In the MCP settings, add a server with this config (or paste it into the MCP config file):
{
"mcpServers": {
"scout": {
"command": "npx",
"args": ["-y", "@scout-ai/mcp"],
"env": { "SCOUT_API_KEY": "sk_your_key" }
}
}
}Add to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):
{
"mcpServers": {
"scout": {
"command": "npx",
"args": ["-y", "@scout-ai/mcp"],
"env": { "SCOUT_API_KEY": "sk_your_key" }
}
}
}Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"scout": {
"command": "npx",
"args": ["-y", "@scout-ai/mcp"],
"env": { "SCOUT_API_KEY": "sk_your_key" }
}
}
}Add to claude_desktop_config.json (Settings → Developer → Edit Config) using the same mcpServers block as above.
Once connected, ask your agent things like:
"Search the web for the latest on the EU AI Act and summarize the top 5 sources."
"Scrape https://example.com/pricing and pull the plan names and prices."
"Look up stripe.com and tell me their industry and socials."
The agent picks the right Scout tool and calls it.
scout_search with depth: "deep" runs an agentic multi-step search server-side. The server streams Scout's run events and forwards them as MCP progress notifications, so clients that show progress (Claude Code, Cursor) display live updates instead of a frozen spinner. The final results come back when the run finishes.
Besides stdio, the server can run over HTTP using MCP's Streamable HTTP transport, so a remote client can connect by URL:
SCOUT_API_KEY=sk_your_key npx -y -p @scout-ai/mcp scout-mcp-http
# listening on :3000/mcpVariable | Default | Purpose |
|
| Listen port. |
|
| Endpoint path. |
| (none) | If set, clients must send |
Point an MCP client at http://your-host:3000/mcp. There's a /health endpoint for load balancers. Each request is stateless (a fresh server per request), which keeps it simple to run behind any HTTP front end.
Variable | Default | Purpose |
| (required) | Your Scout API key. |
|
| Override the API origin. |
No install, no build (zero dependencies):
SCOUT_API_KEY=sk_your_key node bin/scout-mcp.js # stdio
SCOUT_API_KEY=sk_your_key node bin/scout-mcp-http.js # hosted HTTP/SSE
node test/smoke.mjs # run the protocol testAnswer a natural-language question by reading a page and the pages it links to.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page to read | |
| question | Yes | The question to answer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool reads linked pages, which is useful, but does not specify depth, auth needs, or output format.
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 that conveys the core purpose without any superfluous words.
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 two simple parameters and no output schema, the description is fairly complete. It explains the tool's behavior and context. However, it could mention the return format to improve actionability.
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 basic descriptions for url and question. The description adds meaning by explaining that the url is the starting page and that linked pages are also read, which goes 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 tool answers a natural-language question by reading a page and its linked pages. It distinguishes from siblings like scout_extract (structured extraction) and scout_scrape (raw content) but could be more explicit about the Q&A nature.
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 for question-answering from a page and its linked pages, but provides no explicit guidance on when to use vs alternatives like scout_search or scout_extract.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a company profile from its domain: name, description, industry, socials, logo, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The company domain, e.g. "stripe.com" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only lists output fields but does not mention any constraints, side effects, or operational characteristics (e.g., rate limits, authentication, response format).
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, front-loaded sentence with no wasted words, efficiently conveying the tool's action and output.
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 absence of an output schema, the description lists several fields (name, description, industry, socials, logo) to indicate the response content, which is fairly complete for a simple lookup tool. However, it could mention the response format or any limitations.
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 the description does not add significant extra meaning beyond the schema's parameter description. The description reiterates the domain input but offers no new context or formatting details.
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 looks up a company profile from a domain and lists the returned fields (name, description, industry, socials, logo, and more), making the purpose specific and distinct from sibling tools which are for different actions.
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 a company profile is needed from a domain, but provides no explicit guidance on when to use or not use this tool versus alternatives, and no prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crawl a website from a start URL and return its pages. Bound it with max_pages.
| Name | Required | Description | Default |
|---|---|---|---|
| start_url | Yes | The URL to start crawling from | |
| max_pages | No | Maximum pages to crawl | |
| same_host_only | No | Stay on the same host |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It does not mention crawling behavior (e.g., following links, respecting robots.txt, rate limits), return format, or mutability. The phrase 'return its pages' is vague.
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 (one sentence). However, the phrasing 'Bound it with max_pages' is slightly awkward and could be clearer.
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 three parameters, no output schema, and no annotations, the description is too minimal. It fails to explain what 'pages' includes, any limitations, or how to use the tool effectively.
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 description coverage is 100%, so baseline is 3. The description adds minimal value beyond the schema; 'Bound it with max_pages' reinforces max_pages but doesn't clarify interpretation or constraints.
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 crawls a website from a start URL and returns pages, which distinguishes it from sibling tools like scout_scrape (single page) and scout_search (search). However, it lacks explicit contrast with alternatives.
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 given on when to use this tool versus alternatives like scout_scrape or scout_extract. The only usage hint is 'Bound it with max_pages,' which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract structured data from one or more URLs. Provide an objective describing what to pull.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | URLs to extract from | |
| objective | No | What to extract, in plain language |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description alone must convey behavioral traits. It only states 'extract structured data' without indicating side effects, rate limits, or output format, leaving significant gaps.
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 clear, concise sentences with no superfluous content. Essential 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?
Given the tool has no annotations and no output schema, the description should provide more context about return values, error handling, or multi-URL behavior. It currently covers only basic input guidance.
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 description adds minimal nuance ('Provide an objective describing what to pull') that largely restates the schema's own description. No additional semantic 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 states 'Extract structured data from one or more URLs', clearly identifying the tool's function. However, it does not explicitly differentiate from sibling tools like scout_scrape or scout_crawl, which share similar extraction purposes.
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 on when to use this tool vs alternatives. The description only mentions providing an objective, but does not specify contexts or exclusions relative to other scout tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a list of entities matching a natural-language query (e.g. "Series A fintech companies in Europe").
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to find | |
| limit | No | Maximum entities to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether the tool is read-only, any permissions needed, rate limits, or potential side effects. The description only states what it does, not how it behaves or what constraints exist.
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 with an example, making it very concise. It is front-loaded with the core action. However, it could be more structured by separating the example or adding a brief clarification about the tool's scope.
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 lack of output schema, the description should at least indicate what the returned list contains (e.g., names, IDs) or whether it supports pagination. It does not, leaving the agent uncertain about the format and completeness of results.
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 descriptions for both parameters: 'What to find' and 'Maximum entities to return'. The description adds value by specifying that the query is natural-language and provides an example ('Series A fintech companies in Europe'), clarifying the intended format beyond the schema's minimal description.
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 builds a list of entities matching a natural-language query, with an example. The verb 'Build a list' and resource 'entities' are specific, and the name 'find_all' aligns. It distinguishes from siblings like scout_search (web search) and scout_scrape (web scraping) by focusing on entity list building.
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 an example query but no explicit guidance on when to use this tool vs alternatives like scout_answer or scout_company. The usage is implied through the example, but there is no mention of when not to use it or which sibling tools are better suited for other tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a web page and return clean, LLM-ready Markdown. Handles JS rendering and bot defenses.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page URL to scrape | |
| max_chars | No | Truncate the Markdown to this many characters |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It mentions JS handling and bot defenses, but omits important details like error handling, rate limits, or whether it respects robots.txt. Incomplete for a safe inference.
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 action and result. No wasted words. However, could be more concise by omitting 'LLM-ready' or adding sibling differentiation.
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?
No output schema, but description notes return format as Markdown, which is helpful. Missing details like scalability, error responses, or integration with sibling tools.
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 100% of parameters with descriptions. The description does not add meaning beyond the schema for url and max_chars. Baseline score 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?
Description clearly states it fetches a web page and returns clean Markdown for LLMs. It mentions handling JS rendering and bot defenses, which implies differentiation from siblings but does not explicitly name alternatives.
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 on when to use this tool versus siblings like scout_crawl or scout_extract. The description implies it handles dynamic pages, but no explicit when-to or 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.
Capture a screenshot of a web page. Returns a URL (or data URI) to the image.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page URL to capture | |
| full_page | No | Capture the full scrollable page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only mentions returns a URL/data URI, but fails to describe side effects (e.g., page load behavior, JavaScript execution, error handling, authentication needs).
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 concise sentence, front-loading the primary purpose. It could be slightly more informative without losing conciseness, but it is not bloated.
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 two parameters and no output schema, the description covers the core functionality and return type. It doesn't explain edge cases but is adequate for typical use.
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 both parameters with descriptions (100% coverage), so baseline is 3. The description adds no additional semantic meaning beyond the schema's parameter descriptions.
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 verb 'capture', the resource 'screenshot of a web page', and the return type. This distinguishes it from siblings like scout_scrape or scout_search, which focus on data extraction or search.
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., scout_scrape for data, scout_extract for structured info). The description only states the tool's function without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the live web and return ranked results as JSON. Set depth="deep" for an agentic multi-step search; it reports progress as it runs.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query | |
| limit | No | Maximum results to return | |
| country | No | Two-letter country code, e.g. "us" | |
| depth | No | Search depth |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description reveals that results are ranked JSON and that 'deep' depth triggers agentic multi-step search with progress reporting. However, it does not disclose side effects, rate limits, authentication needs, or response structure.
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 consists of two short, impactful sentences. The first defines the core function, and the second provides a key configuration detail. No redundant or unnecessary 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?
The description covers the main function and a key parameter but lacks details on result structure, pagination, error handling, rate limits, or how it compares to similar sibling tools. For a tool with 4 parameters and no output schema, more context is needed for full autonomous agent use.
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 significant semantics to the 'depth' parameter by explaining the 'deep' option's behavior (agentic multi-step, progress reporting). This goes beyond the schema's 'Search depth' description.
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 'Search the live web and return ranked results as JSON,' specifying the verb, resource, and output format. It distinguishes from sibling tools like scout_scrape or scout_screenshot by focusing on general web search with ranked results.
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 a usage tip for the 'depth' parameter but does not explicitly guide when to use this tool over siblings like scout_answer or scout_extract. The implied usage is for general web search, but no exclusions or alternatives are mentioned.
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.
v0.1.0scout_answerscout_companyscout_crawlscout_extractscout_find_allscout_scrapescout_screenshotscout_searchScored across 8 tools
Each tool has a distinct purpose: search, scrape, crawl, extract, screenshot, company lookup, entity building, and question answering. Overlaps are minimal and clarified by descriptions.
All tools follow the consistent pattern 'scout_verb' with snake_case, making it easy to predict tool names.
8 tools is well-scoped for a web research server, covering common operations without being overwhelming.
The set covers core web research needs: search, scrape, crawl, extract, screenshot, company lookup, and intelligent querying. No obvious gaps.
Web data tools for AI agents: pages as markdown, search, maps, commerce, jobs, AI answers.
LLM-ready web search + instant answers + URL-to-clean-text fetch for agents and RAG.
Web search, browser automation, scraping, crawling and CAPTCHA solving for AI agents.
Web search, fetch, extract, and research for AI agents. Markdown output + AI-synthesized answers.
