Confirm a US business is real and find who controls it. 32.6M official registry records.
Get business age distribution — how many entities are 0-4, 5-9, 10-14, 15-19, 20-29, 30-39, 40+ years old. Optionally filter by state.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Filter by state: FL, NY |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. The description does convey that this is a read/aggregation operation (computing distributions), which implies non-destructive behavior. However, it doesn't disclose details like whether entities with unknown/zero age are excluded, how the state filter interacts with the default national scope, or whether results include totals. Basic but not rich behavioral 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 a single efficient sentence that loads the core purpose (age distribution for entities) and bucket ranges, then adds the optional filter in a second clause. It's compact with no wasted words, though the explicit bucket enumeration slightly lengthens it—justified by being essential context the agent needs.
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?
The tool is simple (1 optional param, no output schema), so the description covers the key inputs and purpose. However, for an aggregation tool like this, the absence of any description of the output shape (e.g., does it return counts per bucket, percentages?) is a gap, since there's no output schema to fill that in. The age bucket definition is provided, which is helpful, but output semantics are unclear.
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%, with the state parameter documented as 'Filter by state: FL, NY'. The description reinforces this by mentioning the optional state filter and lists the two valid states. However, it doesn't clarify whether omitting state implies nationwide aggregation or a default state, so the description adds marginal value beyond 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?
The description clearly states the tool aggregates age/business-age distribution for entities, listing specific bucket ranges. It distinguishes itself from siblings (e.g., private_type_breakdown and private_geography) by focusing on age cohorts. However, it doesn't explicitly contrast its scope against private_type_breakdown's type-based breakdown, 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?
The description says to optionally filter by state, providing usage context. It doesn't explicitly state when to choose this over alternatives like private_stats or private_type_breakdown, nor does it mention any prerequisites or states beyond FL/NY. The intended use is reasonably implied but lacks explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a list of companies matching criteria rather than looking one up: state, industry (NAICS), entity type, age, city, ZIP. Use it for prospecting, market sizing, or finding every business of a kind in a place. Ask for an industry with the naics filter — 23 is construction, 238 specialty trades, 238160 roofing.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | ZIP code prefix | |
| city | No | City name (partial match) | |
| type | No | Entity type: domestic_profit, domestic_llc, domestic_lp, foreign_profit | |
| limit | No | Max results (default 25) | |
| state | No | Two-letter state code, e.g. FL, NY, CA, TX | |
| county | No | County (NY only) | |
| offset | No | Pagination offset | |
| max_age | No | Maximum business age in years | |
| min_age | No | Minimum business age in years |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It conveys that this is a list-building/read operation (prospecting, market sizing), which implies non-destructive behavior, and discloses the filtering nature. However, it doesn't describe output format, pagination/limit behavior, or any rate-limit/auth constraints. For a read-oriented search tool, the disclosure is adequate but not rich.
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 sentences, zero filler, front-loaded with the core purpose first. The NAICS example is valuable but could be considered slightly tangential to the main filter list; still, it earns its place by clarifying how to use the industry filter. Efficient and well-structured.
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 9 optional parameters and no output schema, the description covers the primary use cases clearly. It would benefit from mentioning the county parameter's constraint (NY only) which is already in the schema, and from describing what a result row looks like. However, for a filtering/search tool with fully documented parameters, the description covers the essential decision-making context well.
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 fully documents all 9 parameters. The description adds a concrete NAICS example that enriches the semantics of the industry filter even though no explicit naics parameter appears in the schema. This example adds value beyond the schema, but much of the parameters' meaning is already in the schema, so baseline 3 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 'Build a list of companies matching criteria rather than looking one up,' with a specific verb and resource. It lists the filter dimensions (state, industry/NAICS, entity type, age, city, ZIP) and explicitly distinguishes itself from a single-record lookup, differentiating it from siblings like private_entity and private_search.
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 when-to-use context: 'prospecting, market sizing, or finding every business of a kind in a place.' It explicitly names the alternative behavior ('rather than looking one up') and even provides a concrete NAICS usage example (23 construction, 238 specialty trades, 238160 roofing). It doesn't explicitly name a sibling tool to use instead for single lookups, but the contrast is clear. Minor deduction for not naming the alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the chief executive, president, chairman or manager behind a company, or find every company a named executive runs. Use when the question is "who is actually in charge here" rather than "does this company exist". Restricted to executive-level titles; use private_officer_search for any role including directors and secretaries.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | CEO/president name to search | |
| limit | No | Max results (default 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the title-level restriction and bidirectional search capability, but does not mention whether this is a read-only operation, rate limits, auth requirements, or result ordering behavior. The disclosed scope restriction adds value but the safety/profile details are absent.
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 sentences, all substantive. Front-loaded purpose, explicit usage context, and boundary declaration in the final sentence. Zero filler or redundancy.
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 2-parameter tool with no output schema and no annotations, the description moderately compensates by covering purpose, scope boundaries, and an alternative tool. The bidirectional reverse-search capability in the 'when to use' line hints at parameter semantics. Slightly more return-format detail would push it higher, but it's reasonably complete for a search 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 100%, so the schema already documents both parameters ('CEO/president name to search' and 'Max results'). The description's 'bidirectional' nature (find executive for company OR find companies for executive) adds context about how the name parameter is used, but this interpretation is somewhat ambiguous given a single name 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?
Uses a specific verb 'Find' with a clear subject (chief executive, president, chairman, manager) and resource (company/executive reverse lookup). Explicitly distinguishes the 'who is in charge' use case from the 'does this company exist' use case, which differentiates it from private_search/private_entity siblings.
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 explicit 'Use when' guidance ('who is actually in charge here' vs 'does this company exist'). Clearly states scope restriction ('Restricted to executive-level titles') and names the alternative tool for broader role coverage ('use private_officer_search for any role including directors and secretaries').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
You have already identified a company and now need the full official record: current status, incorporation date, EIN, registered agent, every officer with their role, addresses, and filing history. This is the record a state government actually holds, so use it to settle questions that web sources disagree about — mirrors frequently report stale status or the wrong registered agent.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter state code, e.g. FL, NY, CA, TX | |
| state_id | Yes | State entity ID (FL: Corporation Number, NY: DOS ID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this returns the authoritative government record and explicitly warns about the data-quality context (mirrors report stale status or wrong registered agent). However, it doesn't specify return format, whether the record could be empty/missing, or any latency/auth constraints. For a read-only lookup tool with no annotations, this is reasonably transparent but could add more edge-case behavior.
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 well-organized sentences with zero waste. The first sentence enumerates the authoritative content, and the second justifies when to reach for this tool. Every clause earns its place, and the most important information (what it returns) is front-loaded.
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 simple 2-parameter lookup tool with 100% schema coverage, the description is complete. It tells the agent what it gets back, why the official record matters (authority to settle disputes), and when to use it relative to web sources. The output schema absence is compensated by listing the full contents in the description. Sibling differentiation is handled.
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 (state and state_id) are already documented in the schema with format examples. The description adds the semantic context that these are the identifiers the state government uses, with concrete examples of state_id formats. This exceeds the baseline but doesn't add materially beyond what the schema conveys.
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 returns 'the full official record' with specific enumerated contents: current status, incorporation date, EIN, registered agent, officers, addresses, and filing history. It explicitly identifies the resource (official state record) and distinguishes its purpose from web sources. This differentiates it well from the sibling tools which focus on aggregates (age_distribution, geography, stats) and searches.
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 opens with 'You have already identified a company,' which explicitly frames when this tool should be used (after identification, likely after private_resolve or private_search). It also gives clear when-not context: it should be used to 'settle questions that web sources disagree about' and to correct stale mirrors. This is strong contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Geographic distribution of private businesses. Group by city, zip, county, or state. Shows where businesses are concentrated.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Top N locations (default 30) | |
| state | No | Filter by state | |
| group_by | No | Group by: city, zip, county, state | city |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The description tells us it produces a 'geographic distribution' and 'shows where businesses are concentrated,' implying it aggregates/counts. However, it doesn't disclose what 'distribution' means exactly (counts, percentages), whether filtering applies to results or just which businesses are included, or the return format. For a read-only analytical tool this is borderline adequate but lacks specifics.
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, zero waste. The first sentence states the resource and grouping dimensions; the second clarifies the analytical value. Every word 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?
This tool has zero annotations, no output schema, and a compact 3-parameter schema. Given it's an analytical aggregation tool, the description should clarify what the output looks like and how group_by+state interact. It's functional but doesn't fully specify behavior—e.g., whether limit applies per group or total, or how results are ordered (top N implies descending by concentration).
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 all three parameters are documented in the input schema (group_by with its four enum-like values, state filter, limit defaulting to 30). The description adds the grouping dimension by naming the values, but doesn't add meaning beyond what the schema already provides. Baseline 3 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 states the tool shows geographic distribution and grouping options (city, zip, county, state), with a clear verb-resource combination. It doesn't explicitly distinguish from sibling tools like private_type_breakdown, but the geographic dimension is clear.
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 explicit guidance on when to use this tool vs. alternatives. The description implies it's for geographic concentration analysis, but doesn't name alternative tools or exclude cases. The text mentions it shows 'where businesses are concentrated' which gives some context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find which companies a named person is an officer, director or registered agent of. Use it to check whether a counterparty is who they claim, to map the other entities behind one operator, or to find every company a person controls before signing with any of them. Covers 21.2M officer records.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Officer/CEO name or partial name | |
| limit | No | Max results (default 25) | |
| state | No | Two-letter state code, e.g. FL, NY, CA, TX | |
| title | No | Filter by title: ceo, president, director, secretary, treasurer, vp, chairman, manager |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses data coverage (21.2M officer records) and the three role types searched, adding substantive behavioral context. It doesn't describe return format or pagination, but the coverage detail is meaningful. A 4 is appropriate since it goes beyond the schema without being exhaustive.
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 sentences, front-loaded with the core purpose, followed by concrete use cases and a data scale stat. No wasted words, though the use-case list is slightly repetitive in intent. Efficient and well-ordered.
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 read-only lookup tool with 100% schema coverage and no output schema, the description provides purpose, use cases, and coverage scale. It's adequate for a search tool of this nature, though it could mention result ordering or the limit param behavior beyond the schema.
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 input schema fully documents all 4 parameters. The description mentions 'named person' aligning with the name parameter and the three role types, but adds little beyond what the schema provides. Baseline 3 is correct since the schema carries the load.
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 uses a specific verb+resource ('Find which companies a named person is an officer, director or registered agent of') and clearly delineates the function from siblings like private_ceo_search (which narrows to CEO titles). It enumerates the three role types it covers, making the scope precise.
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 explicit use cases: checking if a counterparty is who they claim, mapping other entities behind one operator, and finding all companies a person controls before signing. These are concrete when-to-use scenarios. It doesn't explicitly name alternatives/exclusions, but given the sibling context (ceo_search, entity, resolve), the use cases distinguish it well.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find businesses where an officer is also the registered agent — the filing lists the same person in both roles. This is a succession and acquisition signal: it usually means an owner-operated company with no management layer. Use it to build acquisition target lists or to judge whether a supplier depends on one person. It indicates what the filing says, not legal ownership or control.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City filter | |
| type | No | Entity type filter | |
| limit | No | Max results (default 50) | |
| state | No | Two-letter state code, e.g. FL, NY, CA, TX | |
| offset | No | Pagination offset | |
| min_age | No | Minimum business age (default 15) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations (no readOnlyHint, destructiveHint, etc.), the description carries the burden. It notably cautions that the result 'indicates what the filing says, not legal ownership or control' — a useful caveat clarifying that outputs are filing-based, not authoritative legal facts. However, it doesn't mention pagination behavior, rate limits, or result characteristics beyond the caveat, so it's adequate but not rich.
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 tight three-sentence block: what it does, why it matters, and a disambiguation caveat. Every sentence earns its place — no filler, no redundancy with the schema. The interpretive framing is front-loaded and the caveat is a valuable closing note.
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?
With no output schema and no annotations, the description carries significant weight. It covers purpose, use cases, and the key interpretive caveat (filing-based, not legal ownership). For a filter-type tool with 6 well-documented parameters, this is reasonably complete; the main gap is not describing expected return structure or size, but the caveat about data meaning compensates well.
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% with all 6 parameters documented inline, so baseline is 3. The description meaningfully contextualizes the tool's core filter (officer==agent) which implicitly explains why city/state/type/min_age filters matter for narrowing owner-operated business searches. It adds interpretive value by connecting min_age to the 'no management layer' scenario, slightly elevating above baseline.
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 specific function: finding businesses where an officer is also the registered agent, with the same person in both roles. It uses specific verbs and resources, and distinguishes itself from siblings by defining the unique filter criteria (officer==agent) that no sibling tool name suggests.
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 clear use cases ('acquisition target lists', 'judge whether a supplier depends on one person'), which tells the agent when to reach for it. It doesn't explicitly name alternative tools or exclusions, but the 'succession and acquisition signal' framing gives strong contextual guidance for when this tool's specific filter is wanted vs. generic browsing/search siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a messy or partial business name to ONE canonical government record, with a computed confidence score (0-1), an ambiguity flag and ranked alternatives. Use this when you have a company name from a document, email or user message and need to identify the actual registered entity. Prefer this over private_search when the goal is identification rather than browsing. If confidence is below 0.6, show the user the alternatives instead of choosing one.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City, used as a corroborating signal | |
| query | Yes | Business name as you have it, however messy | |
| state | No | Two-letter state code to narrow the search, e.g. FL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the computed confidence score (0-1), ambiguity flag, ranked alternatives, and gives a concrete behavioral rule (show alternatives when confidence < 0.6). This offers useful operational behavior beyond what the schema conveys.
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 two sentences and front-loaded with the core purpose and outputs in the first sentence. The second sentence adds usage guidance efficiently. Slightly verbose in the first sentence but no wasted words overall.
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 single-query resolution tool with 100% schema coverage, no output schema, and no annotations, this is thorough. It covers when to use it, output characteristics, and a decision rule for low confidence. Given the tool's simplicity, the description is complete.
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 of 3 applies. The description adds the 'however messy' framing for query and 'corroborating signal' context for city, but these map directly to what the schema already describes. It does not add format, syntax, or interplay details beyond 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?
The description clearly states the verb (resolve), the resource (messy business name to ONE canonical government record), and the specific outputs (confidence score, ambiguity flag, ranked alternatives). It effectively distinguishes from siblings by describing the identification goal and explicitly contrasting with private_search.
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 clear context on when to use it (company name from document/email/user message needing identification) and explicitly says to prefer it over private_search for identification rather than browsing. It names the alternative but doesn't detail when NOT to use it beyond that contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find US businesses by name when you do not yet know which one you want. Full-text ranked search over 30.6M entities from 56 state and territory registries. Use it to browse candidates or check whether a name exists at all; use private_resolve instead when you need to identify one specific company. Note: this matches NAMES. There is no industry classification in the search itself, so "roofing" returns companies named "Roofing ...", not every roofer — use private_list with a naics filter for that.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter by entity type: domestic_profit, domestic_llc, domestic_lp, foreign_profit, domestic_nonprofit | |
| limit | No | Max results (default 25, max 200) | |
| query | Yes | Business name or partial name to search | |
| state | No | Two-letter state code, e.g. FL, NY, CA, TX. 56 jurisdictions covered. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses a major behavioral trait: the search matches NAMES only, not concepts — with a concrete example. However, it doesn't disclose return format, ordering details, or pagination behavior, which leaves some gap for a ranked-search tool with no annotations or output 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?
Three tight sentences, front-loaded with the core purpose, followed by sibling-tool differentiation and a critical behavioral caveat. Every sentence earns its place with 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?
The tool has 4 parameters with full schema coverage and rich sibling context. The description explains when to use each sibling and the key behavioral quirk (name-matched, not concept-matched). Minor gap: no mention of ranking rationale or result-ordering behavior, but given the full schema coverage and clear sibling differentiation, this is largely complete.
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 schema already documents all four parameters. The description adds the useful note about no industry classification affecting search behavior, but doesn't add further parameter-level semantics beyond what the schema provides. Baseline 3 is appropriate given full schema coverage.
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 the specific purpose clearly: 'Find US businesses by name when you do not yet know which one you want' with full-text ranked search over 30.6M entities. Distinguishes from private_resolve (identify one specific company) and private_list (NAICS-based industry filtering), clearly defining the resource and verb.
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?
Explicitly names alternatives: use private_resolve when you need one specific company, and use private_list with a naics filter for industry-based searches. Also provides clear when-to-use context: browse candidates or check whether a name exists. The 'roofing returns companies named Roofing' example clarifies a critical usage edge case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check what this dataset actually covers before relying on it. Returns per-state record counts AND the government source behind each state, which matters: some states are full business registries with officer records, while others (California, Illinois) hold only federal SAM.gov registrants with no officer data at all. Read this before asking who runs a company in a state you have not used before.
| 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 of behavioral disclosure. It does well by revealing the critical data-quality caveat: some states are full registries while others only hold SAM.gov registrants with no officer data. It also tells the user to read it as a precondition before other lookups, disclosing that results vary by state. It doesn't describe the return format or whether this is a no-op safe read, but the caveat disclosure is substantial value.
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 compact three-sentence block that is dense but front-loaded with the core purpose. The parenthetical (California, Illinois) adds useful specificity. Minor redundancy exists between the opening 'check what this dataset actually covers' and the later coverage explanation, but every sentence earns its place. Slightly longer than strictly necessary but well structured.
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?
The tool has zero params and no output schema, so completeness depends entirely on the description. It covers the purpose, the return data, the critical caveat about per-state data quality, and usage timing. It could mention return format or how to interpret the counts, but for a no-parameter introspection tool with rich contextual guidance, this is well covered. The sibling context (many search/browse tools) makes this a meaningful guardrail tool, and the description equips the agent appropriately.
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?
There are zero parameters, so the schema-bearing ground is empty. Per the rubric, 0 params gets a baseline of 4. The description effectively communicates what the tool returns (per-state counts, source, coverage differences) which informs how an agent should interpret the to-be-returned data. No parameter explanations needed, so this scores at the baseline.
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 returns per-state record counts and the government source behind each state, which is a specific and distinctive purpose. The verb 'check' plus the concrete deliverables (record counts, government source) give a strong sense of the resource. The note differentiating coverage types (full business registries vs. federal SAM.gov only) further clarifies its role relative to sibling tools.
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 states when to use this tool: 'Read this before asking who runs a company in a state you have not used before.' It also warns about the limitation that some states (California, Illinois) lack officer data, which effectively guides when NOT to rely on certain states for officer lookups. This is strong, actionable guidance without naming a specific alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Entity type breakdown — how many domestic profit corps, LLCs, LPs, nonprofits, foreign corps, etc. Optionally filter by state.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Filter by state: FL, NY |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description does not state what data the breakdown is over (all entities in the system? a specific dataset?), whether counts or percentages are returned, whether foreign corps are filtered out by default, or what output format is produced. For a tool with zero annotations, this leaves significant behavioral ambiguity.
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?
One sentence, tightly packed with relevant information. Front-loaded the core purpose and ends with the optional filter. No wasted words. Could arguably be slightly more compact, but it's efficient and clear.
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?
The tool is relatively simple (one optional parameter, no output schema, no nested objects), so the description doesn't need extensive documentation. However, with no annotations and no output schema, it would benefit from stating what the breakdown returns (counts, percentages, both) and the scope of data it operates over. Given the low complexity, the description is minimally adequate but not rich.
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% for the single state parameter. The description adds the allowable values (FL, NY) implicit in the schema and mentions the optional state filter, but since 100% of parameters are already schema-documented, the description adds minimal additional semantic value beyond reiterating the filter exists.
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 what the tool does: provides an entity type breakdown (domestic profit corps, LLCs, LPs, nonprofits, foreign corps). The examples of entity types add specificity. It's distinct from sibling tools like private_geography (geographic breakdown) and private_age_distribution (age-based), though it doesn't explicitly differentiate itself.
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 the tool is used for entity-type categorization across a dataset, with optional state filtering. There's no explicit when-to-use/when-not-to-use guidance or mention of alternative tools. The optional state filter is conveyed, which gives partial usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Verified company profiles, financials, ownership, registry records and business contacts.
Live data from 27 official national company registries. Unmodified. For KYB and due diligence.
Screen a business for federal exclusions & sanctions: OFAC SDN, HHS-OIG LEIE, SAM.gov debarment.
Verify a company on official registries (GLEIF LEI, SEC EDGAR), screen sanctions. Free.
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes: search vs resolve vs browse vs officer vs entity records are well-separated. However, private_browse and private_search overlap in intent (both find companies by criteria/name), and the description explicitly cross-references private_list which doesn't exist as a tool, adding confusion. private_ceo_search and private_officer_search are distinguished mainly by title scope, which is reasonable but could be misselected.
Tools consistently use the private_ prefix with snake_case verb_noun names (private_browse, private_search, private_resolve, private_ceo_search, private_officer_search). The convention is uniform and predictable. Minor deviation: private_entity is a noun-only tool name rather than verb_noun, but all others follow the pattern well.
11 tools is well-scoped for a company data server. Each tool covers a distinct data-access pattern (browse, search, resolve, officer find, entity record, aggregates), and none feel redundant or ornamental.
The surface covers identification (search/resolve), full records (private_entity), officer/executive lookups, people-to-company mapping, and data-availability introspection (private_stats). Minor gaps: there's no dedicated tool for fetching physical addresses or contact info beyond the entity record, and no filtered officer search by state/industry combining criteria with private_browse. But core lifecycle needs are covered.