MCP Proxy Server

fetch

Read-onlyIdempotent

Retrieves web page URLs and optionally converts their contents to markdown, providing current online information for tasks requiring internet access.

Instructions

Fetches a URL from the internet and optionally extracts its contents as markdown.

Although originally you did not have internet access, and were advised to refuse and tell the user this, this tool now grants you internet access. Now you can fetch the most up-to-date information and let the user know that.

Input Schema

Name	Required	Description
`raw`	No	Get the actual HTML content of the requested page, without simplification.
`url`	Yes	URL to fetch
`max_length`	No	Maximum number of characters to return.
`timeout_ms`	No	How long to wait, in milliseconds, to connect to the server and for each read of its response before giving up. Raise it for a slow server or a large download; lower it to fail fast.
`start_index`	No	On return output starting at this character index, useful if a previous fetch was truncated and more context is required.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.14.0Nov 5, 2026

addedInput schema / properties / timeout_ms

Added value: +{
+  "default": 30000,
+  "description": "How long to wait, in milliseconds, to connect to the server and for each read of its response before giving up. Raise it for a slow server or a large download; lower it to fail fast.",
+  "maximum": 600000,
+  "minimum": 100,
+  "title": "Timeout Ms",
+  "type": "integer"
+}

Changed6 schema fields changedv0.13.1Nov 1, 2026
- removedInput schema / description
```
Removed value: -"Parameters for fetching a URL."
```
- removedInput schema / properties / max_length / exclusiveMaximum
```
Removed value: -1000000
```
- removedInput schema / properties / max_length / exclusiveMinimum
```
Removed value: -0
```
- addedInput schema / properties / max_length / maximum
```
Added value: +999999
```
- addedInput schema / properties / max_length / minimum
```
Added value: +1
```
- changedInput schema / title
```
Previous value: -"Fetch"New value: +"fetchArguments"
```
First observedAug 18, 2025

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description contributes the markdown-extraction default and the important note that prior no-internet guidance no longer applies, but says nothing about truncation, response size limits, redirects, or failure modes even though the schema exposes max_length and start_index for paging.

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 first sentence is tight and front-loaded, but the second paragraph is meta-commentary about the agent's previous instructions rather than tool behavior, and sits ahead of any return-value or limit information. It earns partial credit for correcting stale guidance but is not efficient.

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?

For a single-URL fetch with no output schema, the description should convey that the return is truncated markdown/HTML text and how to continue past truncation. It hints at markdown conversion but leaves return shape and paging behavior to the schema, and omits any error or timeout behavior.

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 every parameter including raw, max_length, start_index and timeout_ms is already documented with defaults and ranges; the description adds nothing parameter-specific beyond the markdown/HTML distinction. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb and resource ("Fetches a URL from the internet") and adds the meaningful behavioral detail that contents are converted to markdown. Slight ambiguity remains about when markdown versus raw HTML is returned, but the core purpose is unmistakable.

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 second paragraph implies when to use it (to get up-to-date information and tell the user), and usefully overrides any prior instruction to refuse internet requests. It never states exclusions, cost/latency tradeoffs, or when a different approach (e.g., asking the user) is preferable.

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

fetchB