AI 에이전트 앞에 QuanticData Data API를 배치하는 단일 파일, 제로 의존성 MCP 서버입니다: 페이지 스크래핑, Google/Bing/DuckDuckGo/Yandex 검색 실행, 사이트 매핑 또는 크롤링, URL SEO 감사, 그리고 의미론적 입력으로 31개의 즉시 사용 가능한 Collectors 중 하나를 실행할 수 있습니다.
SDK 없음, 빌드 단계 없음, node_modules 없음. Node.js 18+ 및 파일 하나면 충분합니다.
git clone https://github.com/quantumproxies/quanticdata-mcp-server
cd quanticdata-mcp-server
QUANTICDATA_API_KEY=qd_live_your_key_here node server.mjsapp.quanticdata.io에서 키를 받으세요 — 무료 월별 할당량이 있으며 카드가 필요 없습니다. 현재 수치는 quanticdata.io의 가격을 참조하세요.
Claude Code
claude mcp add quanticdata \
-e QUANTICDATA_API_KEY=qd_live_your_key_here \
-- node /absolute/path/to/quanticdata-mcp-server/server.mjsClaude Desktop — claude_desktop_config.json
{
"mcpServers": {
"quanticdata": {
"command": "node",
"args": ["/absolute/path/to/quanticdata-mcp-server/server.mjs"],
"env": { "QUANTICDATA_API_KEY": "qd_live_your_key_here" }
}
}
}Cursor — .cursor/mcp.json, 위와 동일한 형식입니다.
stdio MCP를 지원하는 모든 클라이언트가 작동합니다: 서버는 initialize, tools/list, tools/call, ping을 구현하며, 이는 도구 전용 서버의 완전한 표면입니다.
Related MCP server: Spider MCP Server
도구 | 에이전트가 얻는 것 | 가격 |
| 하나의 URL → Markdown / HTML / 텍스트, CSS 또는 AI 추출, 선택적 렌더링 | $0.0002 |
| 자연 검색 결과 + 관련 검색어, 4개 엔진, 18개 세로 분야 | $0.0005부터 |
| 사이트맵 + 홈페이지 링크의 모든 URL, 합계 포함 | $0.0005 |
| 비동기 BFS 크롤링 → 페이지별 Markdown | 페이지당 $0.0003 |
| URL의 no-JS vs 렌더링된 뷰, 차이 비교, 봇 대상 메타 포함 | $0.0012 |
| 카탈로그: 스키마, 예시, 상태, 단가 | 무료 |
| 의미론적 입력으로 하나의 Collector 실행 | 행당 $0.0004부터 |
| 하나의 실행과 전달된 행 | 무료 |
모든 것은 성공 시 지불 방식입니다: 실패한 호출은 비용이 들지 않습니다.
node smoke-test.mjs # handshake + tools/list, no API key needed또는 직접 조작해 보세요 — stdin에서 newline으로 구분된 JSON-RPC입니다:
printf '%s\n' \
'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"cli","version":"1"}}}' \
'{"jsonrpc":"2.0","id":2,"method":"tools/list"}' \
| node server.mjs"quanticdata.io를 매핑한 다음, 가장 최근 블로그 게시물 5개를 스크래핑하고 주제를 요약해 줘."
"미국과 독일에서 serp api pricing을 검색하고 상위 10개 결과가 어떻게 다른지 알려줘."
"우리 가격 페이지에 SEO 감사를 실행해 — JavaScript 없이도 인덱싱 가능한가?"
"list_collectors를 사용한 다음, local_business_leads로 오스틴의 치과 클리닉 40곳을 가져와."
마지막 것이 내면화할 가치가 있는 패턴입니다: 에이전트가 먼저 카탈로그를 읽게 한 다음 Collector를 선택하게 하세요. 스키마는 모델이 올바르게 선택할 수 있도록 정확히 게시된 것입니다.
변수 | 기본값 | 참고 |
| — | 필수; 키는 |
|
| 프록시 또는 스테이징 호스트를 위해 다른 곳을 지정 |
API의 오류는 프로토콜 오류가 아닌 isError: true가 포함된 도구 결과로 반환되므로, 모델이 대화가 중단되는 대신 메시지를 읽고 스스로 수정할 수 있습니다.
MCP 서버 페이지 · 문서
MIT 라이선스.
Fetch one Collector run and its delivered rows by run_id.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | The run_id returned by run_collector. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states the operation is a 'fetch', implying a read-only, non-destructive behavior. It does not disclose response format or edge cases, but the simple nature of the operation and the clear 'fetch' wording provide sufficient transparency for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero filler. It immediately states what the tool does and how, leaving no wasted words. It earns full marks for conciseness and clarity.
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 simplicity (one parameter, no output schema) and the absence of annotations, the description provides all essential information: what it fetches, what it returns (run and delivered rows), and how to identify the run. Nothing critical is missing for a tool of this scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so runId is already documented. The description adds value by specifying that the run_id is the one returned by run_collector, establishing the provenance and correct value source. This extra context meaningfully aids correct invocation beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (fetch), the resource (one Collector run and its delivered rows), and the method (by run_id). This distinguishes it from siblings like crawl_status and run_collector, making its purpose unambiguous without needing to open the schema.
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 the parameter note 'returned by run_collector', signaling this is meant to be called after run_collector to retrieve results. It does not explicitly list alternatives or when-not-to-use scenarios, but for a simple status-like fetch the implicit linkage is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start an asynchronous BFS crawl from a seed URL; each page comes back as Markdown. Returns a job id immediately — poll with crawl_status. $0.0003 per page, unfetched budget refunded. Prefer map + batch when you can filter the URL list first.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Seed URL. | |
| depth | No | Max link depth from the seed, default 3, cap 10. | |
| limit | No | Max pages, default 50, cap 500. | |
| render | No | Render every page with the browser (much slower). | |
| country | No | ISO country code for the proxy exit. | |
| exclude | No | URL substrings to skip. | |
| include | No | URL substrings to include. | |
| contentMode | No | Content scope per page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It discloses async behavior, immediate job id return, per-page cost, budget refund, and output format (Markdown). Does not mention potential side effects like rate limits or data retention, but covers the key operational traits.
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?
Concise single paragraph, front-loaded with action and resource, then key details on costs and alternatives. No fluff, but could be slightly more structured (e.g., separating usage guidance).
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?
Description covers the async nature, job id, cost, and alternative tools. It does not explain parameter semantics, but schema does. No output schema provided; description mentions 'poll with crawl_status' so return behavior is clear. For a complex tool, it's reasonably 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?
Input schema already provides full descriptions for all 8 parameters (100% coverage). The description does not add parameter-specific meaning; it only clarifies the overall outcomeщаться, which is adequate given 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?
Description clearly states it starts an asynchronous BFS crawl from a seed URL, returns Markdown, and explicitly contrasts with map/batch for filtered URL lists, distinguishing it from siblings.
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?
Explicitly advises 'Prefer map + batch when you can filter the URL list first,' and notes the async nature with polling via crawl_status. Clear when-to-use and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll a crawl job: status, pagesCrawled, pagesQueued and the pages fetched so far.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | The id returned by crawl. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the disclosure burden. 'So far' does convey that results may be incremental and that polling may need to be repeated, and it lists the returned progress data. However, it does not describe error cases, status value vocabulary, or how the output evolves between polls.
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 entire description is one dense, front-loaded sentence. It names the action, the resource, and the expected output fields with no filler or repetition.
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-only poll with high schema coverage and no output schema, the description covers purpose and the main return fields adequately. It falls slightly short by not giving exact output field names for the pages fetched or the possible status values, but it is still sufficient for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and jobId is already documented as 'The id returned by crawl', which orients the agent well. The description adds no additional parameter meaning beyond the schema, so the baseline of 3 applies.
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 opens with a specific verb and resource: 'Poll a crawl job', and it names the key monitored fields (status, pagesCrawled, pagesQueued, pages fetched). It is clear, but it does not explicitly differentiate from sibling tools such as collector_run_status.
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 verb 'Poll' implies the tool is used after starting a crawl and to monitor progress, but the description never explicitly states when to use it instead of alternatives, nor does it mention any exclusions or related tools like crawl or collector_run_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the 31 ready-made Collectors: versioned scrapers you run with a semantic input (keyword + location, ASIN, domain, handle…) instead of URLs — web_search, keyword_ideas, amazon_search, amazon_product, ebay_search, aliexpress_search, google_maps_places, place_reviews, google_jobs, linkedin_jobs, indeed_jobs, google_news, google_shopping, product_offers, hotels, youtube_search, youtube_channel, reddit_posts, instagram_profile, tiktok_profile, tiktok_video, zillow_search, app_store_apps, google_play_apps, linkedin_profile, linkedin_company, company_profile, site_contacts, local_business_leads, search_images, search_videos. Each entry carries its input and output schema, examples, health and your price per delivered row. Free to call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since there are no annotations, the description carries the full burden. It discloses that the tool is free ('Free to call'), and it details what each entry contains (input/output schema, examples, health, price). It does not mention rate limits, caching, or that it's a read-only operation, but for a listing tool these are minor. The description goes beyond a simple 'list' by explaining the structure of the response.
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 somewhat long because it enumerates all 31 Collectors, but that list is arguably useful for an agent to know the available options upfront. The first sentence states the purpose, followed by a definition and the list. Each sentence adds value. It's not overly verbose given the need to identify the Collectors.
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 parameterless listing tool with no output schema, the description is complete. It tells the agent what the response will contain (schema, examples, health, price) and that it's free. There are no missing pieces an agent needs to know before calling it, given its 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?
The tool takes no parameters, and the input schema is empty. The description doesn't need to explain parameter meaning. The baseline for zero parameters is 4, and the description adds context about what the tool returns, which is beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact purpose: listing 31 ready-made Collectors. It clearly differentiates them from the sibling tools (run_collector, collector_run_status) by describing what a Collector is and that this tool only lists them, not runs them. The verb 'List' and the resource 'Collectors' are specific and unambiguous.
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?
While it's evident that this tool is meant to be called before running a Collector (given the siblings run_collector and collector_run_status), the description does not explicitly state 'use this to see available Collectors before running one' or contrast it with alternatives. It only implies usage by listing capabilities. No explicit guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover every URL of a site in one call: robots.txt sitemaps + /sitemap.xml (including nested indexes) + same-domain homepage links, de-duplicated. Returns the list plus a site-wide total and a per-section summary. Always cheaper than crawling to find out how big a site is. $0.0005.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Seed URL. | |
| limit | No | Max URLs returned, default 100, cap 5000. Discovery always scans the whole site. | |
| search | No | Only return URLs containing this substring. | |
| country | No | ISO country code for the proxy exit. | |
| group_by | No | Set to "path" for the path tree with counts instead of the URL list. | |
| includeSubdomains | No | Include URLs on subdomains of the seed host. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and discloses the data sources, deduplication, output contents (list, total, per-section summary), and pricing. It does not mention error behavior or rate limits, but for a read-only discovery call these are minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences front-load the core behavior, then return shape, cost comparison, and price. No filler or redundant restatement of the schema.
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?
Despite having no output schema or annotations, the description covers sources, deduplication behavior, return contents, pricing, and the main use case, while the schema covers params. This is enough for an agent to select and invoke the tool correctly.
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 all six parameters are already documented in the input schema. The description adds output context but no new parameter-level semantics, which meets the high-coverage baseline 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 opening 'Discover every URL of a site in one call' names the action and resource, and the following colon specifies the exact discovery sources (robots.txt sitemaps, /sitemap.xml, nested indexes, same-domain homepage links). This clearly distinguishes map from siblings like crawl and search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Always cheaper than crawling to find out how big a site is' gives a concrete use case and names crawl as the alternative. It does not explicitly address when to prefer search or seo_audit, but the context makes the primary selection criterion clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one Collector with its semantic input. Short runs return the rows directly; long runs return a run_id to poll with collector_run_status. Billed per delivered row — zero rows costs zero.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Collector slug, e.g. google_maps_places. Call list_collectors first if unsure. | |
| async | No | Force background processing and return a run_id immediately. | |
| input | Yes | The collector's input, matching its published input_schema. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses billing per delivered row (zero rows cost zero), and the sync/async behavior with run_id. It doesn't mention error handling or rate limits, but the key behaviors are covered. No contradiction with annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earns its place: the core action, the sync/async distinction, and the billing model. Front-loaded with the key action and then important behavior. 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 output schema and 100% param schema coverage, the description covers the essential behaviors: sync vs async, billing, and how to poll. It could mention error conditions or rate limits, but for a run tool it's reasonably complete. The sibling list_collectors is hinted for slug discovery.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents the parameters well. The description adds meaning for the 'async' parameter (force background processing), and explains the input is semantic and matches the collector's published input_schema. It provides value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states clearly it runs a Collector with its semantic input, and distinguishes the sync vs async behavior. It also names the sibling collector_run_status for polling, which helps differentiate from other tools.
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 gives context on when to use synchronous vs asynchronous (short vs long runs), and implicitly suggests using list_collectors first if unsure about the slug. It doesn't explicitly say when not to use this tool or mention alternatives beyond the polling tool, so a slight gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one URL and return it as Markdown (default), HTML or plain text, through residential proxies with real-browser TLS fingerprints. Set render:true only when the content is genuinely absent from the raw HTML. Use extract for CSS-selector JSON, or ai_prompt to have the page turned into structured data by an LLM. $0.0002 per page; a failed fetch is free.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page to fetch (http/https). | |
| mode | No | summary returns metadata only, no page content. | |
| format | No | Output format. | markdown |
| render | No | Run a stealth headless browser (JS execution). Slower and pricier. | |
| country | No | ISO 3166-1 alpha-2 code for the proxy exit, e.g. us, de, jp. | |
| extract | No | CSS extraction schema, e.g. {"price": ".price", "title": "h1"}. Returns payload.data. | |
| ai_prompt | No | Natural-language extraction instruction; result lands in payload.ai.data. | |
| contentMode | No | How much of the page to keep. | smart |
| waitForSelector | No | Render mode: wait until this CSS selector appears. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that fetches go through residential proxies with real-browser TLS fingerprints (implying anti-blocking), the cost per page ($0.0002), and that failed fetches are free. This goes beyond obvious behavior, though it doesn't mention rate limits, auth, or detailed error handling. Still, it provides meaningful 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?
Three sentences with zero wasted words. The main purpose is front-loaded; then usage guidance, alternatives, and cost are presented logically. The pricing note is a useful addition without bloat.
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?
Despite 9 parameters and no output schema, the description covers the critical decision points (render, extract, ai_prompt, cost) enough for an agent to call correctly. Some parameters (country, contentMode, waitForSelector) are not elaborated, but they are well-described in the schema with 100% coverage. The description adds sufficient contextual guidance for a complex 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 coverage is 100%, so baseline is 3. The description adds value by explaining when to set render (only if absent from raw HTML), and how extract and ai_prompt are used for structured data. It also clarifies that summary mode returns metadata only via schema description. This enriches the schema's parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool fetches a single URL and returns it as Markdown, HTML, or plain text. This is a specific verb+resource, and it implicitly distinguishes from siblings like crawl (which implies multiple pages) by saying 'one URL'. The mention of extract and ai_prompt for structured data further clarifies the tool's scope.
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?
Provides concrete guidance for when to use render (only if content absent from raw HTML) and when to use extract/ai_prompt for structured data. However, it does not explicitly contrast with sibling tools (e.g., crawl for multi-page) or state when not to use this tool. The guidance is clear for parameter usage but not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Structured search results from Google, Bing, DuckDuckGo or Yandex: organic rows with position, title, link, snippet and sitelinks, plus related searches and any local/news/shopping blocks the page carried. Eighteen verticals via search_type. From $0.0005 per search.
| Name | Required | Description | Default |
|---|---|---|---|
| num | No | Results to request, 1-100. Default 10. | |
| lang | No | Interface language (hl), e.g. en, it. | |
| page | No | Result page, 1-based. | |
| query | Yes | The search query. | |
| engine | No | Search engine. | |
| country | No | ISO country code — sets the proxy exit and the engine locale (gl). | |
| location | No | Search as if from this place, e.g. "Milan, Italy". Google only. | |
| search_type | No | Vertical. | search |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the burden of explaining behavior, and it does a solid job: it discloses the response shape, the engines covered, the verticals, and the relevant pricing. It does not mention rate limits, caching, or failure modes, which is a gap, but there is no contradiction and the core operational behavior is clearly stated.
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 deliver a large amount of information without filler. The first sentence front-loads the tool's purpose and response contents; the second adds the full vertical count and per-search cost. Every clause earns its place.
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 full parameter schema and the absence of an output schema, the description covers the most important return values and the wide range of verticals well. The main missing element is selection guidance relative to sibling tools, but the information needed to actually invoke the tool is either in the schema or in the description.
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 already covers 100% of the parameters with helpful descriptions, so the baseline is met. The description only adds the high-level note that there are eighteen verticals and that search spans Google, Bing, DuckDuckGo, or Yandex, which is already visible in the schema. It adds no deeper parameter-specific detail.
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 defines a search-engine resource and the exact output format: organic rows with position, title, link, snippet, and sitelinks, plus related searches and local/news/shopping blocks. It is distinct in substance from scraping or crawling, but it does not explicitly name sibling tools or show selection boundaries, so it stops short of perfect.
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?
There is no guidance about when to prefer this tool over scrape, map, crawl, or the other siblings. The description says it offers web search results and verticals, but it does not specify alternatives, exclusions, or conditions that would drive an agent toward another tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a URL twice — as a no-JS bot and fully rendered — and return both views, the diff between them (contentOnlyInJs, canonicalMissingNoJs, titleChanged…) and the bot-facing meta (robots, OG, JSON-LD types). The fastest way to answer 'is this page indexable without JavaScript'. $0.0012.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page to audit. | |
| country | No | ISO country code for the proxy exit. | |
| no_render | No | Skip the rendered pass — cheaper, bot view only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It describes the dual fetch behavior, the returned diff types, the meta extraction, and even the cost per call. It does not explicitly state whether the operation is read-only, but the language (fetch, return) implies a safe audit. The level of detail about internal mechanics is strong for a tool of this type.
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 compact—two sentences—and every element earns its place: the action, the outputs, example diff types, the use case, and the cost. It front-loads the core behavior and then answers 'why use this' with a clear value proposition. There is no filler or redundant phrasing.
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 there is no output schema, the description does a good job of indicating what will be returned (both views, diff items, meta types). It names specific diff categories, making the output shape imaginable. However, it does not detail the structure of the returned views/meta or explain each diff type, which leaves some ambiguity for an agent attempting precise invocation. Still, for a tool with three simple parameters and a clear output sketch, it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all three parameters (url, country, no_render) already have descriptions. The tool description adds minimal parameter-level detail beyond the schema—it mentions the rendered vs no-JS contrast, which implicitly relates to no_render, but does not elaborate on country or additional constraints. Per the rubric, baseline 3 is appropriate given 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 states a specific verb (fetch), the resource (URL twice, bot vs rendered), and the resulting outputs (views, diff, meta). It also names concrete diff types, making the tool's purpose unmistakable. This clearly distinguishes it from siblings like scrape or crawl, which focus on general data extraction rather than SEO indexability analysis.
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 frames the tool as 'The fastest way to answer is this page indexable without JavaScript', giving a clear target scenario. However, it does not explicitly state when not to use this tool or mention alternative siblings, so it stops short of full exclusionary guidance. The context is clear enough for an agent to select it over other tools in many situations.
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.
v1.0.0collector_run_statuscrawlcrawl_statuslist_collectorsmaprun_collectorscrapesearchseo_auditScored across 9 tools
Each tool targets a distinct job: single fetch, search, site discovery, crawl, crawl status, SEO audit, and collector management. Minor ambiguity exists between the `search` tool and the `web_search` collector, and between `scrape` and `seo_audit`, but the descriptions provide enough context to choose correctly.
Bare imperative verbs (`scrape`, `search`, `map`, `crawl`) sit alongside verb-noun names (`run_collector`, `list_collectors`) and noun-phrase status names (`crawl_status`, `collector_run_status`, `seo_audit`). The names are readable, but the pattern is not consistent enough to predict how a new tool would be named.
Nine tools is a well-scoped size for a data-acquisition server covering scraping, search, crawling, SEO auditing, and collector workflows. Each tool earns its place without overwhelming an agent.
The server covers scraping, search, URL discovery, crawling with status polling, SEO auditing, and collector execution/status, forming complete data-fetch workflows. Minor gaps include a referenced batch mode that is not exposed as a tool and no cancellation/list-jobs capability, but these can be worked around.
Web data for agents: YouTube transcripts, screenshots, Google News, WHOIS, jobs, tech stack, more.
Direct access to 60+ scraping and search tools. Extract structured data from Google (Search, Maps, Trends), Amazon, Airbnb, Social Media, and any web page directly into your AI agent.
Web search, browser automation, scraping, crawling and CAPTCHA solving for AI agents.
Agent-native search engine with live web research optimized for AI agents.