Get alternative-data signals

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds valuable context: the output is nested under 'data', and inactive sources are null rather than zero. This goes beyond the annotations by explaining the data shape and null-handling behavior, though it doesn't mention rate limits or error conditions.

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 long but well-structured: it front-loads the core value proposition, then uses a semicolon-separated list to enumerate all 15 sources efficiently. Every sentence adds information, and the closing sentence reinforces its strategic value, though it borders on promotional tone.

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 complexity (15 aggregated sources) and the absence of an output schema, the description does a solid job of explaining what to expect: the data location, source categories, and null behavior. It could be improved by mentioning the response format or potential error cases, but it is largely complete for an average agent.

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 only one parameter 'ticker' and 0% schema description coverage, the description must compensate by adding meaning. It mentions 'for a ticker' but offers no examples, format constraints, or clarification of what constitutes a valid ticker (e.g., symbol vs. company name). The description essentially restates the parameter name without enriching it.

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 it provides 'the full alternative-data dossier for a ticker' and enumerates 15 specific data sources, making the tool's purpose concrete. It distinguishes itself from a generic alt-data feed by emphasizing comprehensiveness, but it does not explicitly differentiate itself from the sibling tool 'stoquant_get_alt_data'.

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 explicitly recommends using it 'to surface catalysts and red flags an ordinary data feed misses,' giving a clear use case. It also explains that sources with no recent activity are null, which helps set expectations. However, it does not mention when to prefer this over the simpler 'stoquant_get_alt_data' or other focused alternatives.

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