equivault-mcp

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it returns a comprehensive snapshot, handles tier restrictions by marking sections as unavailable instead of failing, and implies it's a read operation. However, it lacks details on rate limits, authentication needs, or response format, leaving gaps for a tool with no output schema.

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 front-loaded with the core purpose in the first clause and uses two efficient sentences with zero waste, each adding critical information (snapshot scope and error handling for tier restrictions).

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 complexity (comprehensive data aggregation) and lack of annotations and output schema, the description is incomplete. It covers purpose and error handling but omits details on return values, data structure, or behavioral constraints like pagination, which are needed for full agent understanding.

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 100% description coverage for the single parameter (company_id), so the baseline is 3. The description adds value by implicitly linking the parameter to the output context (e.g., 'comprehensive company snapshot'), though it does not provide additional syntax or format details beyond the schema.

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's purpose with specific verbs ('Get a comprehensive company snapshot') and resources ('profile, financial statements, metrics, and investment narrative'), distinguishing it from siblings like get_company or get_financials by emphasizing comprehensiveness in a single call.

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 clear context for when to use this tool ('in a single call' for a snapshot) and mentions tier-based access limitations, but it does not explicitly state when not to use it or name specific alternatives among the many sibling tools, such as get_company for basic info.

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 provided, the description carries full burden. It discloses that sections may be 'unavailable' based on user tier, which is valuable behavioral context. However, it doesn't mention other important traits like response format, pagination, rate limits, authentication requirements, or whether this is a read-only operation.

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 appropriately sized with two sentences that efficiently convey the tool's purpose and limitations. It's front-loaded with the core functionality, though the parenthetical list of sections could be slightly more streamlined.

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 tool with no annotations and no output schema, the description provides reasonable context about what the tool returns (comprehensive company data) and access limitations. However, it doesn't describe the return format, structure, or what happens when sections are unavailable, leaving gaps for an AI agent to understand the full behavioral contract.

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% for the single parameter 'company_id', which is well-documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema, so it meets the baseline of 3 for high schema coverage.

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 'Get' and resource 'full fundamental deep-dive for a company', specifying it includes 'everything from analyze_company PLUS all profile sections' with explicit examples. It distinguishes from sibling 'analyze_company' by indicating it's a superset with additional sections.

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 clear context for when to use this tool versus 'analyze_company' (as a more comprehensive alternative) and mentions tier-based access limitations. However, it doesn't explicitly state when NOT to use it or compare with other potential alternatives like 'get_company' or 'research_report'.

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 of behavioral disclosure. It states the tool compares financial metrics but doesn't reveal key traits: whether this is a read-only operation, what metrics are included, if there are rate limits, how results are formatted, or if it requires authentication. For a tool with no annotations, this is insufficient to guide the agent effectively.

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 a single, efficient sentence that directly states the tool's purpose without any fluff. It's front-loaded with the core function and uses clear language, making it easy to parse. Every word earns its place, contributing to understanding without redundancy.

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 of comparing financial metrics across companies, the description is incomplete. There are no annotations, no output schema, and the description lacks details on behavior, return values, or usage context. While the schema covers the single parameter, the overall tool understanding is inadequate for effective agent invocation, especially with many sibling tools that might overlap.

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 100% description coverage, with the parameter 'company_ids' documented as 'Comma-separated company IDs to compare (from search_companies results).' The description adds no additional meaning beyond this, as it doesn't elaborate on the parameter's usage or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema handles the parameter documentation 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's purpose: 'Compare financial metrics across multiple companies side by side.' It specifies the verb ('compare') and resource ('financial metrics across multiple companies'), making the function evident. However, it doesn't explicitly differentiate from sibling tools like 'get_metrics' or 'analyze_company', which might also involve metrics or comparisons, so it doesn't reach the highest score.

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 versus alternatives. It doesn't mention prerequisites, such as needing company IDs from 'search_companies', or contrast it with similar tools like 'get_metrics' for single companies or 'screen_companies' for broader filtering. This lack of context leaves the agent without clear usage instructions.

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 provided, the description carries full burden. It discloses the Advisor tier requirement (an auth/access constraint) and the scoping behavior for company_id, which are valuable behavioral traits. However, it doesn't mention potential side effects, rate limits, or what happens on successful creation (e.g., returns an alert ID).

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 perfectly sized at three sentences with zero waste. It's front-loaded with the core purpose, followed by important scoping details, and ends with the access requirement. Every sentence earns its place by adding distinct value.

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 creation tool with no annotations and no output schema, the description does well by covering purpose, scoping behavior, and access requirements. However, it doesn't explain what happens after creation (e.g., whether alerts are active immediately, what format the response might have), which would be helpful given the lack of output 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?

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds some context about company_id scoping ('if omitted, the alert applies to all followed companies'), but doesn't provide additional semantic meaning beyond what's in the schema descriptions for other parameters.

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 ('Create') and resource ('new alert rule') with specific functionality ('fires when a metric meets a condition'). It distinguishes from sibling tools like 'delete_alert' and 'update_alert' by specifying creation rather than modification or deletion.

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 clear context about when to use it (creating alerts for metrics) and includes an important prerequisite ('Requires Advisor tier'). However, it doesn't explicitly state when NOT to use it or mention alternatives like 'update_alert' for modifying existing alerts.

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 provided, the description carries the full burden of behavioral disclosure. It effectively communicates critical behavioral traits: the destructive nature ('This cannot be undone') and authorization requirements ('Requires Advisor tier'), which are essential for safe tool invocation.

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 efficient with three short sentences that each serve distinct purposes: stating the action, warning about irreversibility, and specifying authorization requirements. There's zero wasted language and it's perfectly 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?

