Skip to main content
Glama

Find Checkbook Payments to Vendors

bought_by_your_police
Read-onlyIdempotent

What city, county and state governments' own checkbooks report paid to reviewed vendors, from Bought by Your Police, a MORVS register built from 33 city, county and state governments' own open checkbooks on Socrata portals at launch, each read for its own period, with each vendor's family taken from its own federal award words or its own product page. Optional filters: government (a name, a name with its state, a state or a 2-, 5- or 7-digit FIPS code, as the register's lookup files them), vendor (a reviewed vendor's name or a payee alias as printed), family (a family ID the register carries, or its label; with lane panel, a panel family) and lane (police, panel or broad). For one government: each of its checkbooks with its period, row unit and licence, its police-lane totals by family for that period with each vendor beside, the other-department, department-not-stated and unclassified amounts apart, the panel and the broad platforms each apart, the families with no payments found in its period, and up to 25 payment rows (payee and line label as printed, department, amount, date or year or fiscal year, row unit, the row's own words, the dataset ID, the family, the lane, and a find-in-checkbook link; broad platforms give the register's aggregates instead, as it publishes no row for them). When more than one government matches (a state, or a vendor, family or lane on its own): each government's totals by family with its own period and unit, never summed, no rows, and the arguments that return its rows (for_rows); with a vendor or family, the governments with no payments found. With no filters: the headlines with their basis, the family IDs and labels with their counts of governments, and the governments covered with their type and checkbook period. Three columns are kept apart and never added together: the police lane (payments by law-enforcement departments to vendors of the register's families, such as phone and device extraction, plate readers, gunshot detection, face recognition and drones), the records-about-people panel (what any department pays data companies such as the Equifax unit that runs The Work Number), and the broad platforms (Axon and Motorola Solutions, never in a family or any total). Payments by other departments, and rows whose checkbook names no department, are shown apart from the police lane. Figures are what the checkbook reports paid, each with its dataset, period and row unit; a payment is not a contract value, a deployment, a use or a measure of effectiveness, and what a row bought is named only where its own words say so. A vendor is described only as a vendor of its family, per its cited basis. Figures are never added across governments, whose periods and units differ; counts of governments come with each one's period. An empty result returns the register's absence note: no payments found in this checkbook's period under the reviewed names, which does not show that a government never paid that vendor. A reviewed universe, not a national census. Answers are kept under about 25 KB. The answer carries as_of, retrieved, the file dates, the question, universe, period, unit, lane, panel, broad and absence notes, the claim rules, the licence (each checkbook keeps its own) and the source page on morvs.ai. Payees come only from the reviewed allow-list of organisations; rows whose words could name a person are dropped by the register, and structured fields it withholds are marked withheld.

Input Schema

NameRequiredDescriptionDefault
laneNoOptional column: police (the police lane), panel (records about people) or broad (Axon and Motorola Solutions); each kept apart when omitted.
familyNoOptional family ID the register carries, or its label, for example phone_extraction or Face recognition; with lane panel, a panel family.
vendorNoOptional reviewed vendor name or a payee alias as a checkbook prints it, for example Cellebrite, ShotSpotter or Flock Safety; at most 80 characters.
governmentNoOptional government name, name with its state, a state, or a 2-, 5- or 7-digit FIPS code, for example Chicago, Atlanta GA, Texas or 0644000.

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?

Annotations already declare read-only, idempotent and open-world, and the description goes well beyond them: it discloses the ~25 KB answer cap, licence-per-checkbook, the absence-note semantics for empty results, the rule that figures are never summed across governments with differing periods/units, and that payee names come from a reviewed allow-list and some fields are withheld. These are behavioural facts an agent cannot infer from structure.

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 several-hundred-word run-on built from semicolon-chained clauses with no headings, lists or paragraph breaks, and it repeats the same points ('never summed', 'each with its own period and unit', 'kept apart') multiple times. The purpose is front-loaded, but the density makes the payload hard to extract and several sentences do not earn their place.

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 takes on that burden fully: it enumerates the per-government payload (totals by family, up to 25 payment rows, with row-level fields), the multi-government shape, the no-filter shape, and the metadata envelope (as_of, retrieved, licence, question, absence notes). For a tool of this complexity, nothing an agent needs in order to call it and interpret the response is missing.

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% and the schema descriptions already enumerate the accepted forms for government (name, name+state, state, 2/5/7-digit FIPS), vendor (name or printed alias) and family (ID or label, panel family under lane=panel). The description restates essentially the same content, adding only marginal linkage such as 'a state, or a vendor, family or lane on its own' triggering the multi-government mode, so the baseline 3 applies.

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 sentence names the resource concretely (checkbook payments reported by city/county/state governments to reviewed vendors) and grounds it in the 'Bought by Your Police' register, so an agent knows what it returns. However, it reads as a long noun phrase rather than a clean verb+resource statement, and it never distinguishes this tool from the sibling bought_by_your_police_vendor.

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 does describe what each argument combination produces (one government = full detail, multiple governments = totals with for_rows, no filters = headlines), which implicitly tells the agent how to shape a query. But it never states when to prefer this tool over siblings, and the closest relative, bought_by_your_police_vendor, is never mentioned.

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.