Skip to main content
Glama

See what an agent reads

mttr_agent_view
Read-only

Reads one live page the way an agent does, the free "What an agent reads" tool: robots.txt asked first, so a page closed to mttr is not fetched; then its main content as Markdown with words and an estimated token count (about 4 characters a token), and what helped or hurt the reading, each with a state and, where the rulebook has one, its rule: main text found, text before script runs or a shell a script fills in, one h1, headings as an outline, the answer under the first question, structured data and its types, and how much of the page is its own text. Read by mttr's crawler; an assistant's own reader may differ.

Input Schema

NameRequiredDescriptionDefault
urlNoOne page, as a full public address such as https://example.com/guides/a-page. Read live.
siteNoA whole site, as a domain such as example.com, from its latest read instead: the share of its pages an agent reads, how much of each is the page, where that stands among every site read, what its pages lose, its trend and rivals, and each AI crawler as its robots.txt treats it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, yet the description still adds real sourcing behavior: robots.txt is asked first and a disallowed page is not fetched, and results come from mttr's own crawler rather than the caller's reader. It stops short of stating latency, caching, or failure behavior for unreachable pages.

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?

It is a single long run-on sentence that strings the whole diagnostic checklist together, which is useful content but hard to scan. The best material, the robots.txt gating, is front-loaded, but the middle collapses into an unpunctuated list.

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?

With no output schema, the description carries the burden of describing return contents, and it does enumerate the payload: Markdown main content, word and token estimates (~4 chars/token), and per-signal state plus rule reference. Only error and empty-content handling are left unaddressed.

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 100%, so both url and site are already documented in the schema, including the 'latest read' semantics for site. The description reinforces 'one live page' and 'from its latest read' but adds no format or syntax detail beyond the schema, so the baseline 3 applies.

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?

Opens with a specific verb and resource: 'Reads one live page the way an agent does', and pins it to the named free 'What an agent reads' tool. It does not name sibling tools such as mttr_page or mttr_explore to differentiate the scope, so an agent must infer the contrast.

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?

Usage is only implied through the url-vs-site split and the phrase 'the free ... tool'; there is no explicit statement of when to reach for this rather than mttr_page, mttr_structure or mttr_explore. The 'assistant's own reader may differ' caveat hints at scope but does not route the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources