Offendersearch

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

With no annotations, the description fully discloses behavior: row-by-row engine equivalence, error handling (status='error', never aborts batch), max rows, return format, and the crucial caveat about sourcesIncomplete meaning 'lower bound'. It also documents authentication via X-API-Key or env var. This is rich, transparent context.

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

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

The description is densely informative without fluff. The first sentence captures the core function, then proceeds logically: behavior, return format, caveat, auth. The use of bullets and the star-marked warning keep critical caveats prominent. Every sentence earns its place despite length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter tool with no output schema, the description covers all essential aspects: the input query format, return structure with counts and errors, error semantics, the lower-bound warning, authentication, and a pointer to search_offenders for shared parameter meanings. An agent can invoke it correctly and interpret results accurately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds significant semantic value: explains 'queries' as row-in/row-out with input order, enumerates allowed fields, and outlines result structure. It also interprets match/freshness/jurisdictions by referencing search_offenders for context. This goes well beyond the schema text.

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

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

Description opens with 'Run many person/lookup lookups in one call (row-in / row-out)', clearly stating the tool's verb, resource, and batching behavior. It explicitly distinguishes from siblings by noting 'same engine as search_offenders', making its niche unambiguous.

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

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

The description implies use for multiple lookups ('many... in one call') and references search_offenders as the single-query alternative, but does not explicitly say 'use this instead of search_offenders when you have multiple queries'. It provides constraints (max 1000 rows) but not a direct usage contrast.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries the full burden and does so: billing ($2 per 1,000, one request per call regardless of shape size), 24-hour id lifetime, the 403 map_not_enabled requirement, sandbox mode that bypasses the plan, and auth via X-API-Key. It also warns that a pin is a REGISTERED ADDRESS, not a current location, and that `areas` are ZIP/city-level placements that must not be described as exact spots.

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

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

Front-loaded with the purpose sentence and then organized by concern (return shape, marker semantics, billing, auth), so a reader can stop early. The inline Returns block is long but justified because no output schema exists; only minor duplication of the schema's zoom semantics keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter, zero-required geospatial query with no output schema and no annotations, the description fills every gap an agent needs: return structure, id/groupId semantics, placement caveats, cost, auth, and the one notable failure mode. Nothing required to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents zoom, polygon, route_points, buffer_miles and the rest; that sets the baseline at 3. The description adds only marginal parameter meaning beyond it — the detail-level mapping (clusters/pins/named pins at zoom 15+) and the route_points/buffer_miles pairing are both already stated in the schema text.

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

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

Opens with a specific verb and resource ('Get what to draw inside a drawn shape') and immediately scopes it to two shape types, polygon or buffered line. It explicitly contrasts itself with map_viewport ('the same answer ... limited to what is inside the shape'), so an agent can separate the two without reading either schema.

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

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

Routes the agent to the right sibling for each sub-case: map_group for a marker with id null plus groupId, map_open_record to see who one marker is, and map_route for exact per-leg/per-stop counts. It also states the polygon-vs-route_points mutual exclusion, leaving nothing to inference.

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

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

With no annotations, the description carries the full burden and does so: billing (one map request per page), credential binding and 24-hour expiry of group ids, and the auth mechanism (X-API-Key header or env var) are all disclosed. It also explains the conditional presence of `label` based on the source zoom level.

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

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

Front-loaded purpose sentence, then clearly labeled Returns/Billing/Auth blocks. The Returns block is verbose but justified since there is no output schema; every line carries operational information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a paginated read tool with no output schema and no annotations, the description supplies the return shape, pagination fields, billing cost, credential requirements, and id lifetime — everything an agent needs to invoke and chain it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by constraining group_id behavior (valid for 24 hours, only for the issuing account) and clarifying what `named: true` implies about returned labels.

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

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

States a specific verb and resource ('List the people behind a many-people pin or an approximate-area pin') and clearly distinguishes itself from siblings map_viewport/map_area/map_route, which produce the group ids it consumes.

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

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

Gives concrete follow-up routing ('Each member id opens with map_open_record') and a recovery path ('after that, call map_viewport again'), plus the 24-hour/account-bound lifetime condition. It stops short of an explicit when-to-prefer-this-over-X statement, but the group-id provenance is clear from context.

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

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

No annotations are provided, so the description carries the full burden, and it does: pricing ($0.035/open, account rate may differ), 24-hour marker expiry with 410 marker_expired, 410 record_no_longer_listed being unbilled, and X-API-Key auth. The only real gap is that it doesn't state rate limits or pagination-like concurrency behavior, but for a single-record fetch that is minor.

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

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

Front-loaded with purpose and return shape, then grouped under Returns/Billing/Auth labels with bullet sub-cases. It is long for a one-parameter tool, but nearly every sentence carries non-obvious billing or expiry semantics that an agent must know before calling.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates by spelling out the return envelope ({ record, recordRef, billing: { billed, unit, reason }, notice }), the error codes, the caching windows, and the auth header. Nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already documents the mk_/mr_ prefixes and their sources. The description goes beyond it by stating that marker ids expire after 24 hours while recordRef is 'a lasting reference', and by explaining free re-open semantics for each form.

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

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

Specific verb+resource: 'Open the complete record behind one map marker, or behind a saved reference.' It also anchors the returned object to a named sibling ('the same Record object search_offenders returns'), so an agent can distinguish it from map_viewport/map_area which return markers rather than records.

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

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

Explicit when/when-not guidance tied to cost: 'open a marker only when the user wants that person's record, not every marker in a view or along a route.' It further enumerates which situations constitute a new charge versus a free re-open.

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

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

With no annotations at all, the description carries the full burden and does so richly: billing formula with a worked example ($2/1,000, 22 units for a 17.4-mile/35-stop route), free test mode, auth via X-API-Key/OFFENDERSEARCH_API_KEY, that the call is all-or-nothing and failure is uncharged, the 422 route_too_many_people behavior, and that pins are nameless. The ethical constraints (registered addresses, not where anyone is; never call a route safe/unsafe; relay notice) are unusually valuable context.

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

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

The opening sentence and the measure explanation are front-loaded, and the billing/auth blocks are clearly quarantined at the end. It is long, and the full return-shape enumeration is dense, but with no output schema that enumeration is load-bearing rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter geospatial tool with no annotations and no output schema, the description supplies purpose, parameter semantics, a complete return shape, failure modes, billing, auth, and the cross-tool handoffs to map_group and map_open_record. Nothing an agent needs to call it correctly or interpret the answer is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so the baseline is 3, but the description goes beyond it: it clarifies that detail='count' costs the same as full, that measure defaults to both when stop_radius_feet is sent and corridor otherwise, and that profile bounds the corridor length and stop radius. It does not restate corridor_miles or parcel_allowance_feet semantics, but the added meaning is genuine.

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

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

Opens with a specific verb, resource and scope: 'Exact counts of registered addresses along one walking or bus route.' This pins the tool as a route-corridor counter, which separates it from area/vantage siblings like map_area and map_viewport, and the map_open_record cross-reference clarifies its boundary further.

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

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

Gives explicit condition-action pairs: use detail='count' or split the route when over 300 pins, call map_open_record only for markers the user actually asks about, and it explains profile/measure selection. It stops short of explicitly contrasting map_route with map_area or map_viewport for non-route geometries, so the sibling routing is implied rather than stated.

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

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

No annotations are provided, so the description carries the full burden and does so richly: per-call billing ($2/1,000), 24-hour id validity, the 403 map_not_enabled dependency and the sandbox bypass, the >300-pin downgrade rule, and the caveat that pins are registered addresses rather than current locations (reinforced by the `notice` field). This is far beyond a bare mutation/read disclosure.

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

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

Purpose is front-loaded in the first sentence, then structured into view-spec, zoom modes, return shape, and billing/auth sections with compact bullets. It is long, but nearly every line conveys actionable detail; only minor redundancy between the zoom bullet and the schema's own zoom description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter tool with no output schema and no annotations, the description fully compensates: it documents the response envelope field-by-field, the mode-dependent shape, the areas/unplaced edge cases, and auth/billing constraints. An agent has everything needed to call it and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds semantics the schema does not: the zoom-to-mode mapping table, the radius-mode return differences, and especially the >300-pin clustering override. It also explains how to interpret `id: null` markers with a `groupId`, which is behavioral meaning layered on the parameters.

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

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