For a destructive mutation tool with no annotations and no output schema, the description does an excellent job covering critical aspects: purpose, irreversibility, and authorization. However, it doesn't mention what happens after deletion (confirmation, error handling) or potential side effects, leaving minor gaps.

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 description coverage is 100%, with the single parameter 'alert_id' fully documented in the schema. The description doesn't add any additional parameter semantics beyond what's already in the schema, so it meets the baseline expectation without adding extra value.

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 specific action ('Delete') and resource ('an alert rule'), distinguishing it from sibling tools like 'create_alert' and 'update_alert'. It provides a complete verb+resource combination that leaves no ambiguity about what the tool does.

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 'Requires Advisor tier', providing clear context about prerequisites. However, it doesn't specify when to use this tool versus alternatives like 'update_alert' or provide explicit exclusions, which prevents a perfect score.

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 of behavioral disclosure. It states this is a 'Get' operation, implying read-only behavior, but doesn't clarify if it requires authentication, has rate limits, returns paginated results, or what format the snapshots are in. For a tool with zero annotation coverage, this leaves significant gaps.

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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every part contributing to understanding what the tool does.

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 (1 parameter, no output schema, no annotations), the description is minimally adequate. It explains what the tool retrieves but lacks details on behavioral traits, usage context, and output format. With no output schema, the description should ideally hint at return values, but it doesn't, leaving room for improvement.

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 description doesn't mention any parameters, but the input schema has 100% coverage with a single parameter 'company_id' fully documented. Since schema_description_coverage is high (>80%), the baseline is 3, as the description doesn't need to add parameter details beyond what the schema already provides.

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 'Get' and resource 'snapshots of accounting policies and changes from prior periods', making the purpose understandable. However, it doesn't explicitly differentiate this from sibling tools like 'get_financials' or 'get_metrics' that might also provide accounting-related data, so it doesn't reach the highest score.

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 versus alternatives. It doesn't mention prerequisites (e.g., needing a company_id from search_companies), exclusions, or comparisons to sibling tools like 'get_financials' that might overlap in accounting data.

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 provided, the description carries the full burden of behavioral disclosure. It mentions retrieving current billing information, which implies a read-only operation, but does not specify authentication needs, rate limits, or other behavioral traits like data freshness or error handling.

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 a single, efficient sentence that front-loads the key action and details without any wasted words. It is appropriately sized for a simple, parameterless tool.

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 simplicity (0 parameters, no output schema, no annotations), the description is adequate but has gaps. It covers the purpose but lacks behavioral details and usage context, making it minimally viable but not fully complete for an account status 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?

The tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description appropriately does not discuss parameters, aligning with the baseline for zero parameters.

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 ('Get') and resource ('billing status, tier, query usage, and limits for your EquiVault account'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools, as none appear to be billing-related, so it misses full sibling distinction.

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 versus alternatives, such as other account-related tools or scenarios for checking billing. It lacks explicit context or exclusions, leaving usage implied at best.

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 full burden. It states this is a read operation ('Get'), but doesn't disclose behavioral traits such as authentication requirements, rate limits, error conditions, or whether the brief must be accessible to the user. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves in practice.

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 a single, efficient sentence that front-loads the core purpose ('Get the full contents of a specific brief') and specifies key components. There is no wasted verbiage, repetition, or unnecessary elaboration, making it easy to parse quickly.

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 no annotations and no output schema, the description provides basic purpose but lacks details on return format, error handling, or behavioral context. It's minimally viable for a simple retrieval tool with one parameter, but doesn't fully compensate for the absence of structured metadata, leaving gaps in understanding the tool's operation and 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?

Schema description coverage is 100%, with the single parameter 'brief_id' fully documented in the schema as 'Brief ID from list_briefs'. The description adds no additional parameter information beyond what the schema provides, such as format examples or validation rules. Baseline 3 is appropriate when the schema handles parameter documentation 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 verb 'Get' and the resource 'full contents of a specific brief', specifying what information is included (scorecard, strategy score, rendered sections). It distinguishes from sibling 'list_briefs' by focusing on a single brief's details rather than listing multiple briefs. However, it doesn't explicitly differentiate from other content-retrieval tools like 'get_company' or 'get_financials'.

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 when detailed brief content is needed, referencing 'brief_id from list_briefs' in the schema, which suggests using 'list_briefs' first. However, it lacks explicit guidance on when to choose this tool over alternatives like 'get_company_narrative' or 'research_report', and doesn't mention any exclusions or prerequisites beyond the ID requirement.

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 of behavioral disclosure. It states what data is retrieved but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication requirements, data freshness, or response format. For a data retrieval tool with zero annotation coverage, this leaves significant gaps.

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 a single, efficient sentence that front-loads the core purpose and lists specific data components without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function.

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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the return data looks like (e.g., time periods, units, structure), nor does it cover behavioral aspects like error handling or data sources. For a financial data tool with no structured support, more context is needed.

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%, with the single parameter 'company_id' fully documented in the schema. The description doesn't add any parameter-specific details beyond implying it retrieves data for a company. Baseline 3 is appropriate when the schema does the heavy lifting, though no extra value is added.

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's purpose with a specific verb ('Get') and resource ('historical capital allocation'), listing the specific components it retrieves (buybacks, dividends, debt repayment, M&A, capex). It distinguishes itself from generic company tools but doesn't explicitly differentiate from similar financial data tools like 'get_financials' or 'get_metrics'.

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?

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing a company_id from 'search_companies'), nor does it suggest when to choose this over other financial data tools like 'get_financials' or 'get_metrics' that might overlap in scope.

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 provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves 'detailed information' but doesn't specify what that includes, whether it's read-only, requires authentication, has rate limits, or how it handles errors. This leaves significant gaps for a tool with potential complexity.

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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for a simple retrieval tool, with zero wasted 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' entails, the return format, or error handling. For a tool in a rich sibling set with potential data complexity, more context is needed to guide effective use.

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 100% description coverage, with the parameter 'company_id' documented as 'Company ID from search_companies results'. The description adds no additional meaning beyond this, as it doesn't clarify ID format or sourcing. Baseline 3 is appropriate since the schema does the heavy lifting.

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 ('Get') and resource ('detailed information about a specific company'), specifying the action and target. However, it doesn't distinguish this from sibling tools like 'get_company_narrative' or 'get_financials' that might also retrieve company information, missing explicit differentiation.

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 versus alternatives such as 'search_companies' for finding companies or other 'get_company_*' tools for specific data types. It lacks context on prerequisites or exclusions, offering minimal usage direction.

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 full burden. It mentions the optional 'history' parameter but does not disclose behavioral traits like authentication requirements, rate limits, response format, error conditions, or whether this is a read-only operation. The description is minimal beyond the basic function.

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 front-loaded with the core purpose in the first clause, followed by a concise explanation of the optional parameter. Both sentences earn their place by providing essential information without redundancy or fluff.

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 no annotations and no output schema, the description is incomplete for a tool that returns complex narrative data. It lacks details on response structure (e.g., format of the thesis, how history versions are presented), error handling, or any constraints, leaving significant gaps for an agent to use it effectively.

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%, so the schema already documents both parameters ('company_id' and 'history'). The description adds marginal value by explaining that 'history=true' includes 'prior narrative versions', which slightly clarifies the boolean's purpose beyond the schema's 'Include prior narrative versions'.

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 specific action ('Get the investment thesis for a company') and resource ('company'), including detailed components ('value drivers, headwinds, and tailwinds'). It distinguishes from siblings like 'get_company' (general info) or 'get_financials' (numeric data) by focusing on narrative/thesis content.

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 clear context for when to use the tool (to obtain investment thesis with optional history), but does not explicitly state when not to use it or name specific alternatives among siblings (e.g., 'get_brief' or 'research_report' might overlap). The guidance is helpful but lacks exclusion criteria.

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 full burden. It states what data is retrieved but doesn't disclose behavioral traits like whether this is a read-only operation, requires authentication, has rate limits, returns real-time vs historical data, or what format the signals come in. The description is minimal and lacks operational context.

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?

