OffenderSearch
Start free ›
AI integration · tool calling · MCP in private beta

Offender safety checks for AI agents and chatbots

Give any LLM a reliable sex-offender screening tool. Define one tool call — or, in private beta, connect the MCP server — and your agent can search all 58 US registries and cite its sources.

Start free ›Talk to salesAPI docs ›

$0.15 per tool call, $0.11 past 2,000 a month. 25 free searches, no card.

tool.jsonsearch_sex_offender_registry
{
  "name": "search_sex_offender_registry",
  "description": "Search US sex-offender registries by name, DOB, or location.",
  "input_schema": {
    "type": "object",
    "properties": {
      "firstName": { "type": "string" },
      "lastName":  { "type": "string" },
      "dob":       { "type": "string", "format": "date" },
      "state":     { "type": "string" }
    },
    "required": ["lastName"]
  }
}

Define a sex offender search tool for any LLM One schema, one handler.

Drop this tool schema into your agent framework. The handler calls POST /v1/search; the model gets back scored, source-tagged records.

  • Works with any tool-calling model
  • Or skip the glue code with the MCP server (private beta)
  • Verifiable results the agent can cite
  • The API key stays in your handler, never in the prompt
The loop

How an AI agent runs a sex offender registry check

  1. 01

    The model asks

    From the conversation, the model decides to call the tool with a name and whatever else it knows: date of birth, state, ZIP.

  2. 02

    Your handler calls the API

    It sends POST /v1/search with your API key in the X-API-Key header. The key stays on your server, never in the prompt.

  3. 03

    Records come back

    Scored, de-duplicated records, each with a match state and a link to the official registry entry.

  4. 04

    The model answers

    It states what matched and how strongly, cites the official record, and says which registries were searched.

The response

What the model gets back from a registry search

Pass these fields to the model, not just the records. They are what lets it answer honestly.

FieldWhat it tells the agent
statusWhether the search completed, or returned partial results within a deadline you set
counts.sourcesIncompleteHow many registries did not answer in full. Above zero, “no match” means “not determined”
sourceStatusEach registry searched and its status
matchStatedob_match, year_match, age_match or no_dob_age_year: what lined up
matchConfidenceA score the agent can threshold
source.recordUrlThe official registry record to cite
Guardrails

Guardrails for AI agents that handle registry data

  • Never conclude from a name alone. Tell the model that a no_dob_age_year match is a lead to verify, not an answer.
  • Treat partial as unknown. If any registry did not answer, the agent should say so rather than report a clean result.
  • Always cite the official record. Give the user the registry link so a person confirms before acting.
  • Keep people in decisions. An agent can surface a record; a person decides what to do with it.
  • No hiring or tenant decisions. Standard results are not a consumer report. Those decisions run through FCRA Partner Access.
  • Send only what is needed. Name, date of birth and location are enough. Do not pass other personal details to the tool.
Use cases

Where AI teams use registry search

Trust and safety review

A moderation assistant checks a flagged account holder and gives the reviewer a cited answer to confirm.

Marketplace onboarding

An onboarding agent screens a new provider before they can accept bookings, with weak matches routed to a person.

Volunteer and event coordination

An assistant checks a sign-up sheet in one batch call and summarises the rows that need a second look.

Neighborhood questions

A chatbot answers “who is registered near this address?” from a radius search, with official links.

Personal data

Handling personal data in AI registry checks

A registry search sends a name, and often a date of birth and a location, to the API. Keep that flow narrow: let the tool handler build the request from structured fields rather than passing the conversation, keep your API key on the server, and avoid writing full results into long-lived model memory or logs you do not need. If the people being searched are patients or residents, the search involves protected health information and a Business Associate Agreement is signed first; see HIPAA and BAA.

Results describe real people. An agent should present them neutrally, with the match label and the official link, and leave conclusions to the person it is helping.

Automation

Batch, monitoring and webhooks for automated workflows

For lists, give the agent a batch tool backed by POST /v1/batch, which takes up to 1,000 people per request and returns one result per row. For long-running checks, an async search posts the finished result to your callback URL once, on a basis. For ongoing watch, create a monitor: a person for $3 a month or an address for $10, with a signed webhook when a matching record appears or changes. See async and webhooks and monitoring.

Criminal records are available on the same key through the criminal records API, so one agent can check both. A booking is not a conviction, and the agent should say so.

Beyond registries

A background check API for AI agents

The same tool pattern works for criminal records, on the same key.

An agent that can check a registry can check criminal records the same way: define a second tool whose handler calls POST /v1/criminal/search. It returns jail, prison, court and warrant records, each labelled by type, so the model can say “a 2019 court case with a disposition” rather than “a criminal record”. The combined product is described on the background check API page.

Three rules keep an agent honest. Give the model the matchState and tell it that only a full date-of-birth match is an identification. Give it sourceStatus so it never reports a clear result when a source did not answer. And keep a person in the loop for anything short of a strong match.

An agent must not make a hiring or tenant decision from these results. The standard API is not a consumer report; those decisions run as FCRA workflows through FCRA Partner Access. For a ready-made tool server, see the MCP server for offender search; for code, the background check API in Python tutorial.

AI integration FAQ: LLM tools and registry data

How do I give an LLM access to registry data?
Define a tool that calls POST /v1/search and hand it to your model. The model receives scored, source-tagged records it can cite. An MCP server that removes the glue code is in private beta.
Can I build a safety-alert workflow?
Yes. Re-run searches against the continuously-updated corpus — and add a live block to re-verify a specific person at the source — then have your agent flag new matches. A common pattern for trust & safety and continuous monitoring.
Which models and frameworks does this work with?
Any model that supports tool or function calling, and any agent framework that lets you define a tool with a JSON schema and a handler. The handler is a plain HTTPS call to the REST API.
Can an agent check criminal records too?
Yes. Define a second tool on the criminal records API, on the same key. Tell the model that a jail booking is an arrest, not a conviction.
How is an AI tool call billed?
The same as any API call: $0.15 per search, $0.11 past 2,000 a month, with 25 free searches to start. A batch tool bills one search per row.
Does the model see reliable, verifiable data?
Every record includes a confidence score, the match basis, and a source citation, so agents can present verifiable answers rather than guesses.

The OffenderSearch APIs. One account, one key, one bill.

Related

Give your agent a registry search tool

25 free searches, no card. Call the REST API from your own tool today.

Start free ›Read the docs