Margin of Insight — Equity Research

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

No annotations provided, so description carries full burden. It mentions it returns specific data and is free, but lacks details on data freshness, authentication, or side effects. Adequate but not comprehensive.

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?

Two sentences with no wasted words. Front-loaded with verb and resource, then lists returns and a key qualifier (free). Highly concise.

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?

Without an output schema, the description adequately explains return contents and emphasizes no cost. It could mention whether non-US companies are excluded, but overall complete for a simple retrieval 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 coverage is 100% for the single 'ticker' parameter with clear description. The tool description adds domain restriction ('US-listed') which provides additional context beyond the schema, but does not significantly enhance parameter meaning.

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 the tool retrieves a company primer for US-listed companies and lists specific outputs (business overview, financial snapshot, recent catalysts). It distinguishes from siblings like get_fundamental_analysis by emphasizing 'primer' and 'free'.

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 implies usage for quick overviews with 'primer' and 'free', but does not explicitly state when not to use or name alternatives. It provides clear context for use.

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

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

Without annotations, the description adds value by listing the 12 research steps and disclosing the $1.00 cost and required payment token. However, it does not describe failure modes, response format, or any side effects, so transparency is moderate.

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 four sentences, front-loading the core purpose and steps before payment details. Every sentence adds relevant information; no redundancies. It is concise but could be slightly tighter.

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 one parameter and no output schema, the description covers output structure (12 steps), cost, and payment method. It is sufficient for an agent to understand what the tool does and its prerequisites, though output format details are missing.

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 input schema provides 100% coverage with a description for 'ticker' ('Stock ticker symbol'), and the tool description adds no further semantics or examples. Baseline of 3 is appropriate since schema already documents the single parameter adequately.

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 the tool retrieves fundamental analysis and enumerates 12 research steps, specifying the resource and scope. It implicitly differentiates from sibling tools like get_company_primer and get_investment_memo by listing distinct content areas, but does not explicitly contrast them.

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 no guidance on when to use this tool instead of siblings such as get_company_primer or get_investment_memo. It only mentions payment details, which are not usage guidelines for tool selection.

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

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

The description discloses the cost ($2.00) and the required payment method (Stripe shared payment token in Authorization header), which is critical for a paid API. However, it does not address failure cases like invalid tokens, insufficient funds, or response format, nor does it mention side effects or rate limits. Since no annotations exist, the description carries full burden and provides moderate transparency.

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 three sentences covering what the tool retrieves, its cost, and payment instructions. It is appropriately front-loaded with the core purpose. The list of 21 research steps is somewhat detailed but acceptable for clarity. There is no redundant or filler 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?

The tool has one parameter and no output schema. The description covers the input (ticker), the output nature (full memo), and payment logistics. However, it lacks details on the response format, possible errors, and any prerequisites (e.g., user must have a Stripe token beforehand). Given the complexity of a paid research tool, these omissions limit completeness.

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 documents a single required parameter 'ticker' with description 'Stock ticker symbol'. The description uses 'ticker' in context but adds no additional semantics such as format expectations, case sensitivity, or valid exchanges. With 100% schema coverage, the baseline is 3, and the description does not exceed 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 the tool retrieves a full investment memo, listing specific components like DCF valuation, moat analysis, and management quality. It equates the memo to a sell-side initiation note, distinguishing it from likely less comprehensive sibling tools such as get_company_primer or get_fundamental_analysis.

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 implies usage for in-depth research by detailing the breadth of the memo, but it does not explicitly state when to use this tool versus alternative siblings like list_coverage or request_coverage. No exclusion criteria or when-not-to-use guidance is provided.

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

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

No annotations are provided, so the description carries the full burden. It only states the tool lists data and the fields returned, but lacks disclosure of behavioral traits like rate limits, authentication needs, data freshness, or whether the list is comprehensive. Minimal transparency.

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 extremely concise with one clearly written sentence plus 'Free.' Every word adds value, and the key information is front-loaded.

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 has no output schema, the description explains the return fields (company name, sector, exchange, last updated date), which is sufficient for a simple listing. Could mention whether the list is paginated or sorted, but overall adequate.

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 input schema has 0 parameters, so the description does not need to add parameter details. Baseline for 0 params is 4. The description correctly implies no parameters are needed by stating it lists 'all' covered tickers.

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 the tool lists all covered tickers with specified fields (company name, sector, exchange, last updated date). It uses a specific verb (list) and resource (covered tickers), and is distinct from sibling tools like get_company_primer which retrieve specific company 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 mentions 'Free' to indicate no cost, but provides no guidance on when to use this tool vs alternatives like get_company_primer or search_research. No explicit when-to-use or when-not-to-use context.

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

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

With no annotations, the description carries full burden. It discloses typical timing (24-48 hours) and cost (free) but does not specify error behavior if the company is already covered or any other behavioral traits like rate limits or confirmation details.

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?

Two sentences: first states the purpose and condition, second adds timing and cost. No unnecessary words, front-loaded with key information. Highly efficient.

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 simple request tool with no output schema, the description covers essential aspects: purpose, condition, timing, and cost. It could mention what response looks like but is adequate given low 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?

Input schema has 100% description coverage for both parameters (ticker and email). The description reinforces the ticker's purpose but adds no new meaning beyond what the schema provides. Baseline score of 3 applies.

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 the verb 'request' and resource 'research coverage' for US-listed companies not in the coverage universe. It distinguishes from sibling tools like list_coverage and search_research by specifying the condition of not yet covered.

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 states when to use: for companies not yet in the coverage universe. It implies constraints (US-listed) and adds context (24-48 hour turnaround, free). It does not explicitly name alternative tools for already covered companies, but the sibling context provides that.

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

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

With no annotations, the description carries the full burden. It states the return fields and that it's free, but does not disclose rate limits, pagination, error handling, or any behavioral nuances beyond basic functionality.

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 brief and to the point, containing two sentences. However, the word 'Free' at the end feels tacked on and breaks the flow slightly. It could be more structured.

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 simple search tool with one parameter and no output schema, the description covers the essential aspects: what it does, what you input, and what you get back. It's reasonably complete, though it could mention ordering or limit of results.

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 has 100% coverage with a description for 'query' that says 'Ticker symbol or company name to search for.' The description adds little beyond that, merely restating 'by ticker or company name.' Baseline 3 is appropriate.

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 the action (Search), the resource (covered companies), and the search criteria (by ticker or company name). It also lists the returned fields, distinguishing it from siblings like get_company_primer which likely returns more detailed 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 clearly indicates when to use the tool (to search for companies by ticker or name). However, it does not provide explicit exclusions or when not to use it, nor does it mention alternatives among the sibling tools.

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