Single sentence with zero waste - every word contributes meaning. Front-loaded with the core action and resource, followed by clarifying examples. No redundant or verbose language.

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 tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the return values look like (structured data, list of signals, timeframes), doesn't mention limitations or scope, and provides minimal context for a tool that presumably returns complex competitive intelligence data.

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% for the single parameter (company_id), so the schema already documents it fully. The description doesn't add any parameter-specific information beyond what's in the schema, but with complete schema coverage, 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 verb 'Get' and resource 'competitive signals affecting a company' with specific examples (market share shifts, new entrants, pricing pressure). It distinguishes from generic company tools but doesn't explicitly differentiate from sibling signal tools like get_signals or get_signal_summary.

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?

No guidance on when to use this tool versus alternatives like get_signals, get_signal_summary, or get_signal_dashboard. The description implies it's for competitive signals but doesn't specify prerequisites, context, or exclusions compared to other signal-related tools.

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 full burden. While 'Get' implies a read operation, it doesn't disclose behavioral traits like authentication requirements, rate limits, data freshness, or response format. The description mentions what data is returned but not how it's structured or any limitations.

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?

Single sentence efficiently conveys the tool's purpose and output components. No wasted words or redundant information. The description is appropriately sized for a simple data retrieval tool.

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 single-parameter read tool with no annotations and no output schema, the description provides adequate basic information about what data is returned. However, it lacks details about response structure, data format, or any constraints that would help an agent use it effectively. The absence of output schema increases the need for more behavioral context.

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% with one parameter clearly documented. The description doesn't add any parameter-specific information beyond what's in the schema (company_id from search_companies). This meets the baseline expectation when schema coverage is complete.

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 'Get' and the resource 'debt maturity schedule' with specific components (principal due per year, interest rates, instrument types). It distinguishes this from general company analysis tools but doesn't explicitly differentiate from other financial data tools like get_financials or get_metrics.

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?

