Skip to main content
Glama

Find an Institution's Data Route

agent_access_route
Read-onlyIdempotent

Official machine routes to a public institution's data (an API, bulk files, a DCAT data.json catalog, a sitemap, a feed or a download page) as reviewed in 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). Found by institution_or_host (a host, an institution's name as listed, a jurisdiction, an ISO 3166 code such as US-IL or EU, or a row ID such as federal:www.usda.gov), with optional record_type (a route type the register carries). For each matching row (up to 25): its route review state, kept apart (route: a reviewed route is listed; none_found: reviewed, with the places searched; not_reviewed: no review yet), and for each route its URL and type, the evidence that ties it to the institution (kind, URL, and whether it was re-checked this cycle), the one request's record, when it answered without a key and what that answer confirms, its terms URL (or unknown), its official domain, and the route path's own robots result for MORVS and by token group, evaluated under RFC 9309 from the route host's archived robots.txt. A route that answered once without a key does not show that the data works or may be reused. 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
record_typeNoOptional route type the register carries, for example api, bulk, data_json, sitemap, feed or download_page.
institution_or_hostYesRequired host, institution name, jurisdiction, ISO 3166 code or row ID, for example www.ilga.gov, Agriculture Department, US-IL or federal:www.usda.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?

Although annotations already declare a safe read-only, idempotent, open-world operation, the description adds substantial behavioral context: uncertainty handling, as_of freshness, vantage, robots-not-licence caveats, route-state distinctions, failed-read semantics, and output size limits. It actively prevents common misinterpretations, such as treating a single answer as permission or a no-answer as 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 description is extremely long, with multiple nested parentheticals and caveats packed into enormous sentences. The core action and required parameter are buried inside a dense first sentence, making it hard for an agent to quickly scan the tool's purpose and call requirements.

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?

There is no output schema, and the description compensates by explaining the returned fields, route review states, uncertainty[] lead, as_of, vantage, source page, and licence. It also covers freshness degradation, malformed-read handling, and absence of permission, so an agent has enough context to interpret results 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 both parameters are already documented in the input schema. The description repeats the supported institution_or_host forms and record_type examples, and adds the useful detail that up to 25 matching rows are returned, but it does not materially expand parameter semantics beyond the schema.

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 clearly states that the tool finds official machine routes to an institution's data, gives the retrieval key, and describes the record types returned. It does not explicitly distinguish itself from sibling tools such as agent_access, agent_access_institution, or agent_access_check_url, so an agent must 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?

The description implies when the tool is useful: looking up an institution's reviewed data route by host, name, jurisdiction, ISO code, or row ID. It does not state when to use this tool instead of nearby siblings or what alternatives exist when a lookup fails or when a different view is needed.

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.