Skip to main content
Glama
Sign In
agent-mcp

agent-mcp

by uukelele
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Webfetch

webfetch
Read-only

Fetch an HTTP or HTTPS URL as Markdown, plain text, or raw HTML, with private and loopback addresses blocked unless the operator permits them.

Instructions

Fetch an HTTP or HTTPS URL as markdown (default), text, or raw HTML. Private and loopback addresses are blocked unless the operator allows them.

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": {
      "url": "<url>"
    },
    "name": "webfetch"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYes
formatNomarkdown
timeoutNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description usefully adds that responses are converted (markdown by default) and that private/loopback addresses are blocked unless the operator allows them — a real network-level behavior. It says nothing about redirects, auth requirements, rate limits, truncation of large pages, or error behavior, which are significant for an outbound-fetch 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, zero filler, with the core action and output format front-loaded and the access constraint second. Every clause carries information an agent needs.

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?

An output schema exists, so return-value explanation is not required, and the description covers action, formats, and a key access restriction. The remaining gap is the undocumented timeout parameter and the absence of any routing hint versus websearch, which keeps it from a 5.

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 0%, so the description carries the burden and only partially compensates: it enumerates the format values (markdown default, text, raw HTML) and constrains the URL to HTTP/HTTPS. The 'timeout' parameter (default 30) is never mentioned, leaving one of three parameters undocumented in both schema and description.

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 opens with a specific verb+resource ('Fetch an HTTP or HTTPS URL') and names the output conversion, so an agent knows exactly what the tool does. It does not explicitly distinguish itself from the sibling websearch tool, which is the main adjacent choice, so it stops short of a 5.

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?

It implies you call this when you already have a concrete URL, but never states when to prefer webfetch over websearch, or what to do when the URL is unknown. The blocking clause for private/loopback addresses is a constraint, not routing guidance, so there is no explicit when/when-not guidance.

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