Skip to main content
Glama

Find Closed to Machines Rows

agent_access
Read-onlyIdempotent

Rows and headlines of 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). Optional filters: jurisdiction (a jurisdiction or ISO 3166 code the register carries, such as Illinois, US-IL or EU), slice (a slice ID the register carries, such as federal, legislature, g20_portal, g20_law or self), status (a result class ID the register carries, such as refused_held, mixed, refused_unconfirmed, robots_rule_stop, no_answer, served, directory_link_dead or not_checked_by_policy), vendor (an edge responder the register names from response headers, such as Akamai or Cloudflare), token (a product token the register evaluates; each row then shows its home-path verdict for that token) and has_route (true or false). With filters: counts by class (and by home-path verdict for the token) over all matching rows, and up to 25 rows (institution, host, slice, jurisdiction, class, status label and streak, robots state, the home-path verdict, responders, route review state, and the arguments that return the full row). With no inputs: the register's headlines with their basis, the counts by class for each slice, the result-class definitions, and the coverage gaps (rows not checked by policy, dead directory links, rows without a robots reading, and rows with no route review). 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
sliceNoOptional slice ID the register carries, for example federal, legislature, g20_portal, g20_law or self.
tokenNoOptional product token the register evaluates, for example GPTBot, ClaudeBot or MORVS; each row then shows its home-path verdict for that token.
statusNoOptional result class ID the register carries, for example refused_held, mixed, robots_rule_stop, no_answer or served.
vendorNoOptional edge responder named from response headers, for example Akamai or Cloudflare; the responder, never the institution's policy.
has_routeNoOptional true for rows with a reviewed official route listed, false for the others (none_found or not_reviewed).
jurisdictionNoOptional jurisdiction or ISO 3166 code the register carries, for example Illinois, US-IL, France or EU.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior5/5

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

Although annotations already declare readOnlyHint=true and openWorldHint=true, the description adds substantial behavioral context: data freshness rules (verdicts become unknown after 9 days), error handling (failed reads reported as temporarily unavailable), response size limits (~25 KB), and nuanced caveats about robots rules not being a licence and refusal vs no answer. This goes well beyond the annotations.

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 description is a single, extremely long and dense paragraph with run-on sentences. The purpose is front-loaded but buried inside a sprawling first sentence, and the volume of detail, while informative, makes it hard to scan. Every sentence may earn its place in terms of content, but the structure is not concise.

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?

Given the tool's complexity (6 optional parameters, no output schema, annotations already present), the description is thorough: it covers filtered and unfiltered outputs, response limits, data freshness, error handling, and important caveats about interpretation. An agent has enough context to call the tool correctly.

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 description coverage is 100%, so all parameters are already documented in the input schema. The description lists the filters and gives examples, but adds little semantic detail beyond what the schema provides—for instance, it repeats that token shows a home-path verdict, which is already in the schema description. Baseline 3 is appropriate.

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 specifies what data the tool returns—rows and headlines from the Closed to Machines register—and details the optional filters. It does not, however, explicitly distinguish itself from sibling tools like agent_access_institution or agent_access_route, leaving the agent to infer its role as the general query endpoint.

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?

The description explains what happens when filters are provided versus when no inputs are given, which implies usage. But it offers no explicit guidance about when to choose this tool over alternatives such as agent_access_changes or agent_access_check_url, and no exclusions are stated.

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.