Read a stored web page by returning a window of its text from a given offset and length. Use it to inspect or extract specific parts of fetched sources.
Inspect a stored source in full: returns a window of the stored page text
starting at offset with up to length characters (capped).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| length | Yes | ||
| offset | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose useful non-obvious behavior: the result is a window, `offset` sets the start, and `length` is capped. However, it omits access/permission requirements, what happens on out-of-range offsets, and error behavior, so transparency is only partial.
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?
A single sentence that front-loads the purpose and packs the windowing semantics into the same line, with no padding. The only slack is the mildly misleading 'in full'.
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?
An output schema exists, so return values need not be described, and the windowing parameters are covered. Still, for a tool sitting in a six-sibling family with ambiguous names, the definition is not complete enough: it lacks routing guidance and provenance for `url`, and there are no annotations to fill the gap.
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?
Schema description coverage is 0% and all three parameters are required, so the description must compensate. It meaningfully explains `offset` (start position), `length` (character count, capped), and implies `url` selects the stored source, but it never clarifies what form `url` takes or where it is obtained, leaving one parameter under-specified.
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 names a concrete resource (a stored source's page text) and the exact mechanics of retrieval (a window starting at `offset` of up to `length` characters). It is clear what the tool returns, but it does not distinguish itself from closely named siblings like `read` or `grep`, and the phrase 'in full' sits awkwardly against 'returns a window'.
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?
There is no statement of when to use `open` rather than `read`, `grep`, `search`, or `corpus_search`, and no prerequisites (e.g. that the url must come from a prior search) are given. The agent is left to infer the routing decision entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.