servo-fetch

by konippi

Overview Schema Related Servers Score Discussions

Rust

Hybrid

Server Quality Checklist

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

Latest release: v0.13.1
Disambiguation5/5
Each tool has a distinct purpose: fetch single pages, batch_fetch multiple URLs, crawl recursively, map discovers URLs via sitemaps, execute_js runs JavaScript, and screenshot captures images. No significant overlap.
Naming Consistency5/5
All tool names use lowercase with underscores, following a clear verb-based pattern (e.g., fetch, crawl, map, batch_fetch, execute_js). The naming is consistent and predictable.
Tool Count5/5
With 6 tools, the server is well-scoped for its purpose of web fetching, crawling, and rendering. Each tool adds distinct functionality without unnecessary redundancy.
Completeness4/5
The tool set covers core workflows: single and batch fetching, crawling, URL discovery, JavaScript execution, and screenshots. Minor gaps like cookie or header management exist, but the server's stated purpose is well-served.
Average 4.3/5 across 6 of 6 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 12 of 12 community issues answered or closed in the last 6 months
- 139 commits in the last 12 weeks
- Last stable release on August 10, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only, not destructive, and has open-world hints. The description adds that console messages are appended to the result, but fails to disclose that arbitrary JS execution can modify the page, trigger network requests, or cause other side effects. This is a notable omission for a code execution tool.
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 with a single sentence followed by examples. Every word is purposeful, though a bit more structure (e.g., separating purpose and outcomes) could improve clarity.
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 no output schema, the description should fully specify the return value format. It mentions console messages appended but does not clarify whether the expression's result is included or how different data types are serialized. This leaves ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are described in the schema (100% coverage), so the description adds limited value beyond examples for the 'expression' parameter. It does not clarify formats or constraints beyond what the schema provides.
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 verb 'evaluate' and the resource 'JavaScript expression in a loaded page', clearly distinguishing it from sibling tools like fetch (which retrieves raw HTML) and screenshot (which captures visuals). The examples further solidify its purpose.
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 extracting dynamic content (via examples) but does not explicitly state when to use this tool over alternatives like fetch or crawl, nor does it mention when not to use it (e.g., for static content).
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?
Annotations already provide readOnly, destructive, idempotent, and open-world hints. The description adds context about the software renderer and full_page behavior, but does not detail error handling or output format. This is adequate given the annotations.
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?
Two sentences, front-loaded with the main purpose. Every word adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not specify the return format (e.g., base64-encoded PNG). However, the tool name and basic purpose are clear, and annotations cover safety. Minor gap in output specification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. The description only mentions full_page explicitly, adding no additional meaning beyond what's in the schema for other parameters like timeout or settle_ms.
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 captures a PNG screenshot of a web page, using a specific verb and resource. It distinguishes itself from siblings like fetch or execute_js by focusing on visual capture.
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?
The description mentions the use of Servo's software renderer (no GPU required), hinting at suitable environments. It also explains the full_page parameter usage, but lacks explicit guidance on when to use screenshot over alternatives like batch_fetch or crawl.
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?
Annotations already declare read-only and idempotent behavior. The description adds valuable behavioral details: parallel execution, completion order, and inline failure reporting. It does not contradict annotations. Could mention network dependency or rate limits, but overall good.
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?
Two sentences, front-loaded with purpose, no redundancy. Every sentence adds value. Extremely concise and well-structured.
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?
Despite no output schema, the description clearly explains the result format (separate entries, completion order, inline failures) and error behavior. It covers key behavioral aspects, making it complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add additional parameter semantics beyond what the schema already provides (e.g., max 20 URLs, default formats). No extra value from description for parameters.
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: 'Fetch multiple URLs in parallel and extract readable content.' It specifies the verb (fetch), resource (multiple URLs), and action (extract content), and distinguishes from sibling tools like fetch (single URL) and crawl (recursive).
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?
The description implies usage for fetching multiple URLs in parallel and describes result ordering and error behavior. However, it does not explicitly state when to use this tool versus alternatives (e.g., single fetch for one URL, crawl for recursive exploration), which would improve guidance.
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?
Annotations indicate readOnlyHint, idempotentHint, etc. The description adds context: the tool does not render pages, is lightweight, respects robots.txt, and discovered URLs are untrusted. This provides useful behavioral details beyond the annotations.
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 three concise sentences, each adding value: first states the action, second clarifies non-rendering nature, third provides usage guidance. No redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity with 4 parameters and no output schema, the description adequately explains the tool's purpose, behavior, and usage. It mentions the return type (list of URLs) and constraints. Minor gap: the output format could be more explicit, but overall complete.
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 100%, so parameters are well-described in the schema. The description adds overall context about the discovery mechanism (sitemaps and link extraction), which helps interpret parameters like include_glob/exclude_glob. However, it doesn't add parameter-specific details beyond the schema.
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 'Discover all URLs on a website via sitemaps and link extraction' with a specific verb and resource. It distinguishes the tool from siblings by explicitly noting 'Does NOT render pages' and positioning it as a precursor to crawl or selective fetch.
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?
The description explicitly advises when to use: 'Use before crawl to understand site structure, or to build a URL list for selective fetching.' It also notes constraints like respecting robots.txt and that discovered URLs are untrusted, but does not explicitly state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond annotations: uses Servo browser with JS/CSS, strips navbars/sidebars/footers automatically, truncates content, paginates, and provides accessibility tree. These details are not in annotations (readOnlyHint, idempotentHint, etc.) and significantly aid agent understanding.
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 concise (4 sentences) and front-loaded with the main purpose. Each sentence adds distinct value: engine details, automatic stripping, optional selector, format options, pagination. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description covers core functionality, parameter usage, and behavioral traits well. It lacks explicit error handling or rate limit info, but annotations provide safety signals. Overall, it is sufficient for effective tool use.
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?
All 7 parameters have schema descriptions, so baseline is 3. However, the tool description adds value by explaining the purpose of key parameters (selector for specific extraction, settle_ms for SPA hydration, start_index for pagination) beyond the base schema.
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 fetches a URL and extracts readable content using the Servo browser engine. It distinguishes from siblings like screenshot or execute_js by specifying its unique features (JS execution, CSS layout, readability extraction). The mention of selector, format, and pagination adds specificity.
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?
The description gives clear guidance on when to use optional parameters (selector for specific sections, format for accessibility_tree, start_index for pagination). It does not explicitly contrast with siblings, but the context implies when alternatives are better (e.g., screenshot for visual, crawl for multiple URLs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, non-destructive. Description adds context about JS execution, CSS layout, noise stripping, robots.txt respect, and warns that crawled content is untrusted. No contradiction.
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 well-structured: first sentence main action, second sentence details, then guidelines, limits, performance note, trust warning. Every sentence 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 10 parameters, full schema coverage, behavioral annotations, and no output schema, the description covers the crawling process, limits, and output format via parameter, making it complete for agent decision-making.
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 100%, so baseline 3. Description adds value by clarifying defaults and limits for limit and max_depth parameters, and explaining the overall behavior for other parameters.
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 it crawls a website starting from a URL, following same-site links via BFS, and extracts readable content. It explicitly distinguishes from sibling tools like fetch for single pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use (multiple pages of documentation, blog, knowledge base) and when-not-to-use (single page, cross-site). It also mentions limits (max 500 pages, max depth 10).
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:

[![servo-fetch MCP server](https://glama.ai/mcp/servers/konippi/servo-fetch/badges/card.svg)](https://glama.ai/mcp/servers/konippi/servo-fetch)

Score Badge

Copy to your README.md:

[![servo-fetch MCP server](https://glama.ai/mcp/servers/konippi/servo-fetch/badges/score.svg)](https://glama.ai/mcp/servers/konippi/servo-fetch)

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/konippi/servo-fetch'

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