webfetch

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: downloading, license checking, reverse image search, page probing, and three specialized search tools (general, album art, artist). No ambiguity between them.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with underscores (e.g., download_image, search_images). No mixing of conventions.
Tool Count5/5
Seven tools cover the domain of image fetching and license checking without being excessive. Each tool earns its place, and the count is appropriate for the server's purpose.
Completeness4/5
The set covers core workflows (search, download, license check, find similar, probe page). Minor gaps exist like a generic URL fetcher for non-image content, but the server's focus on images makes this acceptable.
Average 4.2/5 across 7 of 7 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 49 commits in the last 12 weeks
- Last stable release on May 10, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.
This repository includes a glama.json configuration file.
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?
No annotations are provided, so the description carries full burden. It explains the behavioral differences based on the 'kind' parameter (provider sets and query expansion). However, it does not disclose any other behavioral traits such as read-only nature, pagination, or rate limits.
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 few sentences, front-loaded with the purpose. It could be more structured, but it is not overly long and gets to the point.
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 lack of output schema and missing parameter descriptions, the description should be more comprehensive. It only covers the 'kind' parameter and one usage scenario, leaving many parameters and the return format unexplained.
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. It only explains the 'kind' parameter in detail; the other 8 parameters (like safeSearch, licensePolicy, maxPerProvider, etc.) are not described at all. This adds minimal value 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 it is a specialized image search for a musical artist, and explicitly distinguishes this tool from sibling search_images by saying 'Prefer this over search_images when building artist/band content.' It also explains the purpose of the 'kind' parameter with specific provider sets.
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 explicit guidance on when to use this tool over search_images for artist/band content. However, it does not mention when not to use it or provide alternatives for other contexts, and lacks details about other sibling tools like search_album_cover.
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?
Discloses that results are editorial-licensed and safe per ToS, which is key behavioral info. No annotations provided, so description covers safety. Could add more on failure modes or rate limits.
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?
Two sentences, efficient and front-loaded. However, lacks structure or parameter hints. No wasted words, but could be slightly more informative.
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?
With 9 parameters and no output schema, description is incomplete. It doesn't explain return format or behavior for missing results. Adequate for a simple search but not comprehensive.
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%; description does not mention any parameters despite there being 9, including required ones. Schema is detailed, but description fails to add meaning beyond it.
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 uses specific verb 'Find' and resource 'canonical album artwork', clearly distinguishing from sibling tools like search_images and search_artist_images. Mentions specific data sources (MusicBrainz, iTunes, Spotify) and licensing.
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?
States use case 'album identification UI' and attribution requirement. Implicitly differentiates from siblings but lacks explicit when-to-use vs alternatives. Clear context provided.
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?
No annotations provided, so description carries the burden. It adds 'Returns candidates with heuristic licenses — treat results as leads, not shippable,' disclosing the heuristic nature and appropriate usage, which is valuable behavioral context beyond basic purpose.
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?
Three sentences with no redundancies: purpose, prerequisite, output disclaimer. Each sentence serves a distinct, essential function.
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 no output schema and no annotations, the description covers purpose, a key prerequisite, and output quality. It does not address error cases or rate limits, but the tool is low-complexity with 2 params.
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 coverage is 50% (url has description, providers does not). Description adds 'Requires ... providers: ["serpapi"]', indicating the required provider and hinting at the role of the providers parameter. However, it does not explain individual enum options, which the schema already lists.
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 'Reverse-image-search: given a public image URL, find visually similar images.' This is a specific verb+resource combo, and it distinguishes from sibling tools like download_image or search_images.
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?
Description mentions requirement 'Requires SERPAPI_KEY env var and providers: ["serpapi"]', giving clear context for when to use. It does not explicitly exclude alternatives, but the prerequisite is helpful.
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?
Discloses search behavior (federated, license-aware), return format (candidates with license+attribution), and safe policy details. No annotations provided, so description carries burden; could mention failure modes or limits, but overall good disclosure.
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 fairly concise and front-loaded with key information (search purpose, no auto-download, policy). A few clauses (e.g., 'Default safe-only policy includes...') could be tightened, but overall efficient.
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 8 parameters, no output schema, and complex providers, description covers search scope, license awareness, policy, and pointer to download_image. Missing output format details but adequate for use.
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?
Description mentions query and providers implicitly but does not explain parameters beyond schema. Schema coverage is low (13%), yet description adds minimal parameter guidance (e.g., no details on timeoutMs, minWidth, 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?
The description clearly states it performs 'Federated image search across license-aware providers' and returns 'concise ranked candidates with license + attribution.' It distinguishes from sibling tools like download_image which handles downloading.
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?
Explicitly states when not to use ('Does NOT auto-download — call download_image after'), describes default policy and when to use open-only, and suggests using CLI for large batches.
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 fully discloses key behaviors: streaming with a 20MB cap, content-type guard, SHA-256 hashing, and a host blocklist. Since no annotations are provided, this information is critical for safe and correct usage.
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?
Three concise sentences with no redundancy. The first sentence states the purpose, the second lists technical details, and the third adds a restriction. Information is front-loaded and every sentence adds value.
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?
The description covers the tool's purpose, key behaviors, and return value (cached file path). It is mostly complete for a download tool, but lacks details on optional parameters and how they affect behavior.
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?
The description mentions a '20MB hard cap' which correlates to the maxBytes parameter but does not explain it or the cacheDir parameter. With 0% schema description coverage, the tool relies heavily on the description to clarify semantics, missing the opportunity to describe optional 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 uses a specific verb 'Download' and resource 'image URL', clearly stating the action and result (cached file path). It distinguishes itself from sibling tools like 'search_images' or 'fetch_with_license' by emphasizing local disk caching and typical usage from search results.
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 'typically from a prior search_images result', providing a clear context for when to use this tool. However, it does not explicitly state when not to use it or mention alternative tools for different scenarios.
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?
Given no annotations, the description carries full burden; it discloses heuristics, page metadata scanning, and the probe parameter triggering download. Sufficiently transparent for a simple tool.
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, no unnecessary words. First sentence describes function, second provides usage guidance. Efficient.
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?
No output schema, but description implies return of license info. For a 2-param tool, it covers behavior and usage. Could mention return format or error handling.
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 has 0% description coverage, but the description explains the url parameter as target and probe parameter as triggering download, adding value 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 the verb 'determine its license' and the resource 'URL', and distinguishes from siblings like download_image and search_images through its specific function.
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?
Provides explicit usage context: 'Use when an agent already has a URL and needs a go/no-go decision before shipping.' Lacks explicit alternatives or when-not-to-use, but the context is clear.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool respects robots.txt and returns images with dimensions and license. This is transparent about its behavior, though it could mention error handling or performance.
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 extremely concise—two sentences that pack all necessary information. No redundant words. It front-loads the core action and then provides usage context.
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?
For a tool with no output schema and moderate complexity, the description covers what the tool returns (images with dimensions and license) and its default behavior (respects robots.txt). The context is sufficient for an agent to understand when to invoke it among siblings.
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?
Input schema has 2 params (url, respectRobots) with 0% description coverage. The description clarifies the purpose of the tool and implies usage of both params (url as input, respectRobots via default respect). It adds meaning beyond the raw schema, especially for the boolean parameter.
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 action (return every <img> on a webpage), the resource (given a URL), and the output (images with dimensions and license). It distinguishes itself from siblings like download_image or fetch_with_license by focusing on triaging a source page.
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?
Explicitly states 'Use to triage a candidate source page before picking', indicating the intended use case. It also mentions respecting robots.txt by default, providing a constraint. However, it does not explicitly state when not to use or mention alternatives.
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:

[![webfetch MCP server](https://glama.ai/mcp/servers/ashlrai/webfetch/badges/card.svg)](https://glama.ai/mcp/servers/ashlrai/webfetch)

Score Badge

Copy to your README.md:

[![webfetch MCP server](https://glama.ai/mcp/servers/ashlrai/webfetch/badges/score.svg)](https://glama.ai/mcp/servers/ashlrai/webfetch)

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/ashlrai/webfetch'

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