No guidance is provided about when to use this tool versus alternatives. With many sibling tools like get_financials, get_metrics, and get_company that might provide overlapping or related data, the description offers no context about when this specific debt maturity data is needed versus other financial analysis tools.

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 of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but does not specify if it requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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 a single, efficient sentence that front-loads the core purpose. It lists specific components of the earnings quality assessment, which adds useful detail without redundancy. However, it could be slightly more structured by separating the tool's action from the returned components for better clarity.

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 complexity (retrieving multi-component financial assessments), no annotations, and no output schema, the description is moderately complete. It specifies what data is returned but lacks details on format, pagination, or error handling. For a tool with 1 parameter and high schema coverage, it meets minimal viability but could improve by addressing behavioral aspects.

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 100% description coverage, with the parameter 'company_id' documented as 'Company ID from search_companies'. The description does not add any further meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately handles parameter documentation.

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's purpose: to retrieve an earnings quality assessment with specific components (accruals ratio, cash conversion, non-GAAP adjustments, and flags). It uses a specific verb ('Get') and identifies the resource ('earnings quality assessment'), but does not explicitly differentiate it from similar sibling tools like 'get_financials' or 'get_accounting_snapshots', which might also provide financial metrics.

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 versus alternatives. It does not mention prerequisites, such as needing a company ID from 'search_companies', nor does it contrast with sibling tools like 'get_financials' or 'get_metrics' that might overlap in functionality. Usage is implied only by the tool name and description.

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 of behavioral disclosure. It states the tool retrieves financial statements but does not cover critical aspects such as data freshness, rate limits, authentication requirements, error handling, or response format. For a read operation with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.

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 a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly communicates what the tool does and the resource involved, making it easy to parse and understand quickly.

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 (retrieving financial data with two parameters) and no output schema, the description is minimally adequate but incomplete. It lacks details on return values, data scope, or behavioral traits, which are crucial for effective use. However, the clear purpose and high schema coverage provide a basic foundation.

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%, with clear documentation for both parameters (company_id and period_type), including an enum for period_type. The description adds no additional parameter semantics beyond implying financial statements are retrieved, which is already covered by the tool's purpose. This meets the baseline for high schema coverage.

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's purpose with a specific verb ('Get') and resource ('financial statements'), listing the three statement types (income statement, balance sheet, cash flow) and specifying the target ('for a company'). However, it does not distinguish this tool from potential siblings like 'get_company' or 'get_accounting_snapshots', which might also retrieve financial data, leaving some ambiguity about its unique role.

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 versus alternatives. With many sibling tools like 'get_company', 'get_accounting_snapshots', and 'get_metrics' that might overlap in financial data retrieval, there is no explicit or implied context for choosing this tool over others, nor any mention of prerequisites or exclusions.

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 of behavioral disclosure. It states it 'gets' data, implying a read-only operation, but doesn't specify if this requires authentication, has rate limits, returns structured or raw data, or includes pagination. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.

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 a single, efficient sentence that front-loads the purpose and key details (guidance commitments and outcomes). There's no wasted verbiage, though it could be slightly more structured by separating usage context.

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 with full schema coverage and no output schema, the description is minimally complete for a simple lookup tool. However, with no annotations and no output schema, it lacks details on behavioral traits (e.g., data format, error handling) and return values, leaving the agent to guess. It's adequate but has clear gaps.

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%, with the single parameter 'company_id' documented in the schema as 'Company ID from search_companies'. The description doesn't add any meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.

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 'get' and the resource 'management guidance tracker for a company', specifying it includes 'prior guidance commitments and actual outcomes (beat/miss/in-line)'. This distinguishes it from general company tools like get_company or get_financials by focusing on management guidance. However, it doesn't explicitly differentiate from potential siblings like get_management_statements, which might cover similar ground.

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 versus alternatives. It doesn't mention prerequisites (e.g., needing a company_id from search_companies), exclusions, or comparisons to siblings like get_management_statements or get_company_narrative. The agent must infer usage from the purpose alone.

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 mentions the tool retrieves data ('Get') and allows filtering, but lacks critical behavioral details: whether it's read-only, requires authentication, has rate limits, returns paginated results, or what the output format looks like. For a data retrieval tool with no annotation coverage, this is a significant gap.

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 a single, efficient sentence that front-loads the core purpose and includes optional filtering details. It avoids redundancy and wastes no words, though it could be slightly more structured by separating the main action from the filter explanation.

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 no annotations and no output schema, the description is incomplete for a data retrieval tool. It doesn't cover behavioral aspects like safety, permissions, or output format, and while the schema handles parameters well, the overall context lacks necessary operational details for effective agent use.

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%, so the schema already documents both parameters (guru_id and change_type with enum values). The description adds marginal value by explaining that change_type filters for 'new positions, increased, decreased, or sold', which aligns with the enum but doesn't provide additional syntax or context beyond the schema. Baseline 3 is appropriate when schema does the heavy lifting.

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's purpose: 'Get portfolio holdings for a prominent investor (guru)' with optional filtering by change type. It specifies the verb ('Get'), resource ('portfolio holdings'), and target ('prominent investor'), making it distinct from siblings like get_financials or get_insider_transactions. However, it doesn't explicitly differentiate from get_portfolio_analytics, which might be a related sibling.

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 context by mentioning optional filtering by change type, suggesting it's for analyzing investment changes. However, it provides no explicit guidance on when to use this tool versus alternatives like get_portfolio_analytics or get_insider_transactions, nor does it mention prerequisites or exclusions.

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 provided, the description carries the full burden. It discloses access requirements (Advisor tier) and the type of data returned (insider transactions with 10b5-1 flag), which adds useful context. However, it omits behavioral details like rate limits, pagination, error handling, or response format, limiting transparency for a tool with no annotations.

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 a single, efficient sentence that front-loads key information (what the tool does and access requirement) with zero wasted words. It is appropriately sized for a simple tool with one parameter and no complex outputs.

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 no annotations, no output schema, and a simple input schema, the description is moderately complete. It covers the tool's purpose and access requirement but lacks details on return values, error cases, or behavioral constraints, which are needed for full context in the absence of structured fields.

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%, so the schema fully documents the single parameter (company_id). The description does not add any meaning beyond the schema, such as explaining how company_id relates to insider transactions or providing examples. Baseline 3 is appropriate as the schema handles parameter documentation 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 insider transactions (buys, sells, grants, exercises) with a specific flag (10b5-1), making the verb+resource explicit. However, it does not distinguish from siblings like 'get_management_statements' or 'get_signals' that might also provide related data, preventing a perfect score.

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 by specifying a required tier (Advisor), which provides some context for when to use it based on access level. However, it lacks explicit guidance on when to choose this tool over alternatives (e.g., vs. 'get_management_statements' for insider insights) or any exclusions, leaving usage partially inferred.

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 provided, the description carries the full burden of behavioral disclosure. It mentions the access requirement ('Requires Advisor tier') which is useful context, but doesn't describe what the tool returns (format, structure, examples), whether it's paginated, rate-limited, or what constitutes 'notable' statements. For a tool with sentiment analysis and attribution features, more behavioral context would be expected.

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 appropriately concise with two clear sentences: one stating the core functionality and one stating the access requirement. Both sentences earn their place by providing essential information without redundancy or unnecessary elaboration.

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 annotations and no output schema, the description provides basic purpose and access requirements but lacks details about return values, behavioral characteristics, or differentiation from similar tools. For a tool that performs sentiment analysis and attribution, more context about what constitutes 'notable' statements or how results are structured would improve 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?

Schema description coverage is 100% with the single parameter 'company_id' well-documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema (no format hints, examples, or constraints). Since the schema does the heavy lifting, the baseline score of 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 verb 'Get' and resource 'notable management statements' with additional features 'sentiment analysis and source attribution', making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_company_narrative' or 'research_report' that might also provide management-related information.

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 one explicit usage guideline: 'Requires Advisor tier' indicating a prerequisite access level. However, it doesn't specify when to use this tool versus alternatives like 'get_company_narrative' or 'research_report', nor does it provide context about what makes these statements 'notable' or when sentiment analysis is particularly useful.

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 provided, the description carries the full burden. It indicates a read-only operation ('List') and specifies the data fields returned, but does not disclose behavioral traits like rate limits, authentication needs, or pagination. It adds basic context but lacks depth for a tool with zero annotation coverage.

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 a single, efficient sentence that front-loads the purpose ('List all available markets') and includes essential details (supported by EquiVault, fields returned). Every word adds value without redundancy, making it appropriately sized and well-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?

Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is complete enough for basic understanding. However, it lacks details on output format, error handling, or integration context, which could be helpful despite the simplicity.

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 tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately does not discuss parameters, earning a baseline score of 4 for not adding unnecessary information beyond the empty schema.

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 explicitly states the action ('List all available markets') and the resource ('markets (exchanges) that EquiVault supports'), with specific details about the returned fields (code, name, country, currency, MIC). It clearly distinguishes this tool from siblings by focusing on market/exchange data rather than company analysis, alerts, or financial metrics.

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 context by specifying it lists 'all available markets' supported by EquiVault, suggesting it should be used to retrieve exchange information. However, it does not explicitly state when not to use it or name alternatives among siblings, such as tools for company data or alerts.

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 full burden. It states it retrieves data ('Get'), implying a read-only operation, but doesn't disclose behavioral traits like authentication needs, rate limits, data freshness, or return format. For a tool with no annotations, this leaves significant gaps in understanding its behavior.

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 a single, efficient sentence that front-loads the core purpose with zero wasted words. It's appropriately sized for a straightforward data retrieval tool.

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 no annotations and no output schema, the description is incomplete. It doesn't explain what metrics/KPIs are returned, their format, or any limitations (e.g., historical depth, company coverage). For a tool with rich sibling context, more detail is needed to guide effective use.

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%, so the schema fully documents parameters (company_id, period_from, period_to). The description adds no additional meaning beyond implying time-series data, which is already covered by the schema's date parameters. Baseline 3 is appropriate as the schema does the heavy lifting.

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 ('Get') and resource ('financial metrics and key performance indicators for a company over time'), making the purpose evident. It distinguishes from siblings like 'get_financials' by specifying 'metrics and KPIs' rather than raw financial data, though the distinction could be more explicit.

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?

No guidance is provided on when to use this tool versus alternatives like 'get_financials' or 'get_company'. The description implies it's for time-series metrics, but lacks explicit when/when-not instructions or named alternatives, leaving usage context unclear.

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 states 'Get pre-computed analytics', implying a read-only operation, but doesn't disclose behavioral traits like authentication needs, rate limits, data freshness, or error conditions. This is a significant gap for a tool with no annotation coverage.

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 a single, efficient sentence that front-loads the purpose and lists key metrics. Every word earns its place, with no redundancy or wasted space.

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 no annotations, no output schema, and a simple input schema, the description is minimally adequate but incomplete. It covers what analytics are returned but lacks context on behavior, errors, or output format, which is problematic for a tool with no structured safety or output information.

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%, so the schema already documents the 'portfolio_id' parameter. The description adds no additional meaning about the parameter (e.g., format, where to find it, or examples). Baseline 3 is appropriate when the schema does the heavy lifting.

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 'Get' and the resource 'pre-computed analytics for a portfolio', with specific metrics listed (total return, Sharpe ratio, etc.). It distinguishes this from sibling tools that focus on companies, alerts, or other resources, though it doesn't explicitly contrast with 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?

