Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden, and it does contribute real behavior: it is a paid call ($0.03), settled on Base via x402, Ed25519-attested, and hits a specific GET endpoint. It omits what the response contains, latency, rate limits, and failure modes, so the safety/completeness picture is only half-drawn.

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?

It is front-loaded with the value proposition, which is good, but pricing is repeated twice, the alias and endpoint are both listed, and the upsell sentence consumes space that could carry usage guidance. Information density is high but some sentences do not earn their 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?

With no annotations and no output schema, the description must cover both behavior and return values; it covers payment model and attestation but says nothing about what research data comes back, which matters for a paid research call. Adequate but not complete for a tool at this complexity.

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 is a single required parameter and schema coverage is 100%, so the baseline is 3. The trailing '?q=company or domain' restates the schema's own 'Company name or domain' description without adding format, normalization, or disambiguation guidance for ambiguous names.

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?

It names the resource (company research) and enumerates the constituent data sources (web, scrape, firmographics, domain trust), so the agent knows roughly what it does. However it never differentiates itself from close siblings like lion_company_research or lion_company_dossier, and the mix of 'company-research' alias with a 'deep-research-json' endpoint muddies what the tool actually is.

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 only placement guidance is 'Use before/after people enrichment', which gives context but no when-not or alternative-selection rule. With four or five near-identical research/enrichment siblings, the absence of explicit routing (e.g. vs lion_company_research or lion_quick_intel) is a real gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.