Skip to main content
Glama

Check a URL Against Robots Rules

agent_access_check_url
Read-onlyIdempotent

What a public institution's published robots rules say for one URL and one product token, from Closed to Machines, a MORVS register of which public institutions serve an automated client that names itself and gives a contact address, what their robots rules say for each path checked, and where the official route to their data is (US federal agency hosts from the Federal Register's agency list, the 50 state legislatures, the G20 members' national government portals and national law sites, and MORVS's own two hosts; checked weekly by two clients, curl and Python urllib, from one residential US vantage, both sending the same identified user agent). Takes url (http or https) and optional product_token (a robots.txt product token such as GPTBot, ClaudeBot or Googlebot; MORVS when omitted). The rules are evaluated under RFC 9309 against the robots.txt text the register archived in its latest cycle, at the exact path and query of the URL; this server never requests the site. Returns robots.result (disallow_rule_matches, allow_rule_matches, no_rule_matches, no_rules_html_served, no_rules_rfc_unavailable, complete_disallow_rfc_unreachable, undetermined_edge_refused, or unknown), the decisive rule with its line, crawl_delay_s and max_requests_per_day where the file sets a delay for the token, the edge observation (the row's result class, status label, streak_weeks and each dated check with its responder), the official machine route where one was reviewed (URL, type, when it answered without a key, the route path's own robots result for the token, terms URL and status) or none_found or not_reviewed, and next_step (use_official_route, stop, no_rule_against_path_check_terms or unknown). The same host gives different verdicts for different paths. A host the register does not cover returns unknown with the absence note. Nothing here grants permission: a robots rule is a request a site publishes, not a licence, and a page that answered certifies no deeper path. A refusal is the edge's response to this client at a stated time; the vendor named is the responder seen in headers, not the institution's policy, and no record shows a reason. "No answer" (DNS, connection, TLS or timeout) is never a refusal; none_found (reviewed, nothing found where listed) and not_reviewed are kept apart, and neither shows that no route exists. Each answer leads with uncertainty[], then as_of (the cycle date), vantage, the source page on morvs.ai and the licence, and carries the question, vantage, label, robots-not-licence and absence notes (and the self-row note for MORVS's own hosts) and the claim rules. Data more than 9 days old makes each robots verdict and next step unknown, with a note. A failed or malformed read of the register is reported as temporarily unavailable, never as an empty answer. Answers are kept under about 25 KB. Organisations only; officials appear only by office and no person is named.

Input Schema

NameRequiredDescriptionDefault
urlYesRequired http or https URL (at most 2,048 characters), for example https://www.ilga.gov/legislation/; its exact path and query are evaluated.
product_tokenNoOptional robots.txt product token, for example GPTBot, ClaudeBot or Googlebot; MORVS when omitted. An unlisted token is evaluated without a group.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior5/5

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

Even with readOnly/idempotent/openWorld annotations already present, the description adds substantial behavior: the server never requests the site, verdicts go unknown after 9 days, register read failures surface as temporarily unavailable rather than empty, answers are capped near 25 KB, and refusal vs no-answer semantics are spelled out. It also pre-empts a likely misinterpretation by stating that a robots rule is a request, not a licence, and that no record shows a reason for a refusal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is dense and largely earns its place, but it is delivered as a single run-on opening sentence and a wall of subordinate clauses; key facts (no network request, 9-day staleness, default token) are not front-loaded. An agent must parse a paragraph to reach the operational essentials.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with rich enum-style outputs and no output schema, the description enumerates the robots.result classes, the edge observation, the official route sub-object, and next_step, plus absence and error behaviors. Nothing material needed to call or interpret the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3; the description still adds value by explaining that the exact path and query are evaluated (not just the host), that product_token defaults to MORVS when omitted, and that an unlisted token is evaluated without a group. That meaningfully exceeds the schema text.

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?

The description states a specific verb and resource: it evaluates a register's archived robots.txt rules for one exact URL and one product token, under RFC 9309, without fetching the site. It implicitly differentiates from siblings like agent_access and agent_access_institution by stressing per-path verdicts ("the same host gives different verdicts for different paths"), but it never names those siblings explicitly. The purpose is unambiguous once parsed, though it is buried inside an enormous opening sentence.

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 implied rather than stated: you submit a URL (and optional token) when you want the robots verdict for that exact path. It tells the agent how to read results (next_step values, unknown for uncovered hosts, staleness handling) but gives no explicit when-to-use/when-not versus the many sibling agent_access_* tools.

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.