Skip to main content
Glama

Offendersearch

by app.offendersearch

get_criminal_coverage

List the criminal-record jurisdictions searched, with kind and status.

Use it to discover which states and counties are reachable and which are
answering today, before relying on an empty result. Depth is uneven by design:
counties publish independently, so a state with many county jurisdictions is
not "better covered" than one that publishes a single statewide source — it is
differently structured.

Returns the jurisdiction roster; each entry carries its code, the state it
belongs to, the kind of records it holds (jail / prison / court / warrant /
registry) and whether it is currently answering.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden, and it does so well: it reveals that the data is dynamic ('currently answering'), that coverage depth varies, and that a state with many county jurisdictions is not necessarily better covered. It stops short of mentioning refresh behavior or operational constraints like rate limits, but for a zero-parameter listing tool the key traits are covered.

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

Conciseness5/5

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

The description is three short paragraphs, each earning its place: one states the core action, one gives usage context and an interpretive caveat, and one clarifies the return contents. It is front-loaded and avoids filler or restatement.

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 zero-parameter tool with no output schema, the description is nearly complete: it explains what is returned, how to use the result, and how to interpret an important data-quality nuance. It does not explicitly contrast with the similar-sounding get_registry_coverage sibling, which would have made the tool boundary fully unambiguous.

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 tool has zero parameters, so there is little to add beyond the baseline. The description still enriches the output semantics by explaining what each jurisdiction entry will contain—code, state, kind, and status—giving an agent a mental model even without schema-provided parameter docs.

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?

The description opens with a specific verb and resource: 'List the criminal-record jurisdictions searched, with kind and status.' It clearly distinguishes the tool's coverage-mapping purpose from the sibling search tools, which focus on queries rather than jurisdiction availability.

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

Usage Guidelines4/5

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

It gives explicit guidance to use this tool 'before relying on an empty result,' which tells an agent when the tool matters. It also explains how to interpret uneven coverage, but it does not explicitly name alternatives or state when not to use this tool versus get_registry_coverage or the search tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Offendersearch toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool maps to a distinct function: single vs batch registry search, criminal-record search, and coverage metadata for criminal versus registry sources. Despite 'offenders' and 'criminal' both being person-search domains, the descriptions make the boundary clear, and batch_search explicitly references search_offenders as its single-row equivalent.

Naming Consistency4/5

search_criminal/search_offenders and get_criminal_coverage/get_registry_coverage follow a consistent get_/search_ plus domain pattern. batch_search is the only mild deviation because it does not name the domain, but it remains readable and snake_case-consistent.

Tool Count5/5

Five tools is well-scoped for a records-search API: two search modes, a batch variant, and two coverage catalogs. No tool feels redundant or missing for the apparent purpose.

Completeness4/5

The surface covers single and batch registry search, criminal-record search, and coverage/health metadata for both domains. A batch criminal-search option would be a natural addition, but the current set has no dead ends for its read-only search scope.

Resources