Skip to main content
Glama

Get a Closed to Machines Row

agent_access_institution
Read-onlyIdempotent

One row 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), in full, found by query (a host, an institution's name as listed, a jurisdiction, an ISO 3166 code, or a row ID such as federal:www.usda.gov; when several match, each in short form with the arguments that return it). Returns the institution, its slice and authority (its Federal Register agency page or MORVS's curated list), the CISA .gov registry match for its domain (domain type, organisation and suborganisation; never a contact), its result class with its definition, status label, streak and class history, the robots.txt facts (status, archive hash, crawl delays, sitemaps, Content-Signal, intent-ambiguity lines and route pointers), the home-path verdict for each product token the register evaluates, grouped as training, search or user-acting (with each token's operator and whether its group follows the operator's own description), the dated checks with their responders, the route review and routes with their terms, the change-log entries for the host, and GSA Site Scanning's record for a federal host; the redacted robots excerpt when it fits. 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
queryYesRequired host, institution name, jurisdiction, ISO 3166 code or row ID, for example www.usda.gov, Illinois, morvs.ai or federal:www.nsa.gov.

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?

Beyond the read-only and idempotent annotations, it discloses important behavioral caveats: robots rules are not licences, refusals are edge responses rather than institutional policy, absent data is not proof of no route, stale data beyond 9 days makes verdicts unknown, and failed reads are reported as temporarily unavailable. It also states the response size limit and privacy boundary (organisations only, no named individuals), which materially helps the agent interpret results.

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 dense wall of text with nested qualifications and caveats, not front-loaded or structured for quick parsing. While much of the content is useful, it is far longer than needed and would benefit from bullet points or separate sections.

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 and the absence of an output schema, the description thoroughly enumerates the returned fields: institution, authority, CISA registry match, result class, robots facts, token verdicts, dated checks, routes, change log, and GSA scanning. It also covers data freshness, error handling, and response-size limits, so an agent has enough context to invoke it 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 coverage is 100%, so the single query parameter is already well documented. The description adds examples and the multiple-match behavior, but does not add syntax or format details beyond what the schema provides; 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 states a specific resource and scope — one row of the Closed to Machines register — and explains what that register contains. It does not explicitly differentiate itself from sibling tools such as agent_access, agent_access_changes, or agent_access_route, leaving the agent to infer which one to use.

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?

It specifies acceptable query forms (host, institution name, jurisdiction, ISO code, row ID) and notes that multiple matches are returned in short form. However, it gives no explicit when-to-use guidance relative to the closely named sibling tools, so usage is only implied.

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