Look up company registration records, officers, and filings from global business registries. Args: company_name: Company name to search jurisdiction: Jurisdiction code (e.g., 'us_de' for Delaware, 'gb' for UK) max_results: Max results (default 10)
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | ||
| company_name | Yes | ||
| jurisdiction | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds that it searches global registries and returns records/officers/filings, but does not disclose additional behavioral details such as response format, pagination, or potential data variability. It does not contradict 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?
The description is compact and front-loaded with the purpose. The 'Args:' section cleanly lists parameters without fluff. Every sentence contributes useful 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?
With no output schema, the description should clarify what the tool returns. It mentions the categories (records, officers, filings) but does not describe the return structure, pagination, or error cases. The parameter details and read-only annotation are helpful, but the return format is a clear gap for a lookup 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 coverage is 0%, so the description carries the full burden for parameter meaning. It explains all three parameters with clear definitions, including jurisdiction examples ('us_de', 'gb') and a default value for max_results. This adds meaningful context 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?
The description clearly states the tool's function: 'Look up company registration records, officers, and filings from global business registries.' This provides a specific verb, resource, and scope, and clearly distinguishes it from sibling tools that deal with products, recalls, and contracts.
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 is provided on when to use this tool versus alternatives. The description only states what it does; there are no when-not-to-use conditions, prerequisites, or mentions of alternative tools for different needs.
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.
Each tool targets a distinct data source and action: product price comparison, business registration lookup, Amazon product search, FDA recalls, and government contracts. There is no meaningful overlap; even the two product-related tools are clearly separated by scope (cross-platform vs. Amazon-specific).
All tool names follow a consistent verb_noun pattern in snake_case (compare_product_prices, lookup_business_registration, search_amazon_products, etc.). Though the verbs vary, the structure is uniform and predictable.
With exactly 5 tools, the surface is well-scoped for a data lookup server. Each tool covers a distinct domain without redundancy or bloat, making the set feel curated and manageable.
The server provides comprehensive read-only search coverage across its stated data domains: product pricing, business registry, Amazon catalog, FDA safety, and federal spending. There are no obvious gaps for a lookup-oriented tool set.