States a specific verb and resource ('Get what to draw for one map view') and immediately enumerates the three output modes (clusters, pins, named pins). It also names siblings map_group and map_open_record in the context where they apply, so an agent can distinguish this tool from the family without opening a schema.

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

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

Gives two mutually-exclusive ways to specify the view (bbox OR lat+lng+radius_miles) and routes sub-cases to siblings ('call map_group with that groupId', 'call map_open_record with its id'). It lacks an explicit when-not-this-tool statement against siblings like map_area or map_route, but the context needed to invoke correctly is present.

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

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

With no annotations, the description assumes the full disclosure burden and does it well: it defines what each recordType implies, warns that bookings are not convictions, that warrants mean 'SOUGHT', and attaches FCRA restrictions. It even instructs the agent to read recordType before characterizing anyone. This is far beyond the minimum.

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

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

The description is long but front-loaded with the core purpose and organized into readable paragraphs; the surname/recordType/FCRA guidance is all substantive. A few phrases, like the federal-layer explanation, are useful context rather than waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, it documents the returned record fields (name, aliases, dob, sex, race, state, county, custody, sentence, cases, sources, matchConfidence/matchBasis) and the pagination counts. It covers search behavior, caveats, and legal constraints, leaving the agent enough to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema already describes all 8 parameters, so baseline is 3; the description adds real value by explaining that surname is non-optional, that firstName + DOB or birthYear strengthen matching, and that a common surname yields thousands of results. It also calls DOB 'the single strongest disambiguator,' which is not in the schema.

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

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

Opens with a clear verb and resource: "Search US criminal records" and enumerates county jail bookings, prison custody, court cases, and warrants. Scope is unambiguous, but it never explicitly distinguishes itself from the sibling search_offenders or tells the agent which searches are excluded, so sibling differentiation is absent.

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

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

It gives explicit invocation guidance — 'A surname is REQUIRED' and advises supplying firstName plus DOB/birth year 'wherever you have them' — and explains why (bare common surnames return thousands). It doesn't state when to prefer a sibling tool like search_offenders, so no exclusions/alternatives are provided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure and meets it thoroughly. It reveals that results may be partial, that counts.sourcesIncomplete makes records a lower bound, that warnings are always present, and that registries can fail without invalidating the search. It also exposes the auth mechanism and the difference between light and extensive calls.

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

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

The description is long but well-organized: a one-line summary, then fan-out behavior, a clear warning section, a structured return-field list, and an auth note. Critical operational guidance (read sourcesIncomplete before reporting) is highlighted early and in plain language. Every section earns its place given the 18-parameter surface and absence of an output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 18-parameter read tool with no output schema, the description is remarkably complete. It documents the response structure, per-source status fields, cache tiers, geo-search behavior, jurisdiction control, and the crucial lower-bound caveat. An agent has enough context to call it correctly and interpret its results without additional documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds substantial meaning beyond field names and types. It clarifies subtle behaviors such as `state` being a residence filter that does not change which registries run, `location_scoped` being an opt-in recall-reducing knob, `match` levels affecting fuzzy tolerance, and `deadline_ms` causing partial results. This materially improves an agent's ability to choose correct parameter combinations.

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

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: 'Search US sex-offender registries for one person and/or location.' It goes beyond a vague summary by explaining the fan-out, de-duplication, scoring, and normalized record output. The resource is clearly distinct from siblings like search_criminal at a glance.

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

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

The description gives clear guidance on when to call the tool: when searching sex-offender registries, and it explains what identifiers to supply ('at least a name, location, or free-text q should be given'). It also references get_registry_coverage for registry codes, pointing the agent to the right companion tool. It does not explicitly contrast with search_criminal or batch_search, but the resource scope makes the primary context clear.

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