Skip to main content
Glama

Find Federal Data Tool Purchases

who_gets_your_data_government
Read-onlyIdempotent

Federal purchases in the "Bought by the government" lane of Who Gets Your Data, a MORVS pilot register built from USAspending prime contract transactions (award types A to D) by action-date fiscal year over the lane's window (FY2017 to FY2026 at launch): what agencies obligated to the reviewed vendors and resellers of the lane's capability classes (nine at launch; ids as the register carries them, such as device_forensics, people_search, comms_analysis, social_media_osint, plate_data, face_recognition, cell_site_simulators and location_data). Optional filters: agency (an agency or sub-agency name, or an abbreviation derived from the names, such as ICE or FBI), vendor (a recipient as filed, its parent, a reviewed vendor family or a recipient UEI, such as Cellebrite or LexisNexis), capability (a class id or its label, as the register carries them) and fiscal_year (an action-date fiscal year the register carries). With filters: the matching counted totals by fiscal year and by capability, bundles kept beside, the count of matching awards awaiting review, and up to 25 awards, largest matching obligation leading (PIID, agency, recipient as filed, fiscal years, the amount obligated, each matching transaction's capability and basis, the matched words and the words as published or "withheld", the outlay for the whole award where the record gives it, and the USAspending link). With no filters: the lane's headlines with their basis, the totals by fiscal year and by capability, and the top buyers. 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. An empty result returns the lane's absence note: no award in this reviewed universe, which says nothing about purchases outside it. 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. The answer carries as_of, the file dates, the source page on morvs.ai, the licence and the lane's universe, obligation, use, capability, floor, absence, context and panel notes. Recipients as filed, organisations only: the register drops sole proprietors and person-shaped recipients, and award words that could name a person are published as "withheld".

Input Schema

NameRequiredDescriptionDefault
agencyNoOptional agency or sub-agency name, or an abbreviation derived from the names, for example ICE, FBI or Department of Homeland Security; at most 80 characters.
vendorNoOptional recipient as filed, its parent, a vendor family or a recipient UEI, for example Cellebrite, LexisNexis or Pen-Link; at most 80 characters.
capabilityNoOptional capability class id or its label, as the register carries them, for example device_forensics or Face recognition.
fiscal_yearNoOptional action-date fiscal year (YYYY) the register carries, for example 2026 (a floor); all years when omitted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior5/5

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

Beyond the annotations (readOnly/idempotent/non-destructive/openWorld, which already cover safety), the description discloses non-obvious behavioral rules: amounts are obligations net of de-obligations and never outlays, bundled awards count in the lane total but no capability total, the FY2026 floor is flagged, empty results return an absence note, and person-shaped recipients/words are withheld. It also states what the response carries (as_of, file dates, source page, licence, notes).

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 definition is a single ~400-word paragraph of run-on sentences with deep parenthetical nesting; the core purpose (what it returns) is buried behind a long provenance clause. Much of the content is substantive, but the lack of structure and front-loading makes it hard to scan and the volume exceeds what an agent needs before calling.

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, the description carries the full burden and does so: it enumerates both filtered and unfiltered return payloads field by field, documents the counting/attribution caveats, the absence note, and explicitly warns the lane is a separate table never merged into the benefits, context, excluded-amounts or handoff tables. Nothing an agent needs to interpret the result correctly is missing.

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 100%, so baseline would be 3, but the description adds meaning beyond the schema: it enumerates the capability class ids the register carries (device_forensics, people_search, comms_analysis, social_media_osint, plate_data, face_recognition, cell_site_simulators, location_data) and explains that fiscal_year is action-date based and FY2026 is a floor. It also clarifies that agency accepts abbreviations derived from agency names and vendor accepts UEIs/parents/families.

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 opening states a specific verb and resource: federal prime-contract purchases (award types A–D) from USAspending in the 'Bought by the government' lane, filtered by agency/vendor/capability/fiscal year. Scope and data source are unambiguous. It never explicitly distinguishes itself from the sibling who_gets_your_data_government_award, so it falls short of the sibling-differentiation bar for a 5.

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?

Usage is described behaviorally — 'With filters: ...' vs 'With no filters: the lane's headlines' — which implies how to call it, but there are no explicit when-to-use/when-not statements or routing to alternatives such as who_gets_your_data_government_award or who_gets_your_data_summary. The agent must infer which WHO-GETS-YOUR-DATA tool to pick.

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