Skip to main content
Glama

Find Reported Wiretap Orders

wiretap_orders
Read-onlyIdempotent

Finds individual court-authorized wiretap orders as published in one annual US Courts Wiretap Report. Defaults to the latest report year; filters use the report year, court, state, jurisdiction, offense group and intercept type. A row was reported to the courts in that report year and may have ended earlier. Results and costs are per order as reported. The annual headline count undercounts that year because some orders are reported in later years. Related orders can share people, intercepts and arrests, so do not sum those fields across rows. Zero or blank means none reported, not that nothing happened. Flags identify missing prosecutor reports and implausible figures. A missing row is not proof that no surveillance occurred; the published order shards start in 2016.

Input Schema

NameRequiredDescriptionDefault
typeNoInterception type code from the register lookups.
courtNoCourt type: federal or state.
limitNoMaximum order rows returned; default is set by the register, allowed 1-100. Never sum people or intercepts across orders.
stateNoState name as printed in the register, for example TEXAS.
report_yearNoReport year; defaults to the latest published year. Each row is an order reported in that year; late reports can raise later counts.
jurisdictionNoCase-insensitive jurisdiction name substring.
offense_groupNoOffense group label from the register, for example drugs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Very rich beyond annotations: explains that zero/blank means none reported rather than nothing happened, that flags mark missing prosecutor reports and implausible figures, that a missing row is not proof of no surveillance, and that shards start in 2016. It also warns that rows may double-count shared people/intercepts/arrests.

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

Conciseness4/5

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

Dense but front-loaded: verb and source first, then caveats. Every sentence carries an interpretive caveat, though the aggregation of warnings makes it somewhat heavy relative to a filtered-list 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?

No output schema exists, and the description covers the interpretation pitfalls an agent needs (per-order costs, non-summable fields, undercounting, 2016 start boundary). Complete for correct use and reporting of results.

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 is 3, but the description adds real meaning: report_year denotes the year an order was reported (late reports raise later counts), and filters are framed as report-year scoped. This goes beyond the schema's per-parameter text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Finds individual court-authorized wiretap orders') plus the exact source ('one annual US Courts Wiretap Report'). An agent can immediately distinguish this from broad surveillance-related siblings like national_security_surveillance.

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?

Explains the default (latest report year) and which fields are filterable, which orients usage. However, it does not state when to prefer this over a sibling tool or give explicit when-not conditions, leaving usage routing implied rather than directed.

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.