Skip to main content
Glama

List Documented Data Handoffs

who_gets_your_data_handoffs
Read-onlyIdempotent

List documented data handoffs in Who Gets Your Data, a MORVS pilot register: edges from a source organisation and product, through a data type, to a recipient, each from one primary document (an FTC complaint or order, a Federal Register notice, a court opinion or order). Optional filters: data_type (a substring of the data type in the document's words), legal_status (a status key the register carries, such as allegation_in_complaint, finding, order_terms or request_count; matched against the row's own status and its settlement and remedy statuses, with the match shown), recipient (a substring of the recipient as worded or of a named recipient organisation) and year (the primary document's year, a year the register carries). Up to 25 edges in published order, with the full count and the counts by the rows' own legal status. Each handoff gives the source organisations, product and brands, the data type in the document's words, the recipient exactly as worded (named, or the document's own recipient class), the conduct period as worded, the verbatim quote, the document's type, issuer, date and URL, and a settlement, remedy, current status or opt-out only where a document states one. Each handoff carries its primary document's own legal status with the register's label exactly as published (a court's finding, an allegation in a complaint, a settlement with or without an admission, an order's terms, or a count of requests): an allegation is not a finding, a request is not a disclosure, and old conduct is not current practice. An empty result returns the register's absence note: no documented record in this corpus, which says nothing about what a product or company does now. The three tables (handoffs, broker registry answers, legal duties) hold different kinds of evidence and are never added together, scored or ranked; no answer gives a total across them. A pilot: a small, hand-checked set of documented handoffs, the brokers' own registry answers and one legal-duty exhibit, in three separate tables; it is not a census of data sharing. The answer carries the pilot note, lane note, coverage line, as-of date, file dates, legal-status labels, the register's rules, its licence and the source page on morvs.ai. Organisations, companies, agencies and governments only: no individual is named, and there is no bank or personal-report lookup.

Input Schema

NameRequiredDescriptionDefault
yearNoOptional year of the primary document (YYYY), a year the register carries; all years when omitted.
data_typeNoOptional case-insensitive substring of the data type in the document's words, for example location or viewing history; at most 80 characters.
recipientNoOptional case-insensitive substring of the recipient as the document words it, or of a named recipient organisation, for example Verisk.
legal_statusNoOptional legal-status key the register carries, for example allegation_in_complaint, finding, order_terms or request_count.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false. The description goes well beyond those annotations by describing the returned fields, the 25-edge limit with total counts, the absence note, the handling of legal-status labels, and the crucial caveats that allegations are not findings and older conduct is not current practice.

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

Conciseness3/5

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

The purpose is front-loaded, but the description is a single dense paragraph that repeats the pilot framing and the 'three tables are never combined' point. Several details (licence, source page, pilot note metadata) are relevant background but make the definition longer than necessary for selecting and invoking the tool.

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?

With no output schema and four optional filters, the description carries the full burden of explaining return values and is thorough: it lists the fields per handoff, pagination/count behavior, absence handling, legal-status labeling and dataset limitations. An agent has enough information to call it and interpret the response correctly.

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 adds useful meaning beyond the schema, especially that legal_status is matched against the row's own status and its settlement and remedy statuses with the match shown, and that data_type matches a substring in the document's own words.

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 gives a specific verb and resource: it lists documented data handoffs from source organisation/product through data type to recipient, each tied to a primary document. It distinguishes handoffs from the register's other tables (broker registry answers, legal duties), but it does not explicitly name or route against the sibling tools who_gets_your_data_lookup and who_gets_your_data_summary.

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 explains the optional filters and how to interpret results, including the absence note and the rule that the three tables are never combined. However, it never states when an agent should choose this tool over the sibling lookup or summary tools; the selection guidance is at best implied by the word 'List' and the described output.

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