DoorProfit Crime & Neighborhood Data

Search Registered Offenders

search_offenders

Read-onlyIdempotent

Search US registered offenders in one of two modes. Location mode: pass address or lat+lng, plus an optional radius in miles (default 1, capped at 3); results include each offender's distance from the search point. Name mode: pass at least one of first_name, last_name or dob, optionally narrowed by city/state/zipcode — those three filters alone are not accepted. Location parameters take precedence when both are supplied. Use this only for registered-offender questions; for an overall safety grade use get_crime_data instead. Results are paginated (page, limit, max 100 per page) and each page requested requires a DoorProfit API key and consumes 1 call from that key's quota.

Input Schema

TableJSON Schema

Name	Required	Description
`dob`	No	Date of birth, YYYY-MM-DD.
`lat`	No	Latitude (use together with lng, as an alternative to address).
`lng`	No	Longitude (use together with lat, as an alternative to address).
`city`	No	City filter for name-based searches.
`page`	No	Page number (default 1).
`limit`	No	Results per page (default 50, max 100).
`state`	No	Two-letter state code filter, e.g. "OK".
`radius`	No	Search radius in miles for location searches (default 1, max 3).
`address`	No	Full US street address, e.g. "500 Adams St, Tulsa, OK". Provide either address OR lat+lng.
`zipcode`	No	Zipcode filter for name-based searches.
`last_name`	No	Last name for name-based searches.
`first_name`	No	First name for name-based searches.

Output Schema

TableJSON Schema

Name	Required	Description
`page`	No
`radius`	No	Search radius in miles (location searches only).
`success`	Yes
`offenders`	No
`test_mode`	No
`search_type`	No	"gis" for location searches, "name" for name searches.
`total_count`	No	Total matching results.
`total_pages`	No
`offenders_count`	No	Results on this page.

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is safe. The description adds valuable behavioral context beyond annotations: results include distance from search point, radius default/cap, pagination details (page, limit, max 100), and importantly that each page request requires a DoorProfit API key and consumes 1 call. This is meaningful disclosure beyond the structured annotations.

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?

The description is densely informative with no wasted sentences, covering modes, parameter grouping, precedence rules, exclusions, and API-usage implications in a compact form. It could be split into clearer sub-sections for readability, but every sentence earns its place and the critical information (mode selection, API key cost) is front-loaded.

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?

Despite 12 parameters and no required fields, the description fully explains mode selection, parameter constraints, precedence, pagination, and API call costs. The output schema exists so return-value documentation is handled structurally. For a complex multi-mode tool, this is remarkably complete.

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 the schema fully documents all 12 parameters. The description adds value by explaining parameter relationships and constraints beyond what the schema states: which params belong to which mode, the 'three filters alone not accepted' rule for city/state/zipcode, radius default/cap semantics, and pagination defaults. This exceeds the baseline 3 for full coverage documents.

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 clearly states the verb (search) and resource (US registered offenders), and explicitly defines two operation modes (location and name) with their respective parameter requirements. It distinguishes itself from the sibling get_crime_data by specifying this tool is only for registered-offender questions.

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 and names the alternative (get_crime_data for safety grades). It also specifies mode-specific requirements — location needs address or lat+lng, name needs at least one of first_name/last_name/dob — and states that location takes precedence when both are supplied. This is model guidance.

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

All DoorProfit Crime & Neighborhood Data tools Inspect

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.4/5.0

Disambiguation4/5

The four tools are largely distinct: crime/safety data, neighborhood demographics, offender search, and API usage. The descriptions explicitly cross-reference which tool to use for which question, reducing confusion. However, get_crime_data and search_offenders both relate to safety in a place, so an agent might briefly hesitate, though the boundary (risk grade vs. individuals) is clearly drawn in both descriptions.

Naming Consistency4/5

Three of four tools follow a consistent get_/search_ + noun pattern with get_crime_data and get_neighborhood_data being very parallel. search_offenders deviates slightly by using search_ instead of get_, and get_api_usage is a different resource type (meta/tooling), but these deviations are reasonable and readable.

Tool Count4/5

Four tools is a reasonable scope for a data-lookup server covering crime, demographics, offenders, and usage. It sits at the low end but each tool covers a distinct, large data domain with query options (location mode, name mode, pagination), so none feels trivial or like filler.

Completeness4/5

The surface covers the three main residential-data question types (crime/safety, demographics, registered offenders) plus API monitoring, which is a coherent set for a neighborhood-intelligence API. Minor gaps exist—e.g., no schools data despite being casually mentioned in get_crime_data's exclusion note, and no bulk/list or batch endpoints—but core workflows are fully covered.

Resources

Need Help?