sec_company_intelligence

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

With no annotations provided, the description carries the full behavioral burden, and it delivers meaningfully: enrichment is described as best-effort, unavailable sources are surfaced under 'degraded', and such failures never break the SEC-native response. It also discloses that the data is credential-free public data, which is useful context beyond a simple operation summary.

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: it states the aggregate purpose first, then input requirements, then optional enrichment behavior and failure semantics. Every sentence carries necessary information, with no filler or repetition of schema content.

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 moderate complexity, no output schema, and no annotations, the description is remarkably complete for invocation: it names the aggregated response components, explains optional enrichment dependencies, states the best-effort/degraded behavior, and clarifies credential requirements. An agent has enough to call this tool correctly without needing to open the schema.

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?

The schema already documents all 8 parameters, so the baseline is 3. The description adds genuine relational semantics: enrich is a comma list, market and news are keyed on the ticker, and hiring requires an ATS plus its careers slug or Workday tenant/datacenter/site. This meaningfully clarifies how the parameters interact beyond their individual schema entries.

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 leads with a specific verb ('Aggregates') and a clear resource ('Company 360 overview from SEC data'), then enumerates exactly what is included: profile, financial snapshot, latest filing, and material events. It is clear about what the tool does, though it does not explicitly differentiate itself from sibling SEC tools like sec_company_submissions or sec_filing.

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?

It instructs the agent to 'Provide cik or ticker' and explains when enrichment parameters are needed, including the ticker-keying and ATS-specific dependencies. However, it never explicitly states when to prefer this tool over the other SEC-related siblings or when not to use it; the usage guidance is implied rather than stated as a decision rule.

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