Skip to main content
Glama

Offendersearch

by app.offendersearch

get_registry_coverage

List every registry we cover plus its scope, legal status, and health.

Public coverage catalog (no API key required). Use it to discover the
`jurisdictions` codes accepted by search_offenders / batch_search and to
check per-registry freshness/health before relying on a result.

Returns: { count, registries: [ SourceInfo ] } where each SourceInfo is:
  - id: registry code (e.g. 'IL', 'TX', 'PR')
  - name: human-readable registry name
  - covers: [state codes] a registry covers ('*' = national / all)
  - scope: 'state' | 'national'
  - status: 'live' | 'building'
  - legal: { commercialUse: 'allowed'|'restricted'|'prohibited'|'unknown' }
  - health: { lastSuccessAt, typicalLatencyMs, ageSeconds, freshFor }

`health` is OPERATIONAL COVERAGE METADATA about our ingest schedule, published
for transparency. It is NOT a quality warning about a search result: a search
serves every registry's best available data regardless of `freshFor`, so a
registry listing only 'weekly' still contributes its records to a
freshness='daily' search. Do NOT tell a user their search results are stale,
unreliable or out of date on the basis of these fields — they are not. The only
completeness signal that belongs in an answer is `counts.sourcesIncomplete` /
`warnings[]` from the search response itself.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral disclosure burden. It thoroughly explains the return shape, the meaning of each SourceInfo field, and the crucial semantic distinction that health fields are operational metadata, not search-quality indicators. It also states that no API key is required.

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 longer than average, but every section earns its place: a one-sentence purpose, a structured return field listing, and a critical behavioral warning that prevents misinterpretation. The most important caveat about health fields is clearly separated and emphasized.

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?

For a no-parameter tool with no output schema, the description is exceptionally complete. It covers the purpose, use cases, return contract, field enums, and operational semantics, including exactly what the health fields should and should not be used for. Nothing essential 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?

The input schema has zero parameters and 100% schema coverage, so there is no parameter semantics burden for the description. The description adds no parameter-level meaning, but none is needed. Baseline 4 for a no-parameter tool is appropriate.

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?

States a specific verb and resource: 'List every registry we cover plus its scope, legal status, and health.' This clearly identifies what the tool does. However, it does not explicitly distinguish itself from the sibling tool get_criminal_coverage, relying on name similarity rather than an explicit differentiation.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use guidance: discover jurisdiction codes accepted by search_offenders/batch_search and check per-registry freshness/health. It also gives a strong 'do not' instruction against interpreting health fields as search-quality warnings, which is essential for correct use.

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