Skip to main content
Glama
Sign In
listriver-mcp

listriver-mcp

Official
by ListRiver-LLC
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

count_businesses

Read-onlyIdempotent

Count businesses by state with filters for city, county, ZIP, NAICS, entity type, phone, email, and formation date before running a full search.

Instructions

Count businesses matching the filters, per state. Free: use it before search_businesses.

Args:
    states: Comma-separated two-letter registration states, e.g. "FL" or "FL,TX". Required with city, county or zip.
    city: Comma-separated business cities, e.g. "MIAMI".
    county: Comma-separated counties, e.g. "MIAMI-DADE" (or "FL:MIAMI-DADE").
    zip: Comma-separated 5-digit ZIP codes or 3-digit ZIP prefixes, e.g. "33139,331".
    naics: Comma-separated NAICS prefixes, 2-6 digits, e.g. "23" (construction) or "722511".
    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). Set 0 for any formation date.
    formed_from: First formation month, "YYYY-MM" (overrides formed_within).
    formed_to: Last formation month, "YYYY-MM" (overrides formed_within).

Input Schema

NameRequiredDescriptionDefault
zipNo
cityNo
naicsNo
countyNo
statesNo
formed_toNo
has_emailNo
has_phoneNo
entity_typeNo
formed_fromNo
formed_withinNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds genuinely new context: the call is free (cost signal that shapes call ordering) and results are grouped per state. It does not discuss rate limits or what a zero-match response looks like, but the output schema 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.

Conciseness4/5

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

The purpose and the cost-based routing rule are front-loaded in a single sentence, then the args list follows. The arg block is long but every line carries format or default information absent from the schema, so there is little waste; the one sloppy phrase ("Comma-separated of LLC...") is minor.

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

Completeness4/5

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

For an 11-parameter tool with zero schema descriptions, the definition covers every parameter, the default for formed_within, and the cross-parameter dependency. With an output schema present it need not explain return values, though it could say whether states-less calls are legal (all params optional) or what happens when no filters are given.

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 burden and does so for all 11 parameters: formats (two-letter states, 5-digit or 3-digit ZIP prefixes, 2-6 digit NAICS), worked examples, entity_type vocabulary, and the boolean filters. It also states non-obvious interaction rules the schema cannot express — formed_from/formed_to override formed_within, and states is required when city, county or zip is supplied.

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?

States a specific verb and resource plus the aggregation scope: "Count businesses matching the filters, per state." It also names the sibling it precedes (search_businesses), so an agent can distinguish it from both siblings without opening either schema.

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?

Explicit routing rule with a rationale: "Free: use it before search_businesses," which tells the agent to cheaply size a result set before running the costlier search. It names the alternative but gives no explicit when-not condition or guidance on choosing between list_states and this tool.

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

Deploy Server

Other Tools