Skip to main content
Glama
Sign In
Unilytics MCP Server

Unilytics MCP Server

Official
by TeamUnilytics
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

batch_scrape

Read-only

Scrape up to 10 URLs in parallel and return structured page data—headings, markdown, status codes—for competitor analysis, SERP comparisons, and content gap research.

Instructions

Scrape multiple URLs in a single call (up to 10 URLs).

Firecrawl processes all URLs in parallel — much faster than scraping one
by one. Use for competitor analysis, content gap analysis, SERP page
comparisons, link prospecting, or any task requiring data from multiple pages.

Returns one entry in `pages` per requested URL, in the order you sent them. Each has
`url` (as requested), `final_url` (only if it redirected), `status_code`, and `error`
when the page failed (4xx/5xx, DNS failure, timeout, blocked); a failed URL is never
dropped. Successful pages also carry title, description, h1–h3 headings and markdown
`content`. Content is capped at 15,000 characters per page, and lower when many long pages
share one reply (`content_cap_chars` is the cap used): `truncated` says whether a page was
cut, `original_chars` is its full length and `word_count` counts the whole page; content_scrape
returns one page in full.
URLs beyond the first 10 are not scraped and come back in `urls_not_scraped`; a URL sent
twice is scraped once and listed in `duplicate_urls_ignored`. Every URL must start with
http:// or https:// (one that doesn't gets an `error` page; the others still run).

Args:
    urls: List of URLs to scrape (max 10)
    js_rendering: Wait for JavaScript rendering on each page (default: False)

[Provider: Firecrawl]

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "urls": "<urls>"
    },
    "name": "batch_scrape"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlsYes
js_renderingNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.0
    • removedInput schema / properties / config
      Removed value: -{
-  "default": null,
-  "title": "config",
-  "type": "string"
-}
  2. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, non-destructive, open-world), and the description adds substantial operational detail on top: parallel processing, per-URL failure entries that are never dropped, the 15,000-char content cap and its shrinking under load, truncation flags, and the 10-URL ceiling. It also discloses edge-case handling for >10 URLs, duplicates, and non-http(s) schemes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with capability and limit, then parallel-processing rationale, then return contract, then Args. Dense and mostly fact-bearing, though the middle 'Use for competitor analysis, content gap analysis…' list is somewhat generic and could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only two parameters and no output schema, the description fully specifies the return shape (pages array in request order, url/final_url/status_code/error, content fields, content_cap_chars, truncated, original_chars, word_count, urls_not_scraped, duplicate_urls_ignored). An agent can both call and interpret the result correctly from the text alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries the parameter burden, and it does: urls is bounded at 10, must start with http:// or https://, and duplicates are deduped; js_rendering is explained as waiting for JavaScript rendering per page. It could still say more about cost/latency implications of enabling js_rendering.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb, resource and hard limit: 'Scrape multiple URLs in a single call (up to 10 URLs)'. It also explicitly contrasts itself with content_scrape ('returns one page in full'), so an agent can distinguish it from the closest sibling without reading either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete triggering scenarios (competitor analysis, content gap analysis, SERP comparisons, link prospecting) and routes single-page full-content needs to content_scrape. It stops short of explicit exclusions, e.g. when to prefer js_scrape over setting js_rendering here.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools