Arachne MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool serves a distinct purpose in the web scraping pipeline, from health checks to link extraction, crawling, parsing, site mapping, robots inspection, browser interaction, batch scraping, search, structured extraction, diffing, and chunking. No two tools have overlapping functionality.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., extract_links, crawl_url, parse_url). The only exception is 'health', which is a noun but serves as a status probe and fits the convention of a single-word command.
Tool Count5/5
13 tools is appropriate for a comprehensive web scraping and content extraction server. Each tool covers a necessary operation without redundancy, balancing breadth and focus.
Completeness5/5
The tool surface covers the full lifecycle of web data acquisition: discovery (map_site, search_web), fetching (crawl_url, crawl_site, batch_scrape), parsing (parse_url, extract_links), interaction (browser_interact), compliance (check_robots), processing (chunk_content, extract_structured), and monitoring (health, crawl_diff). No obvious gaps.
Average 3.1/5 across 13 of 13 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It only states the method (recursive sitemaps + shallow crawling) without mentioning effects like read-only behavior, rate limits, or robots.txt compliance. This is insufficient for safe invocation.
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?
The description is a single concise sentence with no fluff. It is front-loaded with the core purpose. However, it could be expanded slightly to improve completeness without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no annotations, and an existing output schema, the description is severely incomplete. It omits return value information, parameter behaviors, and handling of edge cases (e.g., exclude/include patterns). The agent lacks context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for 7 parameters. The description does not explain any parameter (e.g., start_url, max_urls, crawl_pages). It fails to compensate for the lack of schema documentation, leaving the agent without parameter insight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Discover site URLs from recursive sitemaps plus optional shallow crawling' clearly states the verb, resource, and method. It distinguishes from siblings like crawl_site by mentioning sitemap discovery, but could be more explicit about the contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., crawl_site, extract_links). There are no prerequisites, exclusions, or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It mentions 'optional OpenAI-compatible LLM' but does not disclose potential side effects (e.g., API calls, cost, rate limits) or whether the tool is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is too brief; it fails to include important details about parameters, behavior, or output. It is under-specified rather than concise, given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and 5 parameters, the description is inadequate. It does not mention return format, rendering choices, or LLM behavior, making it incomplete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain any of the 5 parameters (url, schema, instruction, render_mode, max_source_chars), leaving agents without guidance on required or optional fields.
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?
The description clearly states the tool extracts JSON matching a caller-supplied schema, optionally using an LLM. This distinguishes it from siblings like extract_links (extracts links) or crawl_url (crawls).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over siblings (e.g., when to use render_mode choices or when LLM is needed). The description only mentions optional LLM but no when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions relying on a configured provider. It fails to disclose behavioral traits like rate limits, authentication needs, fallback behavior, or whether results are cached.
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?
The description is a single, well-front-loaded sentence. While concise, it could incorporate more useful information without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no schema descriptions, no annotations, and an output schema not described), the description is insufficient. It does not explain the effect of scrape_results or max_chars_per_result, nor the structure of search results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no parameter details. The tool has 4 parameters (limit, query, scrape_results, max_chars_per_result) with no explanations, leaving the AI unable to understand their purpose or valid ranges.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches through a configured self-hosted SearXNG or Brave Search provider, distinguishing it from sibling tools like crawl_url or extract_links which perform different operations. However, it could be more specific about the type of search (e.g., general web search) and result format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as crawl_site or map_site. The description lacks any context about prerequisite configurations or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behaviors. It does not mention caching behavior, rate limits, supported document types, or what happens with HTML pages despite saying 'non-HTML resource'. The description is vague about the parsing mechanism.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks structure and fails to provide important details. Every sentence should earn its place; here the single sentence is insufficient for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters, no annotation coverage, and an output schema not detailed. The description is too brief to be complete, omitting caching, character limits, and parsing scope. Given the complexity, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation for parameters. 'max_chars' and 'use_cache' are not described beyond their names, leaving the agent to guess their meaning and defaults.
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?
The description uses a specific verb 'Parse' and specifies the resource types ('remote document or non-HTML resource') and output format ('LLM-ready text/Markdown'). It clearly distinguishes from sibling tools like 'search_web' or 'extract_links' which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'extract_structured' or 'browser_interact'. There are no explicit conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like read-only nature or rate limits. It only lists what is inspected but does not describe how the tool behaves (e.g., whether it fetches the file, caches results, or requires authentication).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's function without extraneous words. It is front-loaded with the key verb 'Inspect' and lists the items inspected.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown), but the description does not hint at the output structure. Given the complexity of inspecting multiple items, the description should provide some context about the return format or what constitutes successful retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'url' parameter beyond its name. It fails to specify expected format (e.g., full URL with protocol), or that it should point to the root domain's robots.txt.
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?
The description clearly states the tool's purpose: inspecting robots.txt permissions, crawl delay, request rate, and sitemap declarations. It distinguishes it from sibling tools like 'crawl_url' or 'extract_links' by focusing on robots.txt analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not specify that it should be used before crawling to check permissions, nor does it mention any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 JS rendering support but omits details like side effects (none expected), authentication requirements, rate limits, or what 'normalized' means. The transparency is adequate but not thorough.
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?
Single sentence that is direct and front-loaded with the core action. While concise, it sacrifices useful detail. A slightly longer description could improve clarity without significant bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (implied) and several parameters, the description is minimal. It does not explain the output format, the normalization process, or how parameters affect behavior. The tool's complexity is higher than the description suggests.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (only titles provided). The description does not elaborate on any parameter meanings, defaults, or constraints. For a tool with 5 parameters and low coverage, the description should compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool extracts normalized crawlable links from static or JS-rendered pages. It specifies the action (extract) and resource (links), and hints at an ability to handle JS rendering. However, it does not explicitly distinguish it from sibling tools like crawl_url or parse_url, which may also extract links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., crawl_url for full crawling, parse_url for URL parsing). The description lacks any when-not-to-use or prerequisite information, leaving the agent without decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: strict request/error/token budgets and per-host rate limiting. However, with no annotations, the description carries the full burden, and it fails to mention important behaviors like conforming to robots.txt, handling authentication, or how budgets are enforced. Additional context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence, 10 words), which is efficient but underserves a tool with 17 parameters. It front-loads the core action and constraints but lacks the depth that multiple sentences could provide for key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (17 parameters, 1 required, no schema descriptions, no annotations) and the presence of an output schema (not shown), the description is far from complete. It does not explain return values, effects of parameters, or error scenarios, leaving the agent to guess many operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it only mentions budgets and rate limiting, which are not explicit parameter names. None of the 17 parameters (e.g., max_pages, delay_ms, include_pattern) are described or linked to the narrative, leaving the agent to infer from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Crawl a site') and adds context about budgets and rate limiting. It implies differentiation from sibling tools like 'crawl_url' which likely handles single URLs, but does not explicitly call out alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage for controlled crawling with budgets, but no explicit guidance on when to use this tool versus alternatives (e.g., 'crawl_url' for single pages, 'map_site' for structure). No exclusions or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits but fails to mention side effects like snapshot creation or update behavior, or what happens if no snapshot exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no extraneous words; highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and no annotations, the description omits critical context about snapshot management, diff interpretation, and the update_snapshot behavior, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds no parameter explanations beyond what parameter names imply. Does not compensate for the lack of schema descriptions.
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?
The description clearly states the tool compares a page with its previous persistent snapshot and returns a unified diff, which is specific and distinguishes it from sibling tools like crawl_url or crawl_site.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; lacks context about prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that content is marked untrusted and scanned for prompt-injection, and lists supported formats. However, no annotations provided, and description fails to mention important behaviors like redirect handling, timeouts, error responses, or mutation. With zero annotation coverage, the description should be more thorough.
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?
Description is very concise (3 short lines), front-loads purpose. However, it omits parameter details, which would be necessary for completeness. Appropriate length but at expense of utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 13 parameters and an output schema, the description is too brief. It doesn't explain caching, output format options, or parameter behaviors. Even with output schema existing, agent needs more context to set parameters correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate but does not explain individual parameters. Only 'automatic escalation' relates to render_mode; other 12 parameters are not described. The schema properties' names provide some hint, but description adds little meaning.
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?
Description clearly states action (fetch and extract), resource (one URL), and methods (HTTP, browser, auto). Distinguishes from siblings like crawl_site and extract_links by specifying single URL extraction and supported formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs siblings. Although 'one URL' implies single page extraction, no mention of when to prefer this over extract_links, parse_url, or browser_interact.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the lack of annotations, the description discloses behavioral traits: 'stable' (implying deterministic, idempotent), 'overlapping' (chunks have shared context), and 'hash-addressed' (content-based addressing). However, it does not explain stability guarantees or the hashing scheme in detail.
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?
The description is a single sentence with no wasted words. It is concise, but it lacks structural elements like bullet points or an example that could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fails to explain the output (despite existence of an output schema) and does not cover parameter semantics. For a tool with four parameters and no annotation support, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for parameters, and the tool description does not mention any parameter meaning, defaults, or usage. All four parameters (content, overlap, chunk_size, max_chunks) are left unexplained, leaving the agent with insufficient information.
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?
The description clearly states the verb 'split', the resource 'long content', and the key characteristics 'stable, overlapping, hash-addressed'. It also specifies the intended use case 'for RAG or agents', distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for splitting content for retrieval contexts, but it does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. The intended context (RAG/agents) is helpful but not sufficient for clear decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. It mentions concurrency and output budget but lacks details on error handling, rate limits, partial results, or other behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with essential info, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and complexity of batch scraping, the description is too brief. It does not cover return format, error behavior, or parameter details, leaving gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate by explaining key parameters. It only hints at max_total_chars via 'shared output budget', ignoring concurrency, render_mode, include_links, etc.
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?
Description clearly states the tool scrapes up to 500 URLs concurrently with a shared output budget, distinguishing it from single-URL scraping or extraction tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies batch usage but does not explicitly state when to use this tool over alternatives like crawl_url or extract_links, nor does it specify 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: JavaScript eval is disabled by default, and the tool does not bypass CAPTCHA, authentication, paywalls, or access controls. However, it does not mention session handling, potential state changes, or output format implications.
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?
The description is concise (3 sentences) and front-loaded with the main purpose. The second and third sentences add important caveats. Could be slightly more structured, but it is efficient without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, nested actions) and existing output schema, the description covers core purpose and a couple of limitations but omits behavior details like session persistence, output format handling, and action sequence execution rules.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, but it only briefly mentions actions and does not explain most parameters (e.g., session_id, persist_session, output_format). The agent gets minimal help understanding parameter semantics beyond their names.
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?
The description clearly states the tool's purpose: 'Operate a browser using safe declarative actions' and lists specific actions (click, fill, press, etc.). It differentiates from siblings like crawl_url and extract_links by focusing on interactive browser operations rather than extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for interactive browser tasks (clicking, filling forms) but lacks explicit guidance on when to use this tool versus sibling extraction tools such as crawl_url or extract_structured. No 'use this for... not for...' wording is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It accurately describes a read-only operation returning system status. Although it doesn't explicitly state non-destructive behavior, the context strongly implies it, and no contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's output. It is front-loaded, concise, and contains no filler. Every word earns its place.
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?
Given no parameters, the presence of an output schema, and clear differentiation from siblings, the description is fully complete. It provides all necessary context for an agent to correctly invoke and interpret the tool.
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?
The tool has zero parameters, and schema coverage is 100%. The description does not need to add parameter details beyond the schema, as none exist. A baseline of 4 is appropriate since the description contributes no extra semantic value but is not required.
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?
The description explicitly states the tool returns 'enabled engines, integrations, security policy, and parser availability', providing a clear and specific verb-resource combination. It distinguishes itself from sibling tools like crawl_url or search_web, which focus on different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for checking system health but offers no explicit guidance on when to use this tool versus alternatives. Since siblings are functionally distinct, the context is clear, but there is no direct exclusion criteria or usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![crawl-mcp MCP server](https://glama.ai/mcp/servers/Rizky742/crawl-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Rizky742/crawl-mcp)

Score Badge

Copy to your README.md:

[![crawl-mcp MCP server](https://glama.ai/mcp/servers/Rizky742/crawl-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Rizky742/crawl-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Rizky742/crawl-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server