listriver-mcp

Official

Overview Schema Source Related Servers Discussions Admin

search_businesses

Read-onlyIdempotent

Find US businesses matching location, industry, entity type, contact, and formation-date filters, then page through the results with a cursor.

Instructions

Get businesses matching the filters (same filters as count_businesses). USES THE USER'S RECORDS: each business returned counts, every time it is returned, so ask only for what the user needs.

Args:
    states: Comma-separated two-letter registration states. Required with city, county or zip.
    city: Comma-separated business cities.
    county: Comma-separated counties.
    zip: Comma-separated 5-digit ZIP codes or 3-digit prefixes.
    naics: Comma-separated NAICS prefixes, 2-6 digits.
    entity_type: Comma-separated of LLC, CORP, LP, LLP, NONPROFIT, OTHER.
    has_phone: Only businesses with a phone number on file.
    has_email: Only businesses with an email on file.
    formed_within: Formed in the current month or the N months before it (1 = this month or last; 0 = any date).
    formed_from: First formation month, "YYYY-MM".
    formed_to: Last formation month, "YYYY-MM".
    limit: How many businesses to return, 1-100 (default 25).
    cursor: The cursor from a previous search_businesses answer, to get the next businesses of the same search.

Input Schema

Name	Required	Description	Default
`zip`	No
`city`	No
`limit`	No
`naics`	No
`county`	No
`cursor`	No
`states`	No
`formed_to`	No
`has_email`	No
`has_phone`	No
`entity_type`	No
`formed_from`	No
`formed_within`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 3, 2026

TDQS

A4.6/5.0

Behavior4/5

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

The annotations already cover read-only, open-world, and idempotent behavior, but the description adds an important non-annotated trait: each returned business has a cost every time it is returned. It does not detail authentication, rate limits, or result ordering, though the output schema likely covers return shape.

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 definition is front-loaded with purpose and cost warning, then uses a clean Args list. Every line adds useful information, and no parameter documentation is wasted.

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 13-parameter search tool with an output schema and annotations, the description covers purpose, cost behavior, pagination, all filter semantics, defaults, and conditional requirements. Nothing critical for correct invocation is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full parameter burden, and it succeeds. It documents all 13 parameters with formats, comma-separation rules, NAICS digit lengths, allowed entity-type values, date formats, limit range, cursor meaning, and a conditional requirement for states with city/county/zip.

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 states a specific verb and resource: "Get businesses matching the filters." It also links to count_businesses via "same filters as count_businesses" and makes clear this tool returns actual businesses, distinguishing it from the counting sibling.

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?

The description gives clear usage context by warning that each returned business counts and advising the agent to ask only for what the user needs. It also explains the cursor for paging. It stops short of explicitly saying when to use count_businesses versus this tool, leaving that inference to the sibling relationship.

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

Deploy Server