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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds a wealth of behavioral context beyond annotations: the fan-out across multiple sources, the soft-fail behavior for patents (USPTO API sunset), the specific return structure (cik, resolved_from/resolved_to, recent_filings URIs), the fact that empty sections are expected not failures, and the naming resolution behavior. It also discloses a limitation (private companies). The only minor gap is not explicitly stating response format/pagination, but for a data-fetch tool this is well-covered. Would be a 5 except it stumbles slightly on clearly communicating the 'news via GDELT→GNews fallback' with a single arrow, which is somewhat terse.

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 dense and information-packed, with a clear structure: triggers first, then the approach directive, then a bulleted enumeration of sources and return fields, then parameter guidance. It is front-loaded with the most critical usage direction ('ALWAYS PREFER'). However, it is quite long, and some sentences run on (the return-list sentence is a wall of text). It earns its length because every clause adds useful information, but it could be slightly more scannable with line breaks or headers. It's not bloated with fluff, so a 4 rather than 3, but not a 5 due to the run-on structure.

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?

Given the tool's high complexity (multiple data sources, multiple return sections, edge cases, fallbacks), the description is remarkably complete. It covers: input formats, name resolution, private-company behavior, expected empty sections, source failure semantics, and explicit examples of returns like resolved_from/to. The output schema is absent, so the description must convey the return structure, which it does thoroughly (cik, company_name, recent_filings URIs, fundamentals with sort order, etc.). No critical information that an agent needs to call and interpret correctly is missing. The description even explains why a section might be empty (e.g., small-molecule-only companies showing no fda_products). This is a model of completeness for a complex data-fetch 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 description coverage is 100%: both `type` and `value` are fully described in the schema itself, including the note about interchangeability. The description reinforces this by providing concrete examples ('AAPL', '0000320193', 'Moderna') and clarifying that names resolve via SEC EDGAR. It adds the exact accepted shapes and behavior when a private company is given. This exceeds the baseline 3 because the description provides examples and edge-case behavior not in the schema, but since the schema already covers the basic semantics, a 4 is appropriate rather than 5.

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 is exceptionally specific: it lists multiple natural-language triggers, names the primary resource (full cross-source profile of a US public company), and distinguishes itself from alternatives by explicitly stating 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' It clearly differentiates from siblings like deep_research, compare_entities, and resolve_entity by defining its scope. The verb 'profile' plus the enumerated data sources makes purpose unambiguous.

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 provides explicit when-to-use guidance with imperative language ('ALWAYS PREFER') and specific examples of triggering queries. It names the alternative approach (chaining single-pack lookups) and the condition for preferring this tool. It also covers edge cases: private companies return resolved:false with notes, and expected empty sections are explained. The note about 'sources_failed' being real no-data vs bug provides critical interpretational guidance.

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