Retrieve stored robots.txt check history for a host, including dates, status, size, hash, response time, and distinct versions with first and last seen timestamps.
Every stored robots.txt check for a host (date, status, size, hash, response time) and each distinct version with first/last seen.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| host_or_url | Yes |
Changes observed during successful MCP inspections.
v1.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description usefully adds what the response contains (per-check fields and distinct versions with first/last seen), but says nothing about ordering, pagination behavior, or what happens when a host has no stored checks.
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 dense sentence that front-loads the primary return content and appends the version aggregation. No filler, though the parenthetical field list slightly crowds out the missing parameter guidance.
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?
With no output schema, the description must explain return values, and it does list the per-check fields and the version summary. However, it leaves the limit parameter and the host-vs-URL input form unexplained, which are material gaps for a two-parameter lookup tool.
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%, so the description carries the full burden. It clarifies that host_or_url targets a single host, but it never explains that a full URL is also accepted, and it does not mention limit at all — not its default, its maximum, or what it caps (checks vs. versions).
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 the specific resource (stored robots.txt checks) and the scope (one host), and it lists the fields returned plus the aggregated version view. It implicitly distinguishes itself from live-check siblings like robots_txt_check by emphasizing 'stored' history, though it never names an alternative explicitly.
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?
Usage is only implied: the word 'stored' signals this is for retrospection rather than a fresh fetch, which contrasts with robots_txt_check and robots_txt_diff. There is no explicit when-to-use, when-not-to-use, or named-alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.