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 arguments | |||
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.
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.