Provides a tool to convert any web URL into clean Markdown, facilitating easier content processing and analysis by LLMs.
The complete web data pipeline for AI agents. Search, Extract, Crawl in One API.
A Model Context Protocol (MCP) server with 15 tools covering web search, scraping, extraction, crawling, and autonomous data gathering via the SearchClaw API.
npx searchclaw-mcpOr install globally:
npm install -g searchclaw-mcpRelated MCP server: MCP Server Metasearch
Get your API key from searchclaw.dev and add the server to your MCP client config.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"searchclaw": {
"command": "npx",
"args": ["-y", "searchclaw-mcp"],
"env": {
"SEARCHCLAW_API_KEY": "your-api-key"
}
}
}
}claude mcp add searchclaw -- npx -y searchclaw-mcpThen set your API key in your environment:
export SEARCHCLAW_API_KEY="your-api-key"Add to .cursor/mcp.json in your project:
{
"mcpServers": {
"searchclaw": {
"command": "npx",
"args": ["-y", "searchclaw-mcp"],
"env": {
"SEARCHCLAW_API_KEY": "your-api-key"
}
}
}
}Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"searchclaw": {
"command": "npx",
"args": ["-y", "searchclaw-mcp"],
"env": {
"SEARCHCLAW_API_KEY": "your-api-key"
}
}
}
}Tool | Description | Credits |
| Web search — organic results | 1 |
| RAG-ready search with context and sources (primary tool for AI agents) | 2 |
| Search recent news articles | 1 |
| Search for images with metadata | 1 |
| Autocomplete / query suggestions | 1 |
Tool | Description | Credits |
| Extract structured data from a URL using a JSON schema | 5 |
| Convert any URL to clean markdown | 2 |
| Capture a full-page screenshot of a URL | 2 |
Tool | Description | Credits |
| Async bulk crawl with optional structured extraction | 1/page |
| Check status of an async crawl job | 0 |
| Discover all URLs on a domain (sitemap alternative) | 2 |
Tool | Description | Credits |
| Search + extract in one call — the killer feature for RAG pipelines | 3+ |
| Interactive browser actions (click, type, scroll) | 5 |
| Autonomous data gathering from natural language prompts | variable |
Tool | Description | Credits |
| Check your remaining API credits | 0 |
Feature | SearchClaw | Firecrawl | Tavily |
Web search | ✅ | ❌ | ✅ |
AI search (RAG) | ✅ | ❌ | ✅ |
Extract with schema | ✅ | ✅ | ❌ |
Crawl | ✅ | ✅ | ❌ |
Pipeline (search + extract) | ✅ | ❌ | ❌ |
Autonomous agent | ✅ | ❌ | ❌ |
Browser actions | ✅ | ❌ | ❌ |
News & image search | ✅ | ❌ | ✅ |
Screenshot | ✅ | ✅ | ❌ |
MCP server | ✅ | ✅ | ✅ |
Free tier | ✅ 500 credits/mo | ❌ | ✅ 1000 credits/mo |
Get started at searchclaw.dev.
MIT
Autonomous data gathering agent. Describe what you need in natural language and the agent will search, browse, and extract data. Costs variable credits.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Natural language description of data to gather | |
| schema | No | JSON schema for structured output | |
| max_credits | No | Max credits to spend (default: 10) | |
| max_sources | No | Max sources to consult (default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: autonomous operation, natural language interface, multi-method approach (search, browse, extract), and variable cost structure. However, it doesn't mention rate limits, authentication needs, error conditions, or what happens when credit limits are reached.
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 concise with two sentences that efficiently convey the core functionality and cost consideration. It's front-loaded with the main purpose. Every sentence earns its place, though it could potentially benefit from slightly more structure for complex tool behavior.
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 complexity (autonomous agent with 4 parameters, no output schema, and no annotations), the description provides a reasonable overview but leaves gaps. It explains what the tool does but doesn't detail return values, error handling, or how it differs from the many sibling tools. For a sophisticated autonomous agent, more behavioral context would be helpful.
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 thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting for parameter documentation.
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 as an 'autonomous data gathering agent' that will 'search, browse, and extract data' based on natural language input. It specifies the verb (gather data) and resource (data), but doesn't explicitly differentiate from siblings like 'search', 'browse', or 'extract' which suggests this may be a more comprehensive wrapper tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating 'Describe what you need in natural language' and mentions cost considerations ('Costs variable credits'), but doesn't provide explicit guidance on when to use this versus the many sibling tools like 'search', 'browse', or 'extract'. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Interactive browser actions on a URL. Perform clicks, form fills, scrolling, and more. Costs 5 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to browse | |
| actions | Yes | Array of browser action objects (click, type, scroll, etc.) |
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 adds useful context beyond the schema by mentioning the cost ('Costs 5 credits'), which implies resource consumption and potential rate limits. However, it lacks details on permissions, error handling, or what 'interactive' entails (e.g., whether it simulates user behavior or requires authentication). The description doesn't contradict annotations, as none are given.
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 with two sentences that efficiently convey core functionality and cost. The first sentence front-loads the main purpose ('Interactive browser actions on a URL'), and the second adds critical behavioral context ('Costs 5 credits'). There is no wasted text, though it could be slightly more structured by explicitly listing key use cases.
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 (interactive browser actions with 2 parameters) and no output schema, the description is partially complete. It covers the basic purpose and cost but lacks details on return values, error conditions, or examples of action objects. With no annotations to supplement, the agent might struggle with implementation specifics, though the schema provides parameter definitions.
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 both parameters ('url' and 'actions') adequately. The description adds minimal value beyond the schema by implying that actions include 'clicks, form fills, scrolling, and more', but this is redundant with the schema's description of 'Array of browser action objects'. No additional syntax, format, or constraints are provided, meeting the baseline for high schema coverage.
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 ('Perform clicks, form fills, scrolling, and more') and identifies the resource ('Interactive browser actions on a URL'). It distinguishes from sibling tools like 'crawl' or 'screenshot' by emphasizing interactive actions rather than passive retrieval or capture. However, it doesn't explicitly differentiate from all siblings, such as 'extract' which might also involve browser interaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'Costs 5 credits' which hints at resource considerations but doesn't specify use cases, prerequisites, or exclusions. For example, it doesn't clarify when to choose 'browse' over 'crawl' for data extraction or 'screenshot' for visual capture, leaving the agent with minimal contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start an async bulk crawl with optional extraction. Returns a job ID to poll with job_status. Costs 1 credit per page.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Starting URL to crawl | |
| max_pages | No | Maximum pages to crawl (default: 10) | |
| schema | No | JSON schema for structured extraction per page |
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's an async operation, returns a job ID for polling, and has a cost implication ('Costs 1 credit per page'). It doesn't cover rate limits, authentication needs, or error handling, but provides substantial 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?
Two sentences with zero waste: the first states purpose and key behavior, the second adds critical cost information. Every word earns its place, and the most important information (async nature and cost) 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 3-parameter tool with no annotations and no output schema, the description provides good operational context (async, polling, cost). It doesn't explain return values beyond the job ID or error scenarios, but given the schema coverage and clear purpose, it's reasonably complete for an agent to use 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 the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain how 'schema' relates to 'optional extraction'). 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 specific action ('Start an async bulk crawl'), the resource being acted upon (web pages), and the optional capability ('with optional extraction'). It distinguishes from sibling tools like 'browse' (likely single-page) and 'extract' (likely focused on extraction without crawling).
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 ('Start an async bulk crawl'), mentions the polling mechanism ('Returns a job ID to poll with job_status'), and implies an alternative to single-page operations. However, it doesn't explicitly state when NOT to use it or compare it to all relevant siblings like 'browse' or 'extract'.
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 a URL using a JSON schema. Costs 5 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to extract data from | |
| schema | No | JSON schema defining the structure to extract | |
| prompt | No | Natural language instruction for extraction |
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 adds valuable context beyond the input schema by stating 'Costs 5 credits,' which informs about resource usage. However, it doesn't cover other behavioral aspects like rate limits, error handling, or output format, so it's not fully comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: 'Extract structured data from a URL using a JSON schema. Costs 5 credits.' Every sentence earns its place by stating the core purpose and a key behavioral trait (cost), with zero waste or redundancy.
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 3 parameters, no annotations, no output schema, and involves data extraction (a moderately complex operation), the description is somewhat incomplete. It covers the purpose and cost but lacks details on output, error cases, or integration with siblings. However, the high schema coverage helps offset some gaps, making it minimally adequate.
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 description coverage is 100%, meaning the input schema already documents all parameters (url, schema, prompt) well. The description doesn't add any additional meaning or details about the parameters beyond what's in the schema, so it meets the baseline score of 3 without compensating further.
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: 'Extract structured data from a URL using a JSON schema.' It specifies the verb ('extract'), resource ('structured data'), and mechanism ('from a URL using a JSON schema'). However, it doesn't explicitly distinguish this tool from sibling tools like 'browse', 'crawl', or 'search', which might also involve URL processing, so it doesn't reach the highest score.
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 by mentioning 'Costs 5 credits,' which suggests a cost consideration, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'browse' or 'crawl'. There's no mention of prerequisites, exclusions, or specific scenarios where this tool is preferred, leaving usage context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for images using SearchClaw. Returns image URLs and metadata. Costs 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Image search query |
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 the cost ('Costs 1 credit'), which is useful behavioral context. However, it lacks details on rate limits, authentication needs, error handling, or what 'metadata' includes. The description adds some value but is incomplete for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: two sentences that directly state the tool's function and cost. 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 (search with cost), no annotations, and no output schema, the description is minimally adequate. It covers the core purpose and cost but lacks details on output format (beyond 'URLs and metadata'), error cases, or integration context. It's complete enough for basic use but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter 'q' as 'Image search query'. The description adds no additional parameter semantics beyond what the schema provides. Baseline 3 is appropriate when 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: 'Search for images using SearchClaw' specifies the verb and resource. It distinguishes from siblings like 'search' or 'search_ai' by focusing on images. However, it doesn't explicitly differentiate from potential image-related siblings (none listed), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'images' over 'search' or 'search_ai', nor does it specify prerequisites or exclusions. The cost mention ('Costs 1 credit') is operational but not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of an async job (e.g. crawl). Costs 0 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Job ID returned by crawl or other async endpoints |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and adds valuable behavioral context: it specifies that the tool 'Costs 0 credits', which is a key operational detail not inferable from the schema. However, it lacks information on rate limits, error handling, or 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 front-loaded with the core purpose and includes only essential additional information ('Costs 0 credits'). It consists of two concise sentences with zero waste, making it highly 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 low complexity (1 parameter, no output schema, no annotations), the description is reasonably complete: it covers purpose, usage context, and a key behavioral trait (cost). However, it could benefit from details on output format or error cases to be fully comprehensive.
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 description coverage is 100%, so the parameter 'job_id' is fully documented in the schema. The description adds minimal semantics by referencing 'Job ID returned by crawl or other async endpoints', but this largely repeats 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 verb ('Check') and resource ('status of an async job'), with specific examples ('e.g. crawl') that help distinguish it from sibling tools like 'crawl' or 'extract'. It precisely defines 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 implicitly indicates when to use this tool—for checking async job status—by referencing jobs returned by 'crawl or other async endpoints', but it does not explicitly state when not to use it or name alternatives among siblings. This provides clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover all URLs on a domain. Returns a sitemap-like list. Costs 2 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Domain or URL to map | |
| max_pages | No | Maximum URLs to discover (default: 100) | |
| search | No | Filter URLs matching this keyword |
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 adds value by disclosing cost ('Costs 2 credits') and output format ('Returns a sitemap-like list'), which are not covered by the input schema. However, it does not mention rate limits, authentication needs, or error handling.
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 three concise sentences that each add value: stating the purpose, output, and cost. There is no wasted text, and it efficiently communicates essential 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?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is fairly complete. It covers purpose, output, and cost, but could improve by addressing error cases or providing more context on when to use versus siblings. The lack of an output schema means the description should ideally explain return values more thoroughly.
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 three parameters. The description does not add any parameter-specific details beyond what the schema provides, such as examples or constraints, resulting in a baseline score of 3.
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 ('discover all URLs') and resource ('on a domain'), and distinguishes it from siblings like 'crawl' or 'search' by focusing on sitemap-like discovery rather than content extraction or query-based searching.
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 URL discovery on domains, but does not explicitly state when to use this tool versus alternatives like 'crawl' or 'search'. It provides some context (sitemap-like list) but lacks clear exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a URL to clean markdown. Costs 2 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to convert to markdown |
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 successfully communicates the cost implication ('Costs 2 credits'), which is valuable behavioral information. However, it doesn't describe other important behavioral aspects like rate limits, error conditions, authentication requirements, or what 'clean markdown' specifically means in terms of formatting.
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 concise with just two sentences that each serve distinct purposes: the first states the core functionality, the second provides critical usage information. There's zero wasted language, and the most important 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 single-parameter tool with 100% schema coverage but no output schema, the description provides adequate basic information about what the tool does and its cost. However, it doesn't describe the output format (what 'clean markdown' looks like) 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 description coverage is 100%, with the single parameter 'url' already well-documented in the schema. The description doesn't add any additional parameter semantics beyond what the schema provides, so it meets the baseline expectation but doesn't enhance understanding of 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 ('Convert a URL to clean markdown') and the resource ('URL'), making the purpose immediately understandable. It distinguishes itself from siblings like 'browse', 'crawl', or 'extract' by focusing specifically on markdown conversion rather than general web interaction or content extraction.
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 about when to use this tool ('Convert a URL to clean markdown') and includes important usage information ('Costs 2 credits'). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, which would be needed for a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for recent news articles using SearchClaw. Costs 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | News search query |
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 adds valuable context about cost ('Costs 1 credit'), which is a behavioral trait not covered elsewhere. However, it lacks details on rate limits, authentication needs, response format, or pagination behavior, leaving significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of just one sentence that efficiently conveys the core purpose and key behavioral detail (cost). Every word earns its place, with 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?
Given the tool's moderate complexity (a search operation with cost implications), no annotations, and no output schema, the description is somewhat incomplete. It covers the basic purpose and cost but lacks details on return values, error handling, or operational constraints. The description provides a minimum viable explanation but has clear gaps in 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?
The schema description coverage is 100%, with the single parameter 'q' documented as 'News search query'. The description doesn't add any meaning beyond what the schema provides, such as query syntax examples or search scope details. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
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 a specific verb ('Search') and resource ('recent news articles'), and identifies the service ('using SearchClaw'). It doesn't explicitly distinguish from sibling tools like 'search' or 'search_ai', but the focus on news articles provides some implicit differentiation.
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 through 'recent news articles' and the cost information ('Costs 1 credit'), suggesting when this tool might be appropriate. However, it doesn't provide explicit guidance on when to use this versus alternatives like the 'search' or 'search_ai' sibling tools, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search + extract in one call. The killer feature — find pages via search, then extract structured data from top results. Costs 3+ credits.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query to find relevant pages | |
| schema | Yes | JSON schema defining data to extract from results | |
| max_results | No | Max search results (default: 10) | |
| extract_from | No | Number of top results to extract from (default: 5) |
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 adds valuable context about costs ('Costs 3+ credits'), which is not covered by the schema. However, it doesn't describe other behavioral traits like rate limits, authentication needs, or what happens during execution (e.g., error handling, timeouts), leaving gaps for a mutation-like tool.
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 three concise sentences that each earn their place: the first states the core functionality, the second elaborates on the feature, and the third adds critical cost information. There is zero waste or redundancy.
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 complexity (combining search and extraction), no annotations, and no output schema, the description is incomplete. It covers purpose and costs but lacks details on behavioral aspects (e.g., execution flow, error cases) and output format, which are essential for an agent to use it correctly. It's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no specific parameter semantics beyond what the schema provides (e.g., it doesn't explain 'schema' beyond 'JSON schema defining data to extract'). 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 tool's purpose with specific verbs ('search + extract') and resources ('pages', 'structured data'), distinguishing it from siblings like 'search', 'extract', and 'crawl' by emphasizing the combined functionality. It explicitly mentions the 'killer feature' of finding pages via search and extracting structured data from top results in one call.
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 ('find pages via search, then extract structured data from top results'), implying it's for combined search-and-extract tasks. However, it lacks explicit guidance on when not to use it or alternatives (e.g., using 'search' and 'extract' separately), which prevents a perfect score.
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 URL. Costs 2 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to screenshot | |
| full_page | No | Capture full page (default: true) |
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 mentions the cost implication ('Costs 2 credits'), which is valuable operational context. However, it doesn't describe what happens on failure, whether authentication is needed, rate limits, or what format the screenshot is returned in (though there's no output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that each serve a clear purpose: stating the tool's function and disclosing cost implications. There's zero wasted language, and it's front-loaded with the core functionality.
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 2 parameters, 100% schema coverage, and no output schema, the description provides basic operational context (cost) but lacks information about return format, error conditions, or performance characteristics. Given the mutation nature of creating a screenshot and no annotations, more behavioral context would be helpful.
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 fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 is appropriate when the schema does all the parameter documentation work.
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') and resource ('of a URL'), with no ambiguity. It distinguishes itself from sibling tools like 'browse' or 'images' by focusing specifically on screenshot capture functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'browse' or 'images' from the sibling list. It mentions a cost ('Costs 2 credits') which could imply usage constraints, but doesn't specify when this tool is preferred over other methods of obtaining visual content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web using SearchClaw. Returns organic web results. Costs 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query |
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 successfully reveals key behavioral traits: the tool performs web searches, returns organic results (not ads or other content types), and has a cost implication (1 credit per use). This covers the core operational behavior, though it doesn't mention rate limits, authentication needs, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured in a single sentence that efficiently communicates purpose, result type, and cost. Every word earns its place with zero redundancy or wasted verbiage.
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 search tool with one parameter, 100% schema coverage, and no output schema, the description provides adequate but minimal context. It covers what the tool does and cost implications, but doesn't explain result format, pagination, error cases, or how it differs from sibling tools like 'search_ai'. Given the simplicity of the tool, this is minimally viable but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'q' clearly documented as 'Search query'. The description doesn't add any additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating value.
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: 'Search the web using SearchClaw' with the specific action 'search' and resource 'web'. It distinguishes from some siblings like 'images' or 'news' by specifying 'organic web results', but doesn't explicitly differentiate from 'search_ai' which appears to be a similar search tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by mentioning 'Costs 1 credit', which implies resource constraints, and 'Returns organic web results' which clarifies the type of results. However, it doesn't explicitly state when to use this tool versus alternatives like 'search_ai' or 'browse', nor does it provide clear when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
RAG-ready web search with context and sources. Primary tool for AI agents — returns structured context optimized for LLM consumption. Costs 2 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query |
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 adds context beyond the input schema by stating the tool 'returns structured context optimized for LLM consumption' and disclosing a cost ('Costs 2 credits'), which are critical behavioral traits not inferable from the schema alone. However, it doesn't cover other potential behaviors like rate limits, error handling, or 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 highly concise and front-loaded, with every sentence earning its place. The first sentence establishes the core functionality, the second positions it as the primary tool, and the third adds critical cost information—all without 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 complexity (a search tool with cost implications) and the lack of annotations and output schema, the description does a good job of covering key aspects like purpose, optimization for AI, and cost. However, it doesn't explain the return values or structure in detail, which would be helpful since there's no output schema, leaving some gaps in 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?
The schema description coverage is 100%, with the single parameter 'q' fully documented in the schema as 'Search query'. The description doesn't add any meaning beyond this, such as query formatting tips or examples. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 ('RAG-ready web search') and resources ('with context and sources'), distinguishing it from generic search tools. It explicitly positions itself as the 'Primary tool for AI agents' and specifies the output format ('structured context optimized for LLM consumption'), making its role distinct from sibling tools like 'search' or 'browse'.
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 ('Primary tool for AI agents' and 'RAG-ready web search'), implying it's optimized for AI workflows rather than general browsing. However, it doesn't explicitly state when not to use it or name specific alternatives among the sibling tools, such as when to choose 'search' instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get autocomplete suggestions for a search query using SearchClaw. Costs 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Partial query for autocomplete suggestions |
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 adds useful context about cost ('Costs 1 credit'), which is a behavioral trait not covered elsewhere. However, it lacks details on rate limits, error handling, or response format, leaving gaps in transparency for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: 'Get autocomplete suggestions for a search query using SearchClaw. Costs 1 credit.' Every sentence earns its place by stating the purpose and a key behavioral trait (cost), with zero wasted words, making it highly 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?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is somewhat complete but has gaps. It covers purpose and cost but lacks details on output format, error cases, or integration with siblings. Without annotations or output schema, more context would be helpful, making it adequate but not fully comprehensive.
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 parameter 'q' documented as 'Partial query for autocomplete suggestions.' The description doesn't add any additional meaning beyond this, such as examples or constraints. According to the rules, with high schema coverage (>80%), the baseline is 3, which is appropriate here.
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: 'Get autocomplete suggestions for a search query using SearchClaw.' It specifies the verb ('Get'), resource ('autocomplete suggestions'), and system ('SearchClaw'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'search' or 'search_ai', which prevents a perfect score.
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 by mentioning 'Costs 1 credit,' which suggests a cost consideration, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'search' or 'search_ai'. No when-not-to-use scenarios or prerequisites are mentioned, leaving usage somewhat ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check your SearchClaw API credit balance. Costs 0 credits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 successfully communicates that this is a read operation ('Check') and importantly reveals the cost implication ('Costs 0 credits'), which is valuable behavioral information not captured elsewhere. It doesn't mention rate limits, authentication requirements, or error conditions, leaving some behavioral aspects uncovered.
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 concise at just two short sentences that each earn their place. The first sentence states the core purpose, and the second adds crucial behavioral information about cost. There's zero wasted verbiage or redundancy.
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 0-parameter tool with no annotations and no output schema, the description provides good coverage of what the tool does and its cost implication. However, it doesn't describe what the return value looks like (e.g., current balance, remaining credits, etc.), which would be helpful given the lack of output schema. The description is mostly complete but could benefit from a hint about the response format.
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 0 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, which is correct. No additional parameter semantics are needed or provided.
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 ('Check') and resource ('SearchClaw API credit balance'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'search', 'crawl', or 'extract' by focusing on account/credit status rather than content retrieval or processing operations.
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 about when to use this tool - specifically to check API credit balance. However, it doesn't explicitly mention when NOT to use it or name alternative tools for related functions (like checking usage history or billing details), which prevents a perfect score.
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.
v2.0.1agentbrowsecrawlextractimagesjob_statusmapmarkdownnewspipelinescreenshotsearchsearch_aisuggestusageScored across 15 tools
Most tools have distinct purposes (e.g., search, crawl, extract, screenshot), but there is some overlap between 'search' and 'search_ai' (both perform web searches) and 'extract' and 'pipeline' (both extract structured data). Descriptions help differentiate them, but an agent might occasionally misselect between these pairs.
Tool names are mostly consistent, using lowercase snake_case throughout (e.g., 'job_status', 'search_ai'). However, there is one deviation: 'agent' is a single word while others follow a verb_noun or noun pattern. This minor inconsistency does not significantly hinder readability.
With 15 tools, the count is well-scoped for a web search and data extraction server. Each tool serves a clear purpose, such as browsing, crawling, extracting, and checking usage, without feeling bloated or insufficient for the domain.
The tool set provides comprehensive coverage for web search and data extraction tasks, including search variants (search, search_ai, news, images), data gathering (crawl, map), extraction (extract, pipeline, markdown), browser interaction (browse, screenshot), job management (job_status), and utility (suggest, usage). No obvious gaps exist for the server's purpose.
Hosted MCP with 91 agent tools: X, domains, SEO, Maps, Trends, Search, YouTube, TikTok, and more.
Scrape, crawl and search the web for AI agents via MCP.
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.
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
