Search 128 million official company registrations across every US state, DC, Puerto Rico and Canada.
Scored across 4 tools
Each tool serves a clearly distinct function: one documents the API, one provides query taxonomy, one handles registration, and one performs company search. There is no overlap or ambiguous boundary between them, making tool selection straightforward for an agent.
All tool names follow a consistent verb_noun snake_case pattern: get_site_info, list_jurisdictions, register_agent, search_companies. This creates a predictable structure where the verb indicates the action and the noun indicates the target.
Four tools is an appropriate size for this server's scope—it provides the necessary setup, metadata, authentication, and primary search functionality without redundancy. Each tool addresses a distinct step in the workflow, so none feel extraneous.
The set covers the core search workflow well, from learning about the API and query vocabulary to registering and executing searches. However, it lacks a direct company detail lookup and a credit balance check, which are minor gaps for a data-focused server.
What Netstate is, its pricing plans, API endpoints, FAQ and usage restrictions. Call this to learn what the site offers before using the data tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses that the tool provides information about pricing, endpoints, FAQ, and restrictions, which is useful behavioral context. However, it doesn't state the format of the response (e.g., plain text, structured), or whether it makes external calls or is just static documentation. It could be more transparent about what 'info' entails.
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 that is concise and front-loaded with the core purpose. It lists key content areas and gives a clear directive for usage. No wasted words.
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 tool with no parameters and no output schema, the description is fairly complete. It covers what the tool does and when to use it. The only minor gap is the lack of detail on the return format, but given the simplicity, it's adequate.
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, and schema coverage is 100% (no properties). The description adds value by indicating what information will be returned, which is enough for a no-parameter tool. Since there are no parameters to document, a baseline of 4 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?
The description clearly states the tool's purpose: to learn about Netstate's offerings including pricing, API endpoints, FAQ, and usage restrictions. It uses a specific verb 'learn' and resource 'the site offers.' It doesn't explicitly differentiate from siblings, but it is clear what it does.
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 explicitly instructs to call this before using the data tools, giving clear usage context. It doesn't explicitly mention alternatives, but the siblings are data tools and this is a precursor, so the routing is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The taxonomy for building queries: countries with regions (and cities when a country+region is given), industries, statuses, and total company count. Call this first to find valid slugs for the other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Also list the cities of this region (requires country) | |
| country | No | Limit to one country slug |
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. It discloses the conditional output behavior (cities only when a country+region is given) and enumerates response content including total company count. It doesn't explicitly state safety traits like read-only status, but for a taxonomy listing tool the disclosed behavior is solid.
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 sentences with no filler; the taxonomy role is front-loaded and the actionable sequencing advice is placed at the end. Every phrase earns its place.
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 two-optional-param listing tool with no output schema or annotations, the description covers the return content (countries, regions, cities, industries, statuses, company count) and the conditional drill-down behavior. The only gap is the exact response structure, which is minor for a taxonomy list.
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 both parameters are already documented and the baseline is 3. The description adds some context by tying region/country to the taxonomy hierarchy (cities require country+region), but it doesn't add format or syntax details beyond what the schema provides.
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 clearly and specifically defines the tool as the query-building taxonomy: countries with regions (and cities when country+region is given), industries, statuses, and total company count. The line 'Call this first to find valid slugs for the other tools' distinguishes its role from siblings like search_companies and get_site_info.
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 sequencing guidance—'Call this first to find valid slugs for the other tools'—telling the agent this is a prerequisite for the other query tools. It doesn't name when-not-to-use alternatives, but the context for when to invoke it is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Self-register as an agent and receive a working Netstate API key in the response — no human step. The key authenticates the REST API at /v1: send it as the x-api-key header. Search and taxonomy are free; premium endpoints (e.g. court records) spend 1 credit per company and need a paid plan (from $15/mo, see /pricing) — new keys start with no credits. Idempotent per email: registering the same email again returns a fresh key.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Contact email for the agent's account | ||
| agent_name | No | A name identifying your agent (optional, for your own reference) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the sparse readOnlyHint=false annotation by disclosing the full side-effect profile: it registers an account, returns a working key, is idempotent per email though each call returns a fresh key, and new keys start with zero credits. It also states how the key is used (x-api-key header at /v1). No contradiction with annotations.
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?
Three dense sentences, front-loaded with the core purpose and followed by only high-value behavioral details (authentication, pricing/credits, idempotency). No filler or redundant restatement of the input 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?
Despite having no output schema, the description tells the agent what to expect (a working API key), how to use it (x-api-key header), and what side effects to anticipate (idempotent but fresh key, no starting credits). Nothing needed to call the tool 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 both email and agent_name. The description adds context for email by stating the idempotency behavior (same email returns a fresh key), which enriches parameter understanding without repeating schema details.
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 an explicit verb/resource pair ('Self-register as an agent and receive a working Netstate API key') and clearly differentiates from sibling tools, none of which perform registration. The title matches the action, leaving no ambiguity about what the tool accomplishes.
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?
Provides clear context: this is the self-service way to obtain the key needed for the REST API, with no human step. It does not explicitly enumerate when-not-to-use or compare with siblings, but the sibling tools are unrelated read/list/search operations, so no exclusion is necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across 128 million registered companies in official US and Canadian state registers — by legal name, officer or director name, phone number, email or website. Contact-shaped queries (phone/email/website) resolve through the official records carrying that exact value; the response's matched_by field says which channel matched. Filters mirror the website's facet rail; the response carries up to 25 matching profiles plus facet counts. Facet counts describe every name match (not just the filtered set), so they show which filter values would widen or narrow the search. Records are for human review — not for automated decisions covered by the FCRA.
| Name | Required | Description | Default |
|---|---|---|---|
| has | No | Only companies with this data on file (multi-select) | |
| sort | No | Result order | |
| type | No | Entity type | |
| year | No | Formation decade | |
| naics | No | Two-digit NAICS sector | |
| query | Yes | Company name or name fragment, an officer/director name, or an exact phone number, email or website | |
| state | No | Registration jurisdiction slug: "us-" or "ca-" plus the two-letter state/province code, e.g. "us-ca", "us-de", "ca-on" | |
| status | No | Registry status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and handles it well. It explains exact-contact matching, the matched_by response field, the 25-profile result cap, facet count semantics, and the FCRA restriction for human review only.
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?
Every sentence earns its place: scope, query behavior, response shape, facet behavior, and legal limitation are packed into a compact, front-loaded description with no filler.
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 search tool with no output schema, the description covers query semantics, response fields, filter behavior, and a critical legal constraint. An agent has everything needed to invoke the tool correctly and interpret results.
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 meaningful semantic detail: query can be a name fragment or exact contact value, contact-shaped queries resolve via exact official records, and filters mirror the website's facet rail. This goes beyond the schema without fully unpacking every parameter.
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: full-text search across 128 million registered companies in US and Canadian registers. It lists the query dimensions (legal name, officer, phone, email, website), which clearly differentiates it from sibling tools like register_agent and list_jurisdictions.
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 context for when to use this tool: anytime a company search by name, officer, or contact value is needed. It does not explicitly name alternatives or exclusion conditions, but the sibling tools are functionally distinct enough that an agent can make the correct choice from context.
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.
get_site_infolist_jurisdictionsregister_agentsearch_companies
Add one secure layer between your agents and this server.