Look up a single company by its slug (preferred) or name, returning its full profile: name, slug, employee count, headquarters, founding year, ticker, company type, and estimated valuation. Use search-companies first if you only have a name and need the exact slug. REQUIRED arguments: companyNameOrSlug.
| Name | Required | Description | Default |
|---|---|---|---|
| companyNameOrSlug | Yes | Name or slug of a company |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered and the description carries a lighter burden. It adds real value by enumerating the returned profile fields (compensating for the missing output schema) and by flagging slug as the preferred lookup key. It does not say what happens when the company is not found or when a name matches multiple companies.
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?
Front-loaded with the verb and the return shape, then the routing hint, then the required-argument note. The trailing 'REQUIRED arguments: companyNameOrSlug' is mildly redundant with the schema's required array but does no harm.
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 one-parameter read tool with annotations and no output schema, the definition is nearly complete: it covers purpose, input preference, alternative routing, and the returned field set. The only meaningful gap is error/ambiguity behavior, which an agent would need to guess.
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?
With a single parameter at 100% schema coverage, the baseline is 3, but the description adds genuine semantics: slug is preferred over name, and the argument is marked required. The schema description alone ('Name or slug of a company') conveys none of that preference.
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 a specific verb and resource ('Look up a single company') and enumerates the returned profile fields, so the agent knows exactly what it gets back. The parenthetical '(preferred)' for slug and the reference to search-companies distinguish it from the search 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?
Explicitly routes the agent: prefer slug over name, and use search-companies first when only a name is available and the exact slug is needed. That names the alternative and the condition that selects it, leaving nothing to inference.
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.