Fetch a public web page and return its beginning as Markdown (first 2,000 characters) plus final URL, status, and byte counts. Free local preview; the full page requires the paid HTTP API (x402, $0.01/call).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http(s) URL to read. | |
| max_bytes | No | Max bytes fetched from the response body. |
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 key behaviors: returns Markdown, truncates to 2,000 characters, and includes metadata (URL, status, byte counts). It also states the cost implication for full access. While it doesn't explicitly mention read-only semantics or error handling, the fetch nature and the preview limit cover the essential behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The first sentence front-loads the core action and output, the second provides pricing and alternatives. Every word adds value and the structure is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch tool with no output schema, the description gives enough: it tells what the tool returns and the limitation. It also mentions the alternative for full access. Minor missing details like error handling or redirects are not critical for a preview tool, and the schema covers parameter constraints. The description is adequate for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with 100% coverage. The description does not add additional parameter-specific guidance beyond what's in the schema; the mention of 'first 2,000 characters' is about output behavior, not parameter semantics. According to the rubric, when coverage is high, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states the action ('Fetch') and the resource ('public web page'), and enumerates the exact output: Markdown preview, first 2,000 characters, final URL, status, and byte counts. This clearly differentiates it from the sibling 'preflight_context' by framing it as a preview tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use this tool: 'Free local preview; the full page requires the paid HTTP API (x402, $0.01/call).' This directly guides the agent to choose the preview tool for quick checks and points to the alternative for full content. The scope is also limited to 'public' pages, setting boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool addresses a completely distinct concern: IP reputation lookup, token/context preflight, and web page preview. There is no realistic scenario where an agent would confuse these tools for one another.
All names are clean and snake_case, but the naming styles are mixed: 'ip_intel' is noun-noun, 'preflight_context' is modifier-noun, and 'read_page_preview' is verb-noun. The names are readable but do not follow a single predictable convention.
At 3 tools, the server is compact and every tool has a distinct, useful responsibility. The count feels appropriate for a focused utility API with no obvious excess or bloat.
The tools are self-contained for their advertised free/local behavior, but the set feels more like a small grab-bag than a complete agent-context domain. For instance, read_page_preview only expose an exact preview slice and points to a paid full-page API outside the MCP server, creatinga notable limitation. Broader workflow suchs as batch preprocessing, full-context retrieval, or history/lifecycle management are not present.