Official U.S. business-registry data and change events for agents. Search companies, read their change history, and subscribe to changes across seven states. Bearer API key, paid plans from $200/month.
Homepage: https://recordwirehq.com/mcp Category: Data / Business data Auth: API key (Authorization: Bearer YOUR_API_KEY) Contact: brian@recordwirehq.com
Scored across 8 tools
Most tools have clearly distinct purposes: business lookup vs search, events for a specific business vs global event search, and subscription management. The two event tools (get_business_events and search_events) have some potential overlap since search_events also surfaces business IDs and event types, but the distinction between scoped retrieval and general search is inferable.
All tool names follow a consistent snake_case verb_noun pattern: create_subscription, delete_subscription, get_business, get_business_events, list_sources, list_subscriptions, search_businesses, search_events. There are no deviations or mixed conventions.
Eight tools is well-scoped for a business registry and event subscription API. Each tool earns its place: read/search businesses and events, list sources, and manage subscriptions without redundancy.
The surface covers core read, search, and subscription lifecycle operations (create, delete, list), which is sufficient for most workflows. Minor gaps exist: no update_subscription (e.g., to change endpoint or secret rotation) and no get_subscription for single-subscription details, though workarounds like delete-and-recreate are possible.
Subscribe an HTTPS endpoint to new registry changes. Save the returned secret; it is shown once.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| name | Yes | ||
| entity_ids | No | ||
| event_types | No | ||
| jurisdictions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses one important trait — the returned secret is shown only once and must be saved — but omits auth/permission requirements, whether the endpoint is verified, idempotency, URL validation rules, and limits like the maxItems constraints present in the schema.
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?
Two tight sentences with the action front-loaded and the retention warning right after it. No filler, and every clause carries 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 5-parameter creation tool with no annotations, no output schema, and zero schema description coverage, the description is too thin. It handles the return-secret aspect but leaves the agent without any guidance on the filter parameters (entity_ids, event_types, jurisdictions) that define what the subscription actually receives.
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?
Five parameters exist with 0% schema description coverage, yet the description explains none of them (name, url, entity_ids, event_types, jurisdictions). The phrase 'HTTPS endpoint' adds a marginal constraint beyond the schema's plain uri format, but everything else is undocumented in both places.
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 (subscribe) and resource (an HTTPS endpoint receiving registry changes), making the create action unambiguous against siblings like delete_subscription and list_subscriptions. It does not explicitly name a sibling, but the resource and verb are concrete enough to distinguish it.
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?
There is no explicit when-to-use or when-not-to-use guidance; the purpose implies usage but nothing tells the agent whether this is the right tool versus list_subscriptions or how it relates to existing subscriptions. The one operational hint is the directive to save the returned secret.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Revoke your subscription.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. "Revoke" ambiguously suggests either a reversible deactivation or a permanent deletion, and the description says nothing about reversibility, billing impact, permission requirements, or side effects for a destructive operation.
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?
A single short sentence is efficient and front-loaded, but the brevity here reflects under-specification rather than tight, information-dense writing.
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 destructive, single-parameter tool with no annotations and no output schema, the description omits reversibility, required permissions, and parameter meaning. An agent cannot safely invoke this based on the description alone.
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 0% for the single required parameter "id", so the description must compensate and does not. It never explains what identifier is expected (subscription id vs. business id) or its format, leaving the one parameter effectively undocumented.
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?
"Revoke your subscription" gives a verb and a resource, and "revoke" hints at the semantics (deactivate vs. permanent delete). However, it largely restates the tool name and does nothing to distinguish itself from siblings like create_subscription or list_subscriptions beyond the obvious opposite action.
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?
No guidance on when to use this versus alternatives, no prerequisites, and no stated constraints. The agent gets no signal about what condition should trigger revocation or what happens afterward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns one business by an ID like US-VA:11406679, with dates in YYYY-MM-DD format.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It discloses the date format convention, which is mildly useful, but says nothing about read-only nature, error behavior for unknown IDs, or authentication requirements.
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?
A single tight sentence with no filler, front-loading the core action and resource. Nothing extraneous is included.
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 one-parameter lookup with no annotations and no output schema, the description covers the ID format adequately, but the missing output-shape detail (since no output schema exists) and absent usage guidance leave gaps an agent would need to resolve.
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 0% and the schema only names the parameter 'id' with type string, so the description's example ID format ('US-VA:11406679') is genuinely value-adding. The date-format note also adds meaning beyond the bare 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?
States a specific verb ('Returns') and resource ('business'), and identifies the lookup key (ID). It does not differentiate itself from the similarly named sibling search_businesses, leaving the retrieval-vs-search distinction implicit.
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?
No when-to-use guidance, no mention of when to prefer search_businesses over this single-record fetch, and no prerequisites or error conditions. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns events for a business ID like US-VA:11406679; dates use YYYY-MM-DD and next_cursor pages through more results.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| limit | No | ||
| cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose two useful traits — cursor-based pagination via next_cursor and the date format — but says nothing about permissions, result volume, ordering, or error behavior for a read tool.
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?
A single tight sentence with the primary purpose front-loaded, followed by format and pagination details. Nothing is padded, though cramming three distinct points into one clause chain reduces readability.
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?
No output schema and no annotations mean the description is the only source of context. It covers the id format and paging but omits limit semantics and any hint at the returned event shape or ordering, leaving meaningful gaps for a 3-parameter tool.
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 0%, so the description must compensate. It usefully explains the id format ('US-VA:11406679') and the cursor's paging role, but leaves 'limit' entirely undocumented and references 'dates use YYYY-MM-DD' when no date parameter exists in the schema, which may confuse the parameter mapping.
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+resource ('Returns events for a business ID') and even gives a concrete ID format example, so the agent knows exactly what this retrieves. It does not explicitly differentiate itself from the sibling search_events, so it falls short of a 5.
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?
No guidance on when to use this versus search_events or get_business, and no prerequisites or exclusions stated. Pagination is mentioned but that is behavior, not usage selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns available registry sources and their latest verified YYYY-MM-DD dates.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It does convey that this is a non-destructive listing and that dates are 'verified', implying freshness semantics, but it says nothing about auth requirements, rate limits, ordering, or whether results are paginated.
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?
A single front-loaded sentence with no filler; the return content and date format are packed into one clause.
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 read tool with no output schema, the description adequately states what comes back and the date format. It is slightly thin on ordering and whether the list is exhaustive, but nothing essential to correct invocation 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 tool takes zero parameters, so there is nothing to misinterpret and schema coverage is trivially complete. Baseline 4 applies.
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?
Clear verb ('Returns') plus a specific resource ('available registry sources') and a qualifier on the payload (latest verified YYYY-MM-DD dates). It does not need sibling disambiguation since the sibling set (subscriptions, businesses, events) covers a different surface.
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?
No indication of when an agent should call this versus search_businesses or list_subscriptions, and no prerequisites or exclusions are given. The usage is only implied by the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your subscriptions without signing secrets.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does disclose one non-obvious behavioral trait: signing secrets are deliberately excluded from the result. It is silent on auth requirements, pagination, and ordering, and 'without signing secrets' is grammatically ambiguous between response redaction and an auth requirement.
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?
A single short sentence with the operation front-loaded and no filler. Nothing could be trimmed without losing content.
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 parameterless, annotation-free read tool with no output schema, the description should at least sketch the returned shape and auth expectations. It hints at result content by ruling out secrets but leaves the subscription payload and any access requirements unstated.
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 schema declares zero parameters, so there is nothing for the description to disambiguate. The baseline for a parameterless tool applies, and the description correctly avoids inventing filter arguments.
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 your subscriptions'), which cleanly pairs with the read-side versus the sibling create_subscription and delete_subscription. However, it never names those siblings or narrows the scope (all subscriptions? mine only?), so differentiation is implied rather than explicit.
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?
There is no when-to-use guidance, no mention of alternatives such as create_subscription/delete_subscription, and no preconditions. The agent must infer from the name alone that this is the enumeration counterpart to the mutation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns matching businesses; IDs look like US-VA:11406679, dates use YYYY-MM-DD, and next_cursor pages through more results.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| limit | No | ||
| cursor | No | ||
| status | No | ||
| entity_type | No | ||
| formed_after | No | ||
| jurisdiction | No | ||
| formed_before | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses pagination via next_cursor, ID format (US-VA:11406679), and date format (YYYY-MM-DD), which are useful behavioral details beyond the schema. However, it omits other important behaviors like authentication needs, rate limits, or whether results are read-only, so it is only moderately transparent.
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 a single sentence with no wasted words and the core purpose is front-loaded. However, it crams purpose, ID format, date format, and pagination into one run-on clause, which slightly reduces readability. It is still appropriately sized for the information provided.
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 search tool with 8 parameters, no required parameters, no output schema, and no annotations, the description is far from complete. It lacks explanations of most filter parameters, does not describe return fields beyond ID format, and provides no guidance on result structure or usage context. It is insufficient for an agent to invoke the tool confidently.
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 0%, so the description must compensate for all 8 parameters. It only addresses cursor (via next_cursor) and date parameters (via YYYY-MM-DD), and hints at ID format for jurisdiction. Parameters q, limit, status, and entity_type are left completely unexplained, making the parameter semantics inadequate.
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 states the tool returns matching businesses, which is essentially a restatement of the name search_businesses. It adds 'matching' as a scope hint, but does not clarify what criteria are used or differentiate it from a generic list operation. The first clause is borderline tautological, so a 3 is appropriate.
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?
There is no guidance on when to use this tool versus alternatives such as get_business or search_events. No context, prerequisites, or exclusions are provided. The description merely states what it returns, leaving usage entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns business.created, business.name_changed, business.status_changed, business.address_changed, business.agent_changed, or business.officers_changed events; dates use YYYY-MM-DD, business IDs look like US-VA:11406679, and next_cursor pages through more results.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| limit | No | ||
| since | No | ||
| until | No | ||
| cursor | No | ||
| jurisdiction | No | ||
| observed_since | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses pagination behavior ('next_cursor pages through more results') and value formats, but says nothing about auth requirements, result limits, or how the seven filters combine.
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?
A single semicolon-delimited sentence that is front-loaded with the event types. It is efficient, though the run-on structure makes it slightly hard to scan for a specific parameter's meaning.
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 7-parameter tool with no annotations and no output schema, the description leaves several parameters and the interaction between filters explained nowhere. An agent can guess the happy path but not configure jurisdiction, limit, or observed_since 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 coverage is 0%, so the description must compensate. It explains the date format (covering since/until/observed_since), the business ID format, and cursor paging, and the event-type list implicitly defines the 'type' values—but limit, jurisdiction, and the distinction between observed_since and since are undocumented.
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?
It states the specific resource (business events) and enumerates the exact event types returned, which is concrete. However, it doesn't distinguish this search from the sibling get_business_events, so an agent cannot tell them apart from the description alone.
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?
There is no guidance on when to use search_events versus get_business_events or search_businesses. The presence of a sibling returning events makes this omission notable; the agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_subscriptiondelete_subscriptionget_businessget_business_eventslist_sourceslist_subscriptionssearch_businessessearch_events
