Skip to main content
Glama

Get Who Gets Your Data Figures

who_gets_your_data_summary
Read-onlyIdempotent

Figures from Who Gets Your Data, a MORVS pilot register built from FTC complaints and orders, Federal Register notices, a Supreme Court opinion, a Sacramento court order, FinCEN's Year in Review and one Geographic Targeting Order, and the California data broker registry as MORVS's Data Broker Register republishes it, table by table and never added across tables: handoff edges and primary documents, counts by legal status with the register's labels, named and class-only recipients, rows with a settlement or a current status, and the review queue's counts (a candidate is never an edge until reviewed); the brokers' California registry answers, with each sharing question as the form words it, the registrations and distinct brokers answering yes, and the government or law-enforcement overlap; FinCEN's fiscal-year Bank Secrecy Act figures with their wording, page and unit, and the Geographic Targeting Order's dates, ZIP count by county group and quoted terms; the register's headlines with their basis, legal status and sources; what is not covered (documents left for manual download, hosts never fetched, the incumbents credited and the register's stated gap), with the stop rules; and, kept separate, the "Bought by the government" lane (obligations by fiscal year with the floor year flagged, by capability with basis, bundles, the top buyers, the people, location and plate-data group, awards pending review, the lane's headlines with their basis, and the mixed, unclassified, context, excluded and dropped amounts kept apart) and the benefits and identity panel with its own headline. FinCEN's figures count searches, reports and filers, never people, and carry the register's count note. Broker rows are each business's own answer to the California registry, with the question as the form words it, and carry the broker note: no broker is accused of anything. 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. 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. The lane is a separate table: never added to the benefits and identity panel, the context (Palantir, Dataminr Defense Department licences), the excluded amounts or the handoff, broker and legal-duty tables. Amounts are obligations net of de-obligations, never outlays: an outlay appears only where the award record gives one, labelled as the outlay for the whole award. A contract is not proof of use on any person. Capability comes from the award's own words or a single-product vendor's product line, each with its basis (transaction_words, award_base_words, vendor_product or review); a bundle naming two capabilities sits in the lane total and in no capability total. The floor year (FY2026 at launch) is a floor, as Defense Department actions reach FPDS late, and each figure for it is flagged. A reviewed universe, not a complete inventory. 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

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already mark this as read-only, open-world, idempotent and non-destructive, but the description adds extensive behavioral context: it names data sources, warns 'a pilot... not a census,' says no individual is named, and explains output caveats like 'obligations net of de-obligations, never outlays.' This is valuable disclosure, though delivered in an unstructured wall of text.

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 enormous run-on paragraph of several hundred words, repeating 'never added together' and burying the purpose behind long clauses. It is informative but poorly structured and not front-loaded.

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

Completeness4/5

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

For a no-parameter summary tool with no output schema, the description is thorough about scope, sources, and caveats, and it notes that the answer carries notes, as-of date, labels and licence. It stops short of describing the actual response structure, leaving some ambiguity about how the figures are organized.

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?

The schema has zero parameters, so there is nothing for the description to clarify. Baseline 4 applies for a parameterless tool.

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 that it returns figures from the 'Who Gets Your Data' MORVS pilot register across handoff, broker, FinCEN, government-lane and benefits tables. The resource and content are specific, but it never explicitly distinguishes itself from sibling tools such as who_gets_your_data_handoffs or who_gets_your_data_government.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No sentence says when to choose this summary over the sibling detail tools. The closest guidance is a constraint ('no answer gives a total across them'), which tells the agent what not to expect rather than when to invoke it.

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