Skip to main content
Glama

companies

by global.rootz.private

private_resolve

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNoCity, used as a corroborating signal
queryYesBusiness name as you have it, however messy
stateNoTwo-letter state code to narrow the search, e.g. FL

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All companies toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Resources