Provides preview_link tool that generates Discord-style unfurl cards for URLs, displaying rich previews with metadata similar to Discord's link embedding feature.
Enables AI agents to research competitors of Linear.app by chaining multiple tools including web_search, scrape_url, detect_tech_stack, analyze_seo, and screenshot for comprehensive competitive analysis.
All tools output content in clean Markdown format optimized for LLM consumption, with scrape_url specifically converting HTML to Markdown using Turndown for efficient token usage.
Uses Mozilla Readability library to strip boilerplate content from web pages and convert them to clean Markdown for LLM consumption in the scrape_url tool.
Provides preview_link tool that generates Slack-style unfurl cards for URLs, displaying rich previews with metadata similar to Slack's link unfurling feature.
Provides detect_tech_stack tool that performs Wappalyzer-style technology stack fingerprinting to identify frameworks, libraries, and platforms used by websites.
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., "@ToolCenter MCP scrape the homepage of linear.app and give me the main content in markdown"
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.
The Swiss-Army MCP server for web tools — one install, 15 LLM-ready tools.
Give your AI agent instant access to web search, scraping, screenshots, SEO/accessibility audits, DNS/WHOIS/SSL checks, and more — all through a single Model Context Protocol server. Outputs are optimized for LLM consumption (clean Markdown, structured reports) so your agent spends tokens on reasoning, not parsing HTML soup.
Tool | What it does |
| Search the web (aggregated engines) — news/images/science categories, time filters |
| Fetch a page and return clean Markdown (boilerplate stripped via Readability) |
| Capture a page — full-page, device emulation, dark mode, ad-blocking |
| Title, description, Open Graph, Twitter Card, canonical, favicon |
| Render any URL to PDF — page size, orientation, headers/footers |
| Compare two URLs — added/removed/modified sections with similarity score |
| SEO audit with scored report, issues grouped by severity, fixes |
| axe-core a11y audit, WCAG violations grouped by impact |
| Scan a page for broken (4xx/5xx/timeout) links |
| Wappalyzer-style stack fingerprinting |
| Slack/Discord-style unfurl card for a URL |
| DNS records — A, AAAA, MX, NS, TXT, CNAME, SOA, SRV, CAA, PTR |
| Registrar, creation/expiry, name servers, ownership |
| TLS cert — issuer, validity, days-until-expiry, SANs, cipher |
| HTTP-ping — up/down, status, response time, redirects |
Related MCP server: MCP Server Metasearch
Create a free account at toolcenter.dev and copy your API key from the dashboard.
Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"toolcenter": {
"command": "npx",
"args": ["-y", "toolcenter-mcp"],
"env": {
"TOOLCENTER_API_KEY": "tc_xxxxxxxxxxxxxxxxxxxx"
}
}
}
}Restart Claude Desktop. The 15 tools appear under the hammer icon.
Settings → MCP → Add server:
{
"toolcenter": {
"command": "npx",
"args": ["-y", "toolcenter-mcp"],
"env": { "TOOLCENTER_API_KEY": "tc_..." }
}
}claude mcp add toolcenter -e TOOLCENTER_API_KEY=tc_... -- npx -y toolcenter-mcpThe MCP server talks to api.toolcenter.dev by default. To point at your own ToolCenter instance, set TOOLCENTER_BASE_URL:
"env": {
"TOOLCENTER_API_KEY": "tc_...",
"TOOLCENTER_BASE_URL": "https://api.your-domain.com"
}Ask Claude:
Research the top 3 competitors of Linear.app. For each, give me their pricing page, tech stack, SEO score, and a screenshot of their homepage.
The agent will chain web_search → scrape_url → detect_tech_stack → analyze_seo → screenshot automatically. No glue code.
git clone https://github.com/toolcenter-dev/mcp
cd mcp
npm install
cp .env.example .env # add your key
npm run build
TOOLCENTER_API_KEY=tc_... node dist/index.js # runs over stdioEvery tool returns Markdown structured for LLM consumption. For example, scrape_url runs the HTML through Mozilla Readability to strip nav/footer/ads, then converts the article body with Turndown. A 2 MB page becomes ~4 KB of Markdown — 500× fewer tokens than raw HTML.
MIT © 2026 ToolCenter
Run an axe-core accessibility audit on a URL. Reports WCAG violations grouped by impact (critical/serious/moderate/minor) with the rule, description, and a link to the fix guide. Use to check pages before launch or to monitor a11y regressions.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to audit for accessibility |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it uses axe-core, reports WCAG violations grouped by impact levels, and includes rule details and fix guides. It doesn't mention rate limits, auth needs, or performance aspects, but covers core functionality adequately.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by details on reporting and usage. Every sentence earns its place with no wasted words, making it efficient and easy to parse.
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's moderate complexity (auditing with axe-core), no annotations, and no output schema, the description is fairly complete: it explains what the tool does, how results are structured, and when to use it. It could mention output format or error handling, but covers essentials well for the 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 description coverage is 100%, so the schema already documents the single 'url' parameter fully. The description adds no additional meaning beyond implying the URL is audited for accessibility, which aligns with the schema. Baseline 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 clearly states the specific action ('Run an axe-core accessibility audit') on a specific resource ('on a URL'), distinguishing it from siblings like analyze_seo or check_broken_links by focusing on WCAG compliance rather than SEO, link health, or other web analysis aspects.
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?
It provides clear context for when to use the tool ('to check pages before launch or to monitor a11y regressions'), but does not explicitly state when not to use it or name alternatives among siblings (e.g., not for SEO analysis). This gives practical guidance without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a URL for SEO issues and return a scored report. Checks title/description length, heading structure, image alt attributes, link health, meta tags, canonical URL, robots.txt, mobile viewport, load time. Returns errors/warnings grouped by severity with recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to audit |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes what the tool checks and returns but lacks details about execution characteristics like rate limits, authentication needs, timeout behavior, or whether it performs destructive actions (though 'analyze' suggests read-only). More operational context would be helpful.
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 efficiently structured in two sentences: first states the core purpose and checks performed, second describes the return format. Every element earns its place with no redundant information, making it easy to parse quickly.
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's moderate complexity (comprehensive SEO analysis with multiple check types), no annotations, and no output schema, the description provides adequate but incomplete coverage. It explains what's checked and the return format but lacks details about report structure, severity levels, or execution constraints that would help an agent use it 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?
The schema has 100% description coverage for the single 'url' parameter, so the baseline is 3. The description adds value by specifying this is a 'URL to audit' and listing the comprehensive checks performed, giving context beyond the schema's basic 'URL to audit' 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's purpose with specific verbs ('analyze', 'checks', 'returns') and resources ('URL', 'SEO issues', 'scored report'). It distinguishes from siblings by focusing on comprehensive SEO auditing rather than accessibility, broken links, SSL, or other technical checks.
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 context (analyzing URLs for SEO) but doesn't explicitly state when to use this tool versus alternatives like analyze_accessibility or check_broken_links. No exclusions or prerequisites are mentioned, leaving some ambiguity about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a page for broken (4xx/5xx/timeout) links. Returns a summary and the list of broken URLs with their status codes. Great for site maintenance, pre-launch QA, and link-rot monitoring.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Page to scan for broken links |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what the tool returns ('summary and the list of broken URLs with their status codes') and the scanning behavior, but lacks details on rate limits, authentication needs, or potential impacts like network usage. It adequately covers the core behavior but misses operational context.
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 front-loaded with the core purpose in the first sentence, followed by return details and usage contexts. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.
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's moderate complexity (single parameter, no output schema, no annotations), the description is fairly complete. It explains what the tool does, what it returns, and when to use it. However, without an output schema, it could benefit from more detail on the return format (e.g., structure of the summary), slightly reducing completeness.
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%, with the parameter 'url' well-documented in the schema as 'Page to scan for broken links'. The description does not add additional meaning beyond this, such as format examples or constraints, so it meets the baseline of 3 where the schema handles parameter documentation effectively.
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 specific action ('Scan a page for broken links') and resource ('a page'), distinguishing it from siblings like 'check_status' (general status) or 'check_ssl' (SSL-specific). It specifies the types of broken links (4xx/5xx/timeout), making the purpose highly specific and differentiated.
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 clear context for when to use this tool ('Great for site maintenance, pre-launch QA, and link-rot monitoring'), which helps differentiate it from siblings like 'analyze_accessibility' or 'analyze_seo'. However, it does not explicitly state when NOT to use it or name specific alternatives, such as 'check_status' for general status checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect a domain's TLS/SSL certificate — issuer, validity dates, days until expiry, SANs, protocol version, cipher. Flags expired, soon-to-expire (<30 days), or self-signed certs. Use for devops monitoring and pre-launch verification.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Hostname — 'example.com' (no scheme) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior by listing what it inspects (issuer, validity dates, etc.) and what it flags (expired, soon-to-expire, self-signed), giving clear operational context. However, it doesn't mention potential limitations like rate limits, authentication needs, or error handling for invalid domains.
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 efficiently structured in two sentences: the first explains what the tool does with specific details, and the second provides usage context. Every phrase adds value without redundancy, making it easy to parse and understand quickly.
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 single-parameter tool with no annotations and no output schema, the description provides strong context about what the tool inspects and flags, plus clear usage scenarios. It adequately compensates for the lack of structured output information by describing the certificate attributes examined. A minor deduction because it doesn't specify the exact return format or potential error cases.
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% with the single 'domain' parameter fully documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., format examples or edge cases), so it meets the baseline of 3 where 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 clearly states the specific action ('Inspect a domain's TLS/SSL certificate') and resource ('domain'), listing detailed attributes like issuer, validity dates, SANs, etc. It distinguishes from sibling tools by focusing exclusively on SSL certificate inspection rather than accessibility, SEO, broken links, or other web analysis functions.
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 explicitly states when to use this tool: 'Use for devops monitoring and pre-launch verification.' It also provides implicit context by listing what it flags (expired, soon-to-expire, self-signed certs), helping differentiate from other tools like 'check_status' or 'dns_lookup' that might handle different aspects of domain checking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
HTTP-ping a URL and report whether it's up, its status code, response time, any redirects, and server headers. Use for quick uptime checks and debugging 3xx/4xx/5xx responses.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what the tool does (HTTP ping with reporting) but lacks details on error handling, timeouts, rate limits, or authentication needs. It doesn't contradict annotations, but for a tool with no annotations, more behavioral context would be beneficial.
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 efficiently structured in two sentences: the first explains what the tool does, and the second provides usage context. Every word earns its place, with no redundant information, making it easy to understand quickly.
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's moderate complexity (HTTP request tool), no annotations, and no output schema, the description is adequate but has gaps. It explains the purpose and usage well but lacks details on output format, error cases, or performance characteristics, which would help an agent use it more 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?
The input schema has 100% description coverage, with the 'url' parameter well-documented in the schema. The description doesn't add any additional parameter semantics beyond what the schema provides, such as URL format examples or constraints. Baseline score of 3 is appropriate since 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 clearly states the tool's purpose with specific verbs ('HTTP-ping', 'report') and resources ('URL'), detailing what information it returns (status code, response time, redirects, headers). It distinguishes from siblings by focusing on uptime checks and HTTP response debugging, unlike tools like 'check_ssl' or 'dns_lookup'.
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 clear context for when to use the tool ('for quick uptime checks and debugging 3xx/4xx/5xx responses'), which helps differentiate it from siblings like 'check_broken_links' or 'analyze_seo'. However, it doesn't explicitly state when not to use it or name specific alternatives, preventing a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify which frameworks, libraries, CMS, analytics, and hosting a website uses (similar to Wappalyzer/BuiltWith). Returns technologies grouped by category with version when detectable. Useful for competitor research and sales prospecting.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to fingerprint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the return format ('technologies grouped by category with version when detectable') and compares it to known services ('similar to Wappalyzer/BuiltWith'), but doesn't mention rate limits, authentication needs, or potential limitations of the detection process.
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 efficiently structured in two sentences: the first states the core functionality and return format, the second provides use cases. Every phrase adds value with no redundant information, making it appropriately front-loaded and concise.
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 tool with no annotations and no output schema, the description provides adequate context about what the tool does and its use cases. However, it could be more complete by mentioning potential limitations, accuracy considerations, or what happens with undetectable technologies. The comparison to Wappalyzer/BuiltWith helps but doesn't fully compensate for the lack of structured output information.
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 with a single well-documented 'url' parameter. The description doesn't add parameter-specific information beyond what the schema provides, but with only one parameter and high schema coverage, the baseline is appropriately high. The description's context about what the tool detects provides useful semantic framing for the URL 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's purpose with specific verbs ('identify', 'detect') and resources ('frameworks, libraries, CMS, analytics, and hosting a website uses'), and distinguishes it from siblings by mentioning specific use cases ('competitor research and sales prospecting') that differentiate it from technical analysis tools like analyze_accessibility or check_ssl.
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 clear context for when to use this tool ('useful for competitor research and sales prospecting'), which helps differentiate it from more technical sibling tools. However, it doesn't explicitly state when NOT to use it or name specific alternatives for overlapping functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve DNS records for a domain. Supports A, AAAA, MX, NS, TXT, CNAME, SOA, SRV, CAA, PTR, or ALL (returns all common record types). Useful for debugging DNS config, finding mail servers, or verifying ownership records.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to look up — 'example.com' (no scheme) | |
| type | No | Record type (default ALL) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what the tool does (resolves DNS records) and lists supported record types, but doesn't mention important behavioral aspects like rate limits, authentication requirements, error handling, or whether this performs live DNS queries vs cached lookups.
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 efficiently structured with two sentences: the first states the core functionality and supported types, the second provides usage contexts. Every sentence adds value with no wasted words, and key 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?
For a DNS lookup tool with 2 parameters and no output schema, the description provides good context about what the tool does and when to use it. However, it doesn't describe the return format (e.g., structured data vs raw text) or potential limitations, which would be helpful given the lack of output schema.
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 schema has 100% description coverage, so the baseline is 3. The description adds value by explaining that 'ALL' returns all common record types and providing context about when different record types are useful (mail servers, ownership verification), which goes beyond the schema's enum list.
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 specific action ('Resolve DNS records') and resource ('for a domain'), with explicit mention of the supported record types. It distinguishes this tool from sibling tools like 'whois_lookup' by focusing on DNS resolution rather than domain registration information.
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 clear context for when to use this tool ('debugging DNS config, finding mail servers, or verifying ownership records'), which helps differentiate it from other tools. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract title, description, Open Graph tags, Twitter Card data, canonical URL, favicon, and author info from a web page. Much faster than scrape_url when you only need headline information — perfect for link unfurls or quick context before deciding to read the full page.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL to extract metadata from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates key traits: it's a read-only extraction tool (implied by 'Extract'), it's optimized for speed ('Much faster than `scrape_url`'), and it's suitable for specific use cases like link unfurls. However, it doesn't mention potential limitations like rate limits, authentication needs, or error handling, which would be useful for a tool interacting with external web pages.
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 efficiently structured in two sentences: the first lists what the tool extracts, and the second provides comparative context and usage scenarios. Every phrase adds value, with no redundant or vague language, making it easy to parse and understand quickly.
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's moderate complexity (single parameter, no output schema, no annotations), the description is largely complete. It covers purpose, usage guidelines, and behavioral context effectively. However, without an output schema, it doesn't detail the return format (e.g., structure of extracted metadata), which could help the agent interpret results. This minor gap prevents a perfect score.
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, with the single parameter 'url' clearly documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides (e.g., no examples or format details), so it meets the baseline of 3. This is adequate since the schema fully describes the 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 specific action ('Extract') and resources ('title, description, Open Graph tags, Twitter Card data, canonical URL, favicon, and author info from a web page'), making the purpose explicit. It distinguishes this tool from siblings by naming a specific alternative (`scrape_url`) and highlighting its specialized focus on metadata extraction rather than full-page scraping.
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 explicit guidance on when to use this tool ('when you only need headline information — perfect for link unfurls or quick context before deciding to read the full page') and when not to use it ('Much faster than `scrape_url` when you only need headline information'), directly naming an alternative tool. This helps the agent choose appropriately based on the need for metadata versus full content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a Slack/Discord-style link preview card for a URL — title, description, hero image, favicon, site name, author. Lighter than get_metadata and formatted for UI display rather than deep analysis. Useful when an agent needs to show a user what a URL contains.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to unfurl |
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 mentions the tool is 'lighter' than get_metadata and outputs a formatted preview, which gives some behavioral context. However, it lacks details on potential limitations (e.g., rate limits, authentication needs, error handling), leaving gaps in transparency for a tool that interacts with external URLs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: it starts with the core purpose, lists key components, compares to a sibling tool, and states the use case—all in three efficient sentences. Every sentence adds value without redundancy, making it easy to parse quickly.
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's moderate complexity (single parameter, no output schema, no annotations), the description is fairly complete: it covers purpose, differentiation, and use case. However, it lacks details on output format (e.g., structure of the preview card) and behavioral aspects like error handling, which could be important for an agent invoking this tool.
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% for the single parameter 'url', which is well-documented in the schema. The description does not add any parameter-specific semantics beyond what the schema provides (e.g., URL format constraints or examples). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
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's purpose: 'Generate a Slack/Discord-style link preview card for a URL' with specific components listed (title, description, hero image, etc.). It distinguishes itself from sibling 'get_metadata' by emphasizing 'lighter' processing and 'formatted for UI display rather than deep analysis,' making its unique role explicit.
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 explicit usage guidance: 'Lighter than `get_metadata` and formatted for UI display rather than deep analysis. Useful when an agent needs to show a user what a URL contains.' This clearly indicates when to use this tool (for UI previews) versus alternatives like 'get_metadata' (for deep analysis), addressing sibling differentiation effectively.
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 its main readable content as clean Markdown. Uses Mozilla Readability to strip navigation, footers, ads, and other boilerplate, then converts the article body to Markdown optimized for LLM consumption. Use this instead of web_search when you already know the URL and need to read the full content. Executes JavaScript (headless Chrome) so it handles dynamic / SPA pages.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL to scrape — must include https:// | |
| wait_for | No | CSS selector to wait for before extracting (for JS-heavy pages) | |
| delay | No | Extra ms to wait after load (max 5000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it uses Mozilla Readability to strip boilerplate, converts to Markdown optimized for LLMs, executes JavaScript with headless Chrome, and handles dynamic/SPA pages. It doesn't mention rate limits, authentication needs, or potential destructive effects, but covers core functionality thoroughly.
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 appropriately sized and front-loaded, with every sentence earning its place: first sentence states core purpose, second explains processing details, third provides usage context, and fourth covers technical capabilities. No wasted 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 no annotations and no output schema, the description does well by explaining the tool's behavior, output format (Markdown), and technical approach. It could improve by mentioning potential limitations (e.g., timeouts, blocked sites) or response structure, but it's largely complete for a scraping tool.
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 the schema already documents all parameters (url, wait_for, delay). The description doesn't add specific meaning beyond what the schema provides, such as examples or edge cases for parameters. Baseline 3 is appropriate when 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 clearly states the tool's purpose with specific verbs ('fetch', 'return') and resources ('web page', 'main readable content as clean Markdown'). It distinguishes from siblings by specifying it's for when you already know the URL, unlike web_search which presumably searches for URLs.
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 explicitly states when to use this tool ('when you already know the URL and need to read the full content') and when not to use it (implied: use web_search when you don't know the URL). It names an alternative ('web_search'), providing clear guidance on tool selection.
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 and return a hosted URL to the image. Supports full-page capture, custom viewport size, device emulation (iPhone/iPad/Pixel/etc.), dark mode, ad/cookie-banner blocking. The returned URL is cached and can be shown to the user or fetched later. Use when you need to visually verify what a page looks like.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL to capture | |
| fullPage | No | Capture the entire scrollable page (default: only viewport) | |
| width | No | Viewport width in px (default 1920) | |
| height | No | Viewport height in px (default 1080) | |
| format | No | Image format (default png) | |
| emulateDevice | No | Emulate a device preset (overrides width/height) | |
| darkMode | No | Render with prefers-color-scheme: dark | |
| blockAds | No | Block advertisement trackers before capture | |
| blockCookieBanners | No | Dismiss GDPR/cookie banners before capture | |
| delay | No | Ms to wait after load before capture |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so effectively. It describes key behavioral traits: the tool returns a hosted URL, that URL is cached and can be shown to users or fetched later, and it supports various capture options (full-page, device emulation, blocking features). However, it doesn't mention rate limits, authentication requirements, or error conditions that might be relevant for a screenshot service.
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 perfectly structured and concise - two sentences that each earn their place. The first sentence establishes core functionality and key features, the second provides usage guidance. There's zero waste or redundancy, and the most important information (what it does and when to use it) 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's moderate complexity (10 parameters, no output schema, no annotations), the description provides good contextual completeness. It explains the tool's purpose, usage context, and key behavioral aspects. However, without an output schema, it could benefit from more detail about the returned URL format, cache duration, or potential error responses to be fully complete.
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?
With 100% schema description coverage, the input schema already documents all 10 parameters thoroughly. The description adds minimal parameter semantics beyond what's in the schema - it mentions 'full-page capture, custom viewport size, device emulation' which are already covered in the schema descriptions. The baseline of 3 is appropriate when 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 clearly states the specific action ('capture a screenshot of a web page') and the resource ('web page'), distinguishing it from all sibling tools which perform analytical, diagnostic, or conversion functions rather than visual capture. It precisely identifies what the tool does without being tautological.
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 explicitly states when to use this tool ('Use when you need to visually verify what a page looks like'), providing clear context for its application. This distinguishes it from siblings like url_to_pdf (for document conversion) or analyze_accessibility (for compliance checking), giving the agent specific guidance on appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a web page to a PDF document and return the hosted file URL. Supports page size (A4/Letter/etc.), orientation, custom margins, headers/footers. Use for generating reports, archiving pages, or producing printable documentation.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to convert to PDF | |
| format | No | Page size (default A4) | |
| landscape | No | Landscape orientation (default false) | |
| printBackground | No | Include CSS backgrounds (default true for styled pages) | |
| scale | No | Zoom factor (0.1–2, default 1) | |
| darkMode | No | Render with dark mode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks critical behavioral details. It doesn't mention authentication requirements, rate limits, timeout behavior, file retention policies, or error conditions. While it describes the core function, important operational context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded with the core function first, followed by key capabilities and usage scenarios. Both sentences earn their place by providing essential information without redundancy. The structure is logical and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no annotations, and no output schema, the description is adequate but incomplete. It covers the basic purpose and usage but lacks behavioral transparency and detailed parameter guidance. The absence of output schema means the description should ideally mention the return format more explicitly.
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?
With 100% schema description coverage, the baseline is 3. The description adds minimal value beyond the schema by listing parameter categories ('page size, orientation, custom margins, headers/footers') but doesn't provide additional semantic context about how these parameters interact or affect output quality.
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 specific action ('Render a web page to a PDF document') and resource ('hosted file URL'), distinguishing it from siblings like screenshot (visual capture) or scrape_url (content extraction). It explicitly mentions the output format and key capabilities.
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 clear context for when to use the tool ('generating reports, archiving pages, or producing printable documentation'), which differentiates it from analysis or diagnostic siblings. However, it doesn't explicitly state when NOT to use it or name specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web and get ranked results with titles, URLs, and snippets. Powered by aggregated search engines (Google, Bing, DuckDuckGo, Brave). Best when you need fresh facts, news, or to find pages to read in detail with scrape_url. Returns up to 50 results with position, title, URL, snippet, source engine, and published date if known.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query — e.g. 'claude 4 release date' | |
| category | No | Result category. Default: general. Use 'news' for recent events, 'science' for papers. | |
| limit | No | Max results to return (default 10) | |
| time | No | Only results from the last day/week/month/year | |
| language | No | BCP-47 language code, e.g. 'en', 'es' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: the tool is powered by aggregated search engines (Google, Bing, etc.), returns up to 50 results with specific fields (position, title, URL, snippet, source engine, published date), and supports fresh content retrieval. However, it lacks details on rate limits, authentication needs, or error handling, which are common for web search tools.
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 appropriately sized and front-loaded, with the first sentence stating the core functionality. Each subsequent sentence adds value: engine sources, usage guidelines, and result details. There is no wasted text, and the structure flows logically from purpose to specifics.
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's moderate complexity (5 parameters, no output schema, no annotations), the description is mostly complete. It covers purpose, usage, behavioral traits, and result format. However, it lacks explicit information on output structure or error cases, which could be helpful for an agent invoking the tool without an output schema.
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%, providing detailed descriptions for all 5 parameters in the input schema. The description adds minimal parameter semantics beyond the schema, only implying the 'query' parameter through examples like 'fresh facts, news'. It does not clarify parameter interactions or provide additional context, so it meets the baseline of 3 when 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 clearly states the tool's purpose with specific verbs ('search the web', 'get ranked results') and resources ('titles, URLs, and snippets'). It distinguishes this from sibling tools by mentioning its aggregation of search engines and its relationship to 'scrape_url' for detailed reading, making it distinct from other tools like 'get_metadata' or 'preview_link'.
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 explicit guidance on when to use this tool: 'Best when you need fresh facts, news, or to find pages to read in detail with `scrape_url`.' It also implies alternatives by referencing 'scrape_url' for detailed reading, helping the agent choose between this search tool and other content extraction tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diff two URLs and get a summary of what changed — added lines, removed lines, modified sections. Modes: 'text' (visible content only), 'structure' (DOM/HTML structural changes), 'full' (both). Great for competitor monitoring, change detection, and verifying deployments.
| Name | Required | Description | Default |
|---|---|---|---|
| url1 | Yes | First URL | |
| url2 | Yes | Second URL to compare against url1 | |
| mode | No | What to diff — 'text' for content only (default), 'structure' for HTML changes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks critical behavioral details: it doesn't mention authentication needs, rate limits, error handling, or output format (e.g., JSON summary vs. raw diff). It hints at modes but doesn't explain their practical implications beyond brief labels.
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 front-loaded with core functionality, uses efficient sentences with zero waste, and structures information logically (purpose, modes, use cases). Every sentence earns its place by adding distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity (3 params, no output schema, no annotations), the description is adequate but incomplete: it covers purpose and modes well but misses behavioral transparency and output details, leaving gaps for an agent to invoke the tool effectively without further 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 description coverage is 100%, so the baseline is 3. The description adds minimal value by listing mode options ('text', 'structure', 'full') and implying 'full' combines both, but doesn't clarify semantics beyond what the schema's enum and descriptions already provide for parameters.
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's purpose with specific verbs ('diff', 'get a summary') and resources ('two URLs', 'web pages'), distinguishing it from sibling tools like 'scrape_url' or 'get_metadata' by focusing on comparison rather than extraction or analysis of single pages.
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 clear context for when to use the tool ('competitor monitoring, change detection, and verifying deployments'), but does not explicitly state when not to use it or name alternatives among siblings, such as 'scrape_url' for single-page content extraction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get WHOIS registration info for a domain — registrar, creation/expiry dates, name servers, ownership (where not redacted), DNSSEC status. Useful for domain research, expiry monitoring, and detecting recently registered domains (often phishing signals).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name — 'example.com' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: it's a read operation that returns registration data, notes that ownership info may be redacted, and implies it queries external WHOIS databases. However, it doesn't mention rate limits, authentication needs, error conditions, or response format details.
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 efficiently structured in two sentences: the first states the core functionality with specific data fields, the second provides usage contexts. Every phrase adds value with zero redundant information, making it easy to parse and understand quickly.
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 single-parameter read tool with no output schema, the description provides good context: it explains what data is returned, when to use it, and limitations (redacted ownership). It could be more complete by mentioning response format or error handling, but covers the essential aspects well given the tool's simplicity.
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% with a single well-documented parameter, so the baseline is 3. The description doesn't add parameter-specific information beyond what the schema provides (domain name format, constraints), but it does reinforce the tool's domain-focused purpose.
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's purpose with specific verbs ('Get WHOIS registration info') and resources ('domain'), listing exact data fields returned (registrar, dates, name servers, ownership, DNSSEC status). It distinguishes from siblings like dns_lookup by focusing on registration metadata rather than DNS resolution.
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 clear context for when to use this tool ('domain research, expiry monitoring, detecting recently registered domains'), including specific use cases like phishing detection. However, it doesn't explicitly state when NOT to use it or name alternatives among siblings (e.g., when to use dns_lookup instead).
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.0analyze_accessibilityanalyze_seocheck_broken_linkscheck_sslcheck_statusdetect_tech_stackdns_lookupget_metadatapreview_linkscrape_urlscreenshoturl_to_pdfweb_searchwebsite_diffwhois_lookupScored across 15 tools
Most tools target distinct tasks, but several have clear overlap: preview_link and get_metadata both return page metadata, and analyze_seo and check_broken_links both cover link health. The descriptions help differentiate them, but an agent could still reasonably pick the wrong one for a specific request.
The majority of tools follow a verb_noun pattern (check_status, analyze_seo, scrape_url), but several break that pattern: dns_lookup, web_search, whois_lookup, url_to_pdf, website_diff, and screenshot. This mix of conventions is readable but not highly predictable.
With 15 tools, this is right at the upper boundary of the well-scoped range, and each tool provides a distinct analysis or retrieval capability. The count feels justified for a general web-research and page-AQA utility set.
The set thoroughly covers web search, scraping, metadata extraction, screenshots, PDF generation, SEO, accessibility, broken links, SSL, DNS, WHOIS, and tech-stack detection. Minor gaps exist, like no tool for continuous change tracking or advanced domain reputation checks, but those are not core to the apparent scope.
Hosted MCP with 91 agent tools: X, domains, SEO, Maps, Trends, Search, YouTube, TikTok, and more.
Your agent needs the open web — searched by more than one engine, and read as clean markdown rather than raw HTML. **What you can ask for** • "Search this question with two providers and tell me where they disagree." • "Scrape these 40 URLs into markdown, in one batch." • "Crawl this documentation site and give me every page." • "Do deep research on this topic and cite the sources." • "Find the academic papers behind this claim." **How to use it** Point any MCP client at https://mcp.aisa.one/search/mcp and sign in with OAuth — there is no key to create or paste. 30 tools across several independent providers: Tavily and Exa search, answers, contents and agent runs; Firecrawl scrape, batch scrape, crawl, map and search; Perplexity Sonar, Sonar Pro, reasoning and deep research; Oxylabs AI search and LLM jobs; OpenAI and Anthropic web search; and scholarly search. **Why this rather than the source** Several independent indexes behind one account, because one engine's blind spot is not visible from inside it. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Find the page here, then ask the same agent who links to it or how much traffic it gets — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/seo-serp/mcp for the Google results page itself, https://mcp.aisa.one/seo-serp-other-engines/mcp for Bing, Baidu and Naver.
Free web search for AI agents. No API key required. Hosted MCP in active development.
Your agent needs live data — a competitor's traffic, who to contact there, what people are saying, what Google and ChatGPT answer about you, a company's filings. Normally that is six vendor accounts, six sets of keys and six SDKs. This is one URL. **What you can ask for** • "How much traffic does stripe.com get, where does it come from, and who competes for the same keywords?" • "Find 20 Series-B fintech companies in Germany and the heads of marketing there, with emails." • "Does ChatGPT mention our brand when someone asks for the best CRM — and what does it cite?" • "What is X saying about $NVDA today, and what did the stock actually do?" • "Search the web for this, then scrape the three best pages into markdown." **How to use it** Point any MCP client at https://mcp.aisa.one/mcp and sign in with OAuth — there is no key to create or paste. Then just ask: the agent calls search to find the right operation and use to run it. **Why this rather than the source** 26 sources behind one account and one bill — DataForSEO, Semrush, Ahrefs, Similarweb, Apollo, X/Twitter, Instagram, Reddit, Pinterest, YouTube, Tavily, Exa, Perplexity, Firecrawl, CoinGecko, Kalshi, Polymarket, AgentMail and more, 580+ operations. tools/list returns five tools, not 580, so the introduction does not eat your context window. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** One slice at a time: https://mcp.aisa.one/seo/mcp · /finance/mcp · /social/mcp · /search/mcp · /sales/mcp · /mail/mcp · /gtm/mcp, or a single provider like /twitter-api/mcp. Same account, fewer tools listed, and search still reaches everything. Full list at https://mcp.aisa.one/servers