No guidance is provided on when to use this tool versus alternatives. While it's implied this is for portfolio analytics, there's no mention of prerequisites (e.g., needing an existing portfolio) or comparisons to other portfolio-related tools (none are listed in siblings).

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 but provides minimal behavioral context. It implies a read-only operation ('Get') but doesn't disclose data freshness, rate limits, authentication needs, or output format. The mention of 'evolution' hints at temporal data, but specifics like date ranges or update frequency are missing.

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 a single, efficient sentence with zero waste. It front-loads the core purpose and includes specific details (types of evolution) without unnecessary elaboration, making it easy to parse quickly.

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 tool with 1 parameter, 100% schema coverage, and no output schema, the description is minimally adequate. It states what the tool does but lacks context on usage, behavioral traits, or output, leaving gaps in understanding how to effectively apply it compared to siblings.

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%, so the schema fully documents the 'company_id' parameter. The description adds no additional parameter semantics beyond implying it's for risk factor evolution, which is already inferred from the tool's purpose. Baseline 3 is appropriate as the schema handles parameter documentation.

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 ('Get the evolution') and resource ('risk factors disclosed in a company's filings'), specifying the types of evolution tracked (new, ongoing, resolved, elevated). It distinguishes from generic company tools like 'get_company' but doesn't explicitly differentiate from similar analysis tools like 'analyze_company' or 'get_signal_trends'.

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?

No guidance on when to use this tool versus alternatives is provided. It doesn't mention prerequisites (e.g., needing a company ID from 'search_companies'), exclusions, or compare to siblings like 'get_signal_trends' or 'analyze_company' for risk analysis.

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 provided, the description carries the full burden of behavioral disclosure. It states what data is retrieved but does not mention critical aspects like whether this is a read-only operation, potential rate limits, authentication requirements, or the format of the returned data. For a tool with zero annotation coverage, this is a significant gap in 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the key action and resource, making it easy to parse quickly. Every part of the sentence contributes to understanding the tool's function.

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 tool with one parameter and no output schema, the description adequately covers the basic purpose. However, it lacks details on behavioral traits (e.g., read-only status, data format) and usage guidelines relative to siblings, which are important given the server's many financial data tools. The absence of annotations and output schema increases the need for more contextual information in the description.

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 100% description coverage, with the 'company_id' parameter clearly documented as 'Company ID from search_companies'. The description does not add any additional meaning or context beyond this, such as explaining how the ID is used or any constraints. Given the high schema coverage, a baseline score of 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 ('Get') and the specific resource ('revenue and operating-income breakdown by business segment for a company'), making the purpose immediately understandable. However, it does not explicitly differentiate this tool from sibling tools like 'get_financials' or 'get_company', which might also provide financial data, leaving room for ambiguity.

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 versus alternatives, such as 'get_financials' or 'get_company', which could offer overlapping or related financial information. It lacks explicit instructions on prerequisites, context, or exclusions, leaving the agent to infer usage based on the tool name alone.

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 full burden. It mentions 'Get' (implying read-only) and lists dashboard components, but doesn't disclose behavioral traits like authentication needs, rate limits, response format, or whether it's real-time vs cached. For a tool with no annotations, this leaves significant gaps.

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?

Single sentence, front-loaded with the core purpose ('Get portfolio-wide signal dashboard'), followed by specific components. Zero waste—every phrase adds value. Efficiently structured for quick comprehension.

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 no annotations, no output schema, and moderate complexity (dashboard with multiple data types), the description is incomplete. It lists components but doesn't explain return structure, data freshness, or error handling. For a tool with rich sibling context, more detail is warranted.

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 tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description adds no parameter information, which is acceptable since there are no parameters to document. No compensation is needed.

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's purpose: 'Get portfolio-wide signal dashboard' with specific components (recent signals, unread counts, per-company breakdown). It distinguishes from siblings like get_signals (general signals) and get_signal_summary (summary rather than dashboard), though not explicitly named. The verb 'Get' is appropriate for a read operation.

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?

No explicit guidance on when to use this tool versus alternatives like get_signals, get_signal_summary, or get_trending_signals. The description implies it's for portfolio-wide overviews, but doesn't specify contexts, prerequisites, or exclusions. Usage is inferred rather than stated.

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 mentions pagination support, which is useful behavioral context. However, it does not disclose other traits like rate limits, authentication needs, error handling, or what 'detected signals' specifically entail beyond the examples given, leaving gaps in 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 concise with two sentences that efficiently cover the tool's purpose and pagination support. It is front-loaded with the main functionality, though it could be slightly more structured by explicitly listing key features or constraints.

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 no annotations and no output schema, the description provides basic context but lacks details on return values, error conditions, or deeper behavioral aspects. It is minimally adequate for a read operation but incomplete for full agent understanding, especially without output schema guidance.

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%, so the schema fully documents parameters like company_id, page, and limit. The description adds no additional parameter semantics beyond what the schema provides, such as clarifying the types of signals or how pagination works in practice. Baseline 3 is appropriate as the schema does the heavy lifting.

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's purpose: 'Get detected signals for a specific company' with examples like earnings surprises and guidance changes. It specifies the resource (signals) and verb (get), but does not explicitly differentiate from sibling tools like get_signal_summary or get_signal_dashboard, which might offer similar functionality.

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 context by mentioning 'for a specific company' and 'supports pagination', suggesting it's for retrieving paginated signal data per company. However, it lacks explicit guidance on when to use this tool versus alternatives like get_signal_summary or get_signal_trends, leaving the choice ambiguous.

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 of behavioral disclosure. It mentions the tool returns a 'count-based summary' with breakdowns, but does not specify whether this is a read-only operation, requires authentication, has rate limits, or details the response format. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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 a single, efficient sentence that front-loads the core purpose ('Get a count-based summary of signals for a company') and adds specific details ('breakdowns by type and severity, plus unread count') without unnecessary elaboration. Every word contributes to understanding the tool's function.

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 complexity (simple single-parameter query), high schema coverage (100%), and lack of output schema, the description is minimally adequate. It explains what the tool returns but does not cover behavioral aspects like safety or performance, which are important for a tool with no annotations. It meets basic needs but lacks depth for full contextual understanding.

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 100% description coverage, with the 'company_id' parameter documented as 'Company ID from search_companies'. The description does not add any additional meaning beyond this, such as format examples or constraints, so it meets the baseline score of 3 where the schema does the heavy lifting.

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's purpose: 'Get a count-based summary of signals for a company' with specific breakdowns by type, severity, and unread count. It uses a specific verb ('Get') and resource ('signals for a company'), but does not explicitly differentiate from sibling tools like 'get_signals' or 'get_signal_dashboard', which likely provide different views of signals 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 provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools like 'get_signals' or 'get_signal_dashboard', nor does it specify contexts or prerequisites for usage, leaving the agent to infer appropriate scenarios based on the tool name alone.

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 provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves trends but doesn't mention whether this is a read-only operation, what permissions are needed, rate limits, or the format of returned data. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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 a single, efficient sentence that front-loads the core purpose and includes the optional parameter details. There is no wasted verbiage, and every word contributes directly to understanding the tool's function.

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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'signal activity trends' entail, how data is returned (e.g., time series format), or any error conditions. For a tool with no structured behavioral or output information, the description should provide more context to be fully helpful.

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 description coverage is 100%, so the schema fully documents the single parameter 'window' with its allowed values. The description adds no additional semantic context beyond what's in the schema, such as default behavior if 'window' is omitted or how trends are aggregated. This meets the baseline for high schema coverage.

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 'Get' and resource 'time-bucketed signal activity trends across your followed portfolio', which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'get_signal_dashboard', 'get_signals', or 'get_signal_summary', which appear related but have different scopes.

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 versus alternatives. It mentions 'your followed portfolio' but doesn't clarify prerequisites or contrast with sibling tools like 'get_signal_dashboard' or 'get_signal_summary', leaving the agent to guess based on tool names alone.

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 full burden. It mentions 'real-time' which is useful behavioral context, but doesn't disclose rate limits, authentication needs, data freshness guarantees, or what happens with invalid tickers. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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 a single, efficient sentence that front-loads the core functionality. Every word earns its place with no redundancy or unnecessary elaboration, making it optimally concise for this simple tool.

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 simplicity (1 parameter, 100% schema coverage, no output schema) and lack of annotations, the description is minimally adequate but incomplete. It doesn't address return format, error handling, or how it differs from sibling tools, leaving the agent with gaps despite the straightforward nature.

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% with the single parameter 'tickers' fully documented in the schema. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples of valid symbols, no mention of maximum number of tickers). Baseline 3 is appropriate when schema does the heavy lifting.

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 'Get' and resource 'real-time stock quotes' with scope 'for one or more ticker symbols', making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_company' or 'get_financials' which might provide overlapping financial data, so it doesn't reach the highest tier of sibling differentiation.

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 versus alternatives. With many sibling tools available (e.g., 'get_company', 'get_financials', 'get_metrics'), there's no indication whether this is for price-only data or broader financial information, nor any prerequisites or exclusions mentioned.

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 of behavioral disclosure. It states the tool lists profiles but doesn't cover critical aspects like whether it's a read-only operation, if it requires authentication, rate limits, pagination, or error handling. For a tool with zero annotation coverage, this leaves the agent with insufficient information about how the tool behaves in practice.

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 two sentences that are front-loaded and efficient. The first sentence states the core purpose, and the second adds useful context about what profiles define. Every word earns its place with no redundancy or fluff.

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 low complexity (0 parameters, no annotations, no output schema), the description is adequate but not complete. It explains what profiles are but misses behavioral details like safety, performance, or integration with other tools. For a simple list operation, it meets minimum viability but could be more informative.

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 with 100% coverage, so no parameter documentation is needed. The description adds value by explaining what the tool returns ('investment strategy profiles' and 'screening criteria'), which compensates for the lack of an output schema. This goes beyond the schema, earning a high score.

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's purpose: 'List all available investment strategy profiles (system + custom).' It specifies the verb ('List') and resource ('investment strategy profiles'), and distinguishes between system and custom profiles. However, it doesn't explicitly differentiate from sibling tools like 'screen_companies' or 'get_signals', which might also involve strategy-related operations, keeping it from a perfect score.

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 versus alternatives. It doesn't mention prerequisites, context (e.g., for portfolio setup or analysis), or exclusions. With many sibling tools like 'screen_companies' or 'get_signals' that might overlap in investment strategy contexts, this lack of differentiation is a significant gap.

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 provided, the description carries full burden but only states it retrieves data without disclosing behavioral traits like rate limits, authentication needs, data freshness, or response format. It mentions 'right now' suggesting real-time data, but this is vague and insufficient for a tool with no annotation coverage.

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 a single, efficient sentence that front-loads the core purpose with no wasted words. It's appropriately sized for a simple tool with one parameter.

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 no annotations, no output schema, and a simple input schema, the description is incomplete. It lacks details on return values, data format, error handling, or operational constraints, making it inadequate for effective tool invocation despite the tool's 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?

