Skip to main content
Glama

Get a Reviewed Checkbook Vendor

bought_by_your_police_vendor
Read-onlyIdempotent

One reviewed vendor in 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, found by vendor (its name, or a payee alias as a checkbook prints it). Returns the reviewed entry (its column: a family, the panel or a broad platform; the family and its label, whether the family is established, the register's wording for it, each basis with its kind, URL, the award words or quoted page text, and the register's check of it with its status and date where it records one, the row rule that assigns rows by their own words, the aliases reviewed and the rows published) and the governments whose checkbooks report payments to it, each with its figures by lane and family (police lane, other departments, department not stated, unclassified, the panel, or the broad platforms) and each with its own period and row units, never summed across governments, with the arguments that return its rows; then the governments read with no payments found to it, each with its 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
vendorYesRequired reviewed vendor name or a payee alias as a checkbook prints it, for example Clearview AI, TALX or Axon; at most 80 characters.

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?

Beyond the readOnly/idempotent/openWorld annotations, the description discloses substantive behavior: three columns kept apart and never summed, figures never aggregated across governments, an explicit absence note for empty results, a ~25 KB answer cap, a reviewed allow-list restricting payees, person-naming rows dropped, withheld structured fields, and the caveat that payments are not contract values or deployment evidence. This is unusually rich behavioral context.

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 an enormous single block that runs through register architecture, lane definitions, caveats, licensing and output fields in comma-spliced prose. It is front-loaded only in the sense that the purpose appears first; everything after is undifferentiated and hard to scan. Much of the enumeration could be trimmed or structured.

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 the reviewed entry's columns, the per-government figures and lanes, the no-payments-found list, the metadata carried in the answer, and the key interpretive caveats. An agent has enough to interpret results correctly, even if the presentation is unwieldy.

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%, and the schema already documents the vendor parameter with examples (Clearview AI, TALX, Axon) and the 80-character limit. The description's phrase 'its name, or a payee alias as a checkbook prints it' largely restates the schema, adding little beyond it. Baseline 3 applies when the schema does the heavy lifting.

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 first clause states a specific resource: one reviewed vendor in the Bought by Your Police MORVS register, looked up by vendor name or payee alias. That is a clear verb+resource and distinguishes it from the aggregate sibling bought_by_your_police. Clarity is degraded only because the purpose sentence is buried inside a very long, comma-chained enumeration of return contents.

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 the usage case (look up a single reviewed vendor by name or alias) and mentions the alias input route, but never states when to use this instead of bought_by_your_police or the other vendor-related siblings, nor any exclusions. Usage is left to inference from the tool name and the 'one reviewed vendor' framing.

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