Schema description coverage is 100% for the single parameter 'limit', so the schema fully documents it. The description adds no parameter-specific information beyond what's in the schema, meeting the baseline score of 3 for high schema coverage.

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 ('Get') and resource ('cross-company trending signals') with scope ('across all tracked companies'). It specifies what the tool does but doesn't explicitly differentiate from sibling tools like 'get_signals' or 'get_signal_trends' that might have overlapping functionality.

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 minimal usage guidance with 'right now' implying real-time data, but offers no explicit when-to-use instructions, alternatives, or exclusions compared to siblings like 'get_signals' or 'get_signal_trends'. It lacks context on prerequisites or limitations.

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 provided, the description carries full burden for behavioral disclosure. It mentions filtering capabilities but doesn't describe important behavioral aspects: whether this is a read-only operation, what format the list returns (e.g., pagination, sorting), authentication requirements, rate limits, or what happens when both filters are provided. For a list operation with zero annotation coverage, this leaves significant behavioral gaps.

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 perfectly concise - two sentences with zero waste. The first sentence establishes the core purpose, the second explains the filtering options. Every word earns its place, and the information is front-loaded with the main purpose stated first.

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 (listing with optional filters), 100% schema coverage but no annotations and no output schema, the description is minimally adequate. It covers what the tool does and the filtering options but leaves important behavioral aspects undocumented. For a list operation, the agent would need to know about pagination, return format, and other behavioral characteristics that aren't addressed.

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%, so the schema already fully documents both parameters. The description adds minimal value beyond the schema - it restates that company_id filters by company and followed filters by followed companies, but doesn't provide additional context about how these interact or which takes precedence. The baseline 3 is appropriate when the schema does the heavy lifting.

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 'list' and resource 'investment briefs', making the purpose immediately understandable. However, it doesn't distinguish this tool from potential siblings like 'get_brief' (which presumably retrieves a single brief) or 'research_report' (which might be similar content). The description is specific about what it lists but lacks sibling differentiation.

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 implied usage guidance by mentioning two filtering options (company_id and followed), suggesting when to use each parameter. However, it doesn't explicitly state when to choose this tool over alternatives like 'get_brief' (for single briefs) or 'search_companies' (for broader company searches). No explicit when-not-to-use guidance or alternative tool references are 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?

With no annotations provided, the description carries full burden for behavioral disclosure. It only mentions filtering capabilities but fails to describe important behavioral aspects like whether this is a read-only operation, pagination behavior, rate limits, authentication requirements, or what the return format looks like. This leaves significant gaps for an agent to understand how to properly invoke and interpret results.

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 perfectly concise - a single sentence that immediately states the purpose and key capabilities without any wasted words. It's front-loaded with the core function and efficiently lists the filtering options, making it easy for an agent to quickly understand what the tool does.

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 list operation with no annotations and no output schema, the description is insufficiently complete. It doesn't describe the return format, pagination, sorting options, or any behavioral constraints. While the schema covers parameters well, the overall context for proper tool usage remains incomplete, especially given the lack of output information.

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 100% schema description coverage, the schema already documents all three parameters thoroughly with descriptions and enums. The description adds minimal value by listing the filterable fields (company_id, type, status) but doesn't provide additional semantic context beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.

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 ('List') and resource ('media items') with specific examples (earnings calls, podcasts, etc.), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_briefs' or 'get_company' which might also retrieve media-related information, preventing a perfect score.

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 versus alternatives. It mentions filtering capabilities but doesn't specify scenarios where this tool is preferred over other list/search tools on the server, nor does it mention prerequisites or exclusions for usage.

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 provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's scope (multiple research components) and access constraints (tier-based availability), but lacks details on rate limits, authentication needs, response format, or whether it's read-only (implied by 'Get' but not explicit).

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 front-loaded with the core purpose, followed by specific components and access notes in a single, efficient sentence. Every phrase adds value without redundancy, making it appropriately sized and well-structured for quick comprehension.

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 (aggregating multiple data sources) and no annotations or output schema, the description does well by outlining components and access constraints. However, it could improve by hinting at the return structure or error handling, leaving some gaps for a tool with no output 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 description coverage is 100% for the single parameter, so the baseline is 3. The description adds value by explaining the optional portfolio_id's effect ('portfolio analytics are included'), enhancing understanding beyond the schema's basic documentation, though it doesn't provide format examples or deeper semantics.

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's purpose with specific verbs ('Get a daily research summary') and resources ('signal dashboard, trending signals, recent briefs for followed companies, portfolio analytics'), distinguishing it from siblings like get_signal_dashboard or get_trending_signals by bundling multiple components into one comprehensive briefing.

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 clear context for usage ('daily research summary') and mentions tier-based access restrictions, but does not explicitly state when to use this tool versus alternatives like get_signal_dashboard or get_trending_signals individually, nor does it outline exclusions or prerequisites beyond tier limitations.

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 full burden. It mentions the tool builds a report 'in one call' but lacks details on behavioral traits like rate limits, authentication requirements, processing time, or error handling. The description does not contradict annotations, but it fails to disclose critical operational aspects for a comprehensive tool.

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 front-loaded and efficient, using a single sentence that lists key components without redundancy. Every phrase adds value, such as specifying 'full deep-dive' and 'ready for rendering as a report,' making it appropriately sized for the tool's complexity.

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 complexity (building a comprehensive report) and lack of annotations or output schema, the description is incomplete. It outlines what the tool does but misses details on output format, error cases, or dependencies. However, it adequately covers the high-level purpose and scope, making it minimally viable but with clear gaps.

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 100% description coverage, with company_id documented as 'Company ID from search_companies.' The description does not add meaning beyond this, as it does not explain parameter usage or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description does not compensate but also does not detract.

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 explicitly states the tool's purpose: 'Build a comprehensive research report for a company' with specific components listed (profile, financials, metrics, narrative, recent signals, related briefs). It clearly distinguishes from siblings by emphasizing 'all in one call' versus tools like get_financials or get_metrics that fetch individual components.

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 context by specifying 'all in one call, ready for rendering as a report,' suggesting it should be used when a consolidated report is needed rather than separate API calls. However, it does not explicitly state when not to use it or name alternatives among siblings, such as using get_company for basic info instead.

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 of behavioral disclosure. It mentions that the tool 'returns companies matching your criteria', which implies a read-only operation, but doesn't specify whether it's paginated, rate-limited, requires authentication, or what the return format looks like (e.g., list of names, detailed objects). For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.

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 concise and front-loaded, consisting of two clear sentences that state the action and result without unnecessary details. Every sentence contributes directly to understanding the tool's function, though it could be slightly more structured by explicitly mentioning the input parameter.

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 of screening operations, no annotations, and no output schema, the description is incomplete. It doesn't explain what the return values include (e.g., company names, IDs, financial metrics), how results are formatted, or any limitations (e.g., maximum filters, performance considerations). This leaves the agent with insufficient context to use the tool effectively.

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 description coverage is 100%, with the 'filters' parameter fully documented in the schema as a JSON string of screening filters. The description adds minimal value beyond this, only implying that filters are 'financial' and used for 'screening', which doesn't provide additional syntax or format details. This meets the baseline for high schema coverage.

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's purpose: 'Screen companies using financial filters' specifies the verb (screen) and resource (companies), and 'Returns companies matching your criteria' indicates the outcome. However, it doesn't explicitly distinguish this from sibling tools like 'search_companies' or 'get_company', which limits differentiation.

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 versus alternatives. With many sibling tools available (e.g., 'search_companies', 'get_company', 'analyze_company'), there's no indication of when screening is preferred over searching or retrieving specific company data, nor any mention of prerequisites or exclusions.

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 mentions the search functionality and return format, but lacks details on behavioral traits such as rate limits, authentication needs, pagination, error handling, or whether it's a read-only operation. For a search tool with zero annotation coverage, this is a significant gap.

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 appropriately sized and front-loaded with two clear sentences: the first states the action and parameters, and the second specifies the return value. There is no wasted text, making it efficient and easy to parse.

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 low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and output but lacks depth in behavioral context and usage guidelines, which are important for effective tool selection in a crowded sibling set.

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 description adds minimal value beyond the input schema, which has 100% coverage. It reiterates that the 'query' parameter is for 'name, ticker symbol, or keyword', but the schema already describes this as 'Search term — company name, ticker symbol, or keyword'. No additional syntax, format, or constraints are provided, so the baseline score of 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 tool's purpose: 'Search for companies by name, ticker symbol, or keyword' specifies the verb (search) and resource (companies), and 'Returns a list of matching companies with their IDs' indicates the output. However, it doesn't explicitly differentiate from sibling tools like 'screen_companies' or 'get_company', which might offer similar functionality.

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?

No guidance is provided on when to use this tool versus alternatives. With many sibling tools (e.g., 'screen_companies', 'get_company'), the description lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage based on the name alone.

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 provided, the description carries the full burden. It discloses that the tool is a mutation ('update'), requires a specific tier ('Advisor tier'), and performs partial updates ('Only the fields you provide are changed'). However, it lacks details on permissions, error handling, or response format, leaving behavioral gaps for an agent.

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 two concise sentences with zero waste: the first states the purpose and partial update behavior, and the second specifies the tier requirement. It is front-loaded and efficiently structured, with every sentence adding value.

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 mutation tool with no annotations and no output schema, the description is moderately complete: it covers the purpose, partial update behavior, and tier requirement. However, it lacks details on error cases, response format, or side effects, which are important for an agent to use it correctly in context.

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 100% description coverage, so the baseline is 3. The description adds no specific parameter semantics beyond what the schema provides (e.g., it doesn't explain 'alert_id' format or 'threshold' units), but it does imply partial updates, which contextualizes parameter usage without detailing individual parameters.

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 'update' and the resource 'existing alert rule', distinguishing it from sibling tools like 'create_alert' and 'delete_alert'. It specifies that only provided fields are changed, which adds precision about the update behavior.

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 by stating 'Only the fields you provide are changed', suggesting partial updates, but it does not explicitly guide when to use this tool versus alternatives like 'create_alert' or 'delete_alert'. The mention of 'Requires Advisor tier' provides some context about prerequisites, but no explicit when/when-not guidance is given.

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