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

With no annotations, the description carries full burden. It discloses the tool updates stored portfolio (destructive mutate), returns updated metrics, and includes an example. It does not detail prerequisites or error conditions but provides sufficient behavioral 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?

The description is structured with Args, Returns, Example sections. It is front-loaded with the main action. While slightly verbose with the example, every sentence adds information and no waste is evident.

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 presence of an output schema, the return details are adequate. However, the description omits error conditions or validation and could clarify the relationship with 'optimize_portfolio' more explicitly. It is minimally complete.

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 0%, but the description explains all four parameters: name, method, target_return, and target_volatility, including constraints like target_return is for 'efficient_return' method. This adds clear value beyond the bare 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 it applies optimization and updates portfolio weights, specifying the optimization method. It distinguishes itself from the sibling 'optimize_portfolio' by noting the method is the same but this tool updates stored weights, effectively differentiating the action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for applying optimization and persisting results but does not explicitly state when to use this tool versus 'optimize_portfolio' or provide conditions for use. No exclusions or alternatives are 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. It explains that cloning creates a copy and optionally changes weights, and describes the return value as 'New portfolio information.' However, it omits details like permissions required, error conditions (e.g., source not found), or side effects on the source portfolio.

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 well-structured with a brief intro, Args list, Returns line, and a clear example. It is concise yet informative, with no unnecessary words.

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 presence of an output schema (context indicates 'Has output schema: true'), the description's brief mention of 'New portfolio information' is acceptable. However, it could mention constraints like source must exist or naming uniqueness, which would improve completeness for a tool with many 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?

The schema has no descriptions for parameters (0% coverage), and the description fully explains each parameter in the Args section, including the optional new_weights with its default behavior. This adds significant value 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 'Clone an existing portfolio, optionally with new weights.' It identifies the verb (clone) and resource (portfolio), and the context of testing allocation strategies distinguishes it from siblings like create_portfolio or update_portfolio_weights.

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 indicates the tool is for copying portfolios for testing different allocation strategies, and includes examples. However, it does not explicitly state when not to use it or compare it to alternatives like create_portfolio for new portfolios.

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 details the operation (comparison, retrieval) and return format (dictionary with portfolios, rankings, best_by_metric). However, it does not explicitly state it is read-only or mention any side effects, which is a minor 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 uses a clean structure with Args, Returns, and an Example section. Every sentence is purposeful, concise, 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 an output schema exists, the description adequately explains the return structure. For a comparison tool with one parameter, it covers all necessary aspects without overcomplicating.

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 param 'names' is described as 'List of portfolio names to compare.' This adds meaning beyond the schema's type (array of strings) and compensates for the 0% schema description coverage. The example further clarifies usage.

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 'Compare multiple portfolios side by side' and specifies retrieving metrics and ranking by KPIs. It differentiates from sibling tools like get_portfolio_metrics (single portfolio) and list_portfolios (listing only) by focusing on comparison.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for comparing multiple portfolios via the example and returns section, but does not explicitly state when to use this tool over alternatives or provide when-not conditions.

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 discloses key behaviors: persistent storage, return of metrics, and data source handling. It does not mention potential overwriting if name already exists or any rate limits, but covers the main behavioral traits.

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 well-structured with Args, Returns, and Example sections, but is lengthy. It could be slightly more concise while retaining 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?

For a tool with 10 parameters, 2 required, and an output schema, the description covers all parameters, return values, and provides multiple comprehensive examples, making it complete for agent invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description fully compensates by explaining each parameter in detail, including examples for symbols, weights, source options, and period format. It adds significant meaning beyond the raw 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 it creates a new portfolio and stores it in RefCache, with options for real, provided, or synthetic data. It distinguishes from siblings like clone_portfolio and delete_portfolio by focusing on creation from various data sources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit examples for different use cases (stock, crypto, synthetic) and explains source options. However, it does not explicitly state when not to use this tool or point to alternatives like generate_price_series for price generation only.

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 present, so the description bears full responsibility. It discloses irreversible deletion ('permanently removes'), which is critical. However, it does not mention potential side effects (e.g., affecting other data), authorization needs, or error handling behavior beyond the example's success case.

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 highly concise: two short paragraphs plus a clear code example. Every sentence serves a purpose—specifying action, permanence, parameter, return value, and usage example. No redundant information.

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 (one parameter, clear output schema example), the description covers purpose, parameter meaning, return value, and a usage example. It lacks error handling details or mention of whether the portfolio must exist, but for a basic delete tool, it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% coverage for the 'name' parameter, so the description's docstring ('The portfolio name to delete.') adds essential meaning beyond the schema's type-only definition. The example also clarifies usage. However, no additional constraints like format or existence checks are mentioned.

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?

Description clearly states 'Delete a stored portfolio. Permanently removes a portfolio from storage.' The verb 'delete' and resource 'portfolio' are explicit, and the specific action (permanent removal) distinguishes it from sibling tools like clone_portfolio or create_portfolio.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for removing portfolios but does not explicitly state when to use this tool versus keeping portfolios, nor does it mention prerequisites or safety checks like ensuring the portfolio exists. The permanence is noted, but no exclusion criteria 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, the description fully explains that large results are cached, scenarios are generated randomly using provided ranges, and the return dictionary includes ref_id, preview, and summary. No contradictions or hidden behaviors.

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 well-structured with a clear first line, usage hint, and parameter list. However, the parameter list is somewhat verbose and could be trimmed for conciseness without losing 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 6 parameters, one required, no annotations, and an output schema, the description thoroughly covers inputs, caching behavior, and return structure. No missing critical information for an agent to use the tool correctly.

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?

Despite 0% schema description coverage, the description includes an 'Args:' section that explains each parameter's meaning and defaults (e.g., base_symbols as asset symbols, return_range as annual return min/max). This adds substantial value beyond the raw 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 verb 'Generate' and the resource 'multiple portfolio scenarios,' with explicit mention of varying parameters. It distinguishes itself from siblings by referencing caching and 'get_cached_result' for pagination.

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 notes usefulness for testing optimization strategies and instructs to use 'get_cached_result' for full data, providing usage context. However, it does not explicitly list when to avoid this tool or mention alternative tools for different tasks.

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

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

With no annotations, the description carries full burden. It discloses the model (GBM), caching for large results, and pagination via get_cached_result. It also notes that results include a preview and reference ID. However, it does not mention error conditions, rate limits, or any external dependencies, slightly reducing 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 well-structured with clear sections (intro, args, returns, example) and uses concise language. Every sentence adds value, and the example demonstrates typical usage. There is no redundancy or unnecessary detail.

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 (7 parameters, caching behavior, output with multiple fields), the description is complete. It explains input parameters thoroughly and describes the return dictionary with all keys. The presence of an output schema signal but actual schema not provided is mitigated by the description's own return documentation. No gaps remain for an AI agent to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must fully explain parameters. It provides detailed explanations for all 7 parameters, including defaults, types, and examples (e.g., symbols list, annual_returns dict). This adds substantial meaning beyond the bare schema types and defaults, making it easy for an AI agent to understand each parameter's purpose.

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 generates synthetic price series using Geometric Brownian Motion. It defines the core functionality and customizable parameters. However, it does not explicitly differentiate from sibling generation tools like generate_portfolio_scenarios, which could lead to confusion about which to use for price-only 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 implicit usage guidance through examples and parameter explanations, indicating it's used for creating realistic stock price data. It mentions caching and pagination, which helps in subsequent steps. However, there is no explicit guidance on when not to use this tool or alternatives, such as when to prefer generate_portfolio_scenarios for portfolio-level 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?

No annotations provided, so description carries full burden. It explains caching behavior, pagination mechanics, preview strategies (sample, truncate, paginate), and that it depends on ref_id from other tools. Does not mention side effects or errors, but covers core behaviors well.

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?

Description is detailed and well-structured with sections (use cases, args, returns, example). However, it is slightly verbose; the example could be shortened. Still, it remains clear and organized.

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 schema descriptions, but an output schema (return dict explained), the description covers all necessary aspects: purpose, usage, parameters, return values, and examples. It is complete for an AI agent to understand and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (no descriptions in schema). Description compensates by explaining ref_id as tool output, page as 1-indexed with default null, and page_size with variable default. Adds meaning beyond type/null constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves a cached result with optional pagination. It distinguishes itself from siblings by specifying it works with ref_id from tools like generate_price_series, making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly lists three use cases: get preview, paginate through large data, and access specific pages. Provides code examples. Does not explicitly exclude misuses or compare to alternatives, but context is sufficient for correct selection.

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

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

No annotations are provided, so the description must disclose behavioral traits. It mentions caching behavior (ref_id, preview, pagination via get_cached_result) and that any input parameter can accept a ref_id. However, it does not explicitly state whether the tool is read-only or any side effects, leaving a 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 front-loaded with the purpose but includes a verbose caching behavior section that appears generic. The example adds value but lengthens the text. Every sentence has purpose, but the caching block could be shortened or linked to a shared reference.

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 simple tool (one parameter, clear output), the description covers the return format with an example and explains caching mechanics. It does not mention error cases (e.g., invalid portfolio name) but is otherwise complete for basic usage.

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% description coverage, so the description must compensate. It adds basic meaning by stating that 'name' is the portfolio name. While minimal, this is sufficient for a single parameter, and the example reinforces usage. No further constraints or format details are 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 it gets the correlation matrix for portfolio assets and calculates pairwise correlations based on daily returns. The example and distinction from the sibling get_covariance_matrix is implied by the function name, but the description explicitly mentions 'correlation' making it unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like get_covariance_matrix. The description does not specify prerequisites, such as requiring the portfolio to exist or have historical data. It only provides an example but no explicit 'when to use' or 'when not to use' advice.

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

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

The description discloses return structure (symbols, covariance_matrix, variances), caching behavior (ref_id, preview, pagination), and the effect of annualization. Since no annotations are provided, this is a thorough account of the tool's 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 includes a lengthy example and caching notes, which are useful but make it less concise. Could be streamlined without losing essential information.

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 and the presence of many sibling tools, the description covers return values, parameters, and caching adequately. It provides enough detail 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?

The description explains both parameters: name is the portfolio name, and annualized annualizes the covariance by multiplying by 252. This adds meaning beyond the schema, which only has defaults and types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it computes the covariance matrix for portfolio assets based on daily returns, using a specific verb and resource. However, it does not differentiate from sibling tools like get_correlation_matrix.

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, or when not to use it. The description only describes parameters without context for selection.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool retrieves data (read-only), lists returned fields, and includes an example. However, it does not mention authentication needs, rate limits, caching behavior, or potential side effects, which are gaps for a tool without annotation support.

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 well-organized with 'Args' and 'Returns' sections and a useful example. Slightly longer than minimal, but the example adds clarity. Each sentence contributes 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?

The tool has an output schema (indicated but not shown), so the description's return field list is adequate. Combined with the parameter description and example, it fully explains usage for a simple read operation. No critical gaps identified.

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% description coverage, so the description must compensate. It explains that the 'symbol' parameter accepts crypto symbols or CoinGecko IDs, with concrete examples. This adds significant meaning beyond the schema's bare type definition.

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 name 'get_crypto_info' clearly indicates retrieving information, and the description states 'Get detailed information about a cryptocurrency' with specific data points (price, market cap, volume, 24h changes). This distinguishes it from sibling tools like 'get_trending_coins' or 'search_crypto_coins' which serve different purposes.

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 is self-contained but does not explicitly compare to sibling tools or specify when to use this versus alternatives. It provides an example but no guidance on prerequisites or exclusion criteria, relying on implicit understanding from the tool's name.

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

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

The description includes caching behavior and return value structure, but fails to explicitly state that this is a read-only operation (no destructive hint). Given no annotations, the description should more clearly indicate it does not modify data.

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 overly long, including docstring formatting (Args, Returns, Example) and generic caching instructions that are not tool-specific. The core purpose is front-loaded, but the additional text could be trimmed or abstracted to improve conciseness.

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 simple nature of the tool (one parameter, clear output described), the description adequately covers what it does and what it returns. However, it could mention that the portfolio must exist before calling this 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 only parameter 'name' is fully explained as 'The portfolio name', adding meaning beyond the bare schema. Since schema coverage is 0% (no property descriptions), the description compensates well for the single parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it analyzes portfolio drawdowns by calculating maximum drawdown and drawdown periods, which is a specific action. However, it does not distinguish itself from sibling tools like 'get_portfolio_metrics' or 'get_correlation_matrix' that may also involve risk assessment.

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 such as 'get_portfolio_metrics' or 'run_monte_carlo'. It only mentions it is 'useful for risk assessment', which is too vague to inform tool selection.

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

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

No annotations are provided, so the description must disclose behavioral traits. It mentions caching behavior and preview size, which are helpful, but it does not explicitly state whether the tool is read-only or if it has side effects. Given the 'get' in the name, safety is implied but not confirmed, and no permissions or limitations are described.

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 well-structured with clear sections for Args, Returns, Example, and caching behavior. The example is useful. However, the inclusion of generic caching boilerplate that applies to all tools on the server adds unnecessary length. Overall, it is informative without being overly verbose.

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 and the presence of many related sibling tools, the description covers the main aspects: purpose, parameters, return structure, and an example. It does not explicitly differentiate from siblings, but the return structure and visualization focus provide sufficient context. The caching behavior also adds completeness for large datasets.

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% description coverage, so the description compensates well by explaining both parameters: 'name' as the portfolio name and 'num_points' as the number of points. This adds significant value beyond the raw schema, which only specifies types and defaults. However, it does not provide examples of valid values or constraints.

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 as generating efficient frontier data points for visualization. The verb 'generate' combined with the specific resource 'efficient frontier' makes the function clear. However, it does not explicitly distinguish this tool from siblings like 'optimize_portfolio' or 'run_monte_carlo', though the visualization focus is implied.

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 some context by mentioning 'for visualization', but it lacks explicit guidance on when to use this tool versus alternatives. No exclusions or specific conditions are stated. The agent must infer usage from the general context of portfolio optimization 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 provided, so description carries full burden. It details return structure, caching behavior (ref_id, preview, pagination), and that any parameter can accept ref_id. This is comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections (args, returns, example, caching behavior). However, the caching block is somewhat verbose and could be streamlined if generic across tools. Not overly long, but not maximally concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all aspects: purpose, when to use, parameter explanation, output structure with example, caching behavior. Given the tool's simplicity (1 param, no annotations), the description is fully complete.

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 has 1 parameter 'name' with 0% schema description coverage. The description explains 'The portfolio name' and provides an example ('tech_stocks'), adding meaning beyond the raw schema. However, no format constraints or source hints are given.

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?

Clearly states it gets metrics for each individual stock in a portfolio, distinguishing it from get_portfolio_metrics which gives overall metrics. Uses specific verb 'Get' and resource 'individual stock 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?

Explicitly says 'useful for identifying best/worst performers', implying diagnostic use case. While it does not mention when not to use or alternatives, the sibling context makes the distinction clear enough.

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

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

With no annotations, the description carries full burden. It discloses it is a retrieval operation ('Get') and mentions error on not found, but does not explicitly state non-destructive behavior or any other behavioral traits like caching, auth needs, or rate limits.

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?

Well-structured: brief opening sentence, then Args/Returns/Example sections. No unnecessary text; every sentence adds value. Example is concise and illustrative.

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 param, output schema exists), the description covers key aspects: purpose, input, output format with example, and error handling. Could add more context on output schema structure or prerequisite (portfolio must exist).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the description only repeats 'The portfolio name.' without adding constraints, format, or referential context (e.g., exact match, case sensitivity). The example provides a concrete value but minimal semantic enrichment.

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 'Get detailed information about a stored portfolio' and specifies the scope as including 'allocation, metrics, and settings,' which differentiates it from sibling tools like get_portfolio_metrics or list_portfolios.

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 such as get_portfolio_metrics or compare_portfolios. The description implies use for comprehensive details but lacks explicit differentiation or when-not-to-use advice.

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?

Despite no annotations, the description reveals key behaviors: it calculates and returns a detailed dictionary with multiple metrics, mentions caching with ref_id and pagination via get_cached_result. However, it does not state that it is read-only or if any side effects exist.

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 well-structured with Args, Returns, and Example sections. The caching behavior block adds length but provides useful context. Could be slightly more concise, but it earns its place.

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 (multiple return fields), the description is comprehensive: it lists all return keys, explains caching, and provides an example. The output schema exists but the description adds full 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 single parameter 'name' is thoroughly described as 'The portfolio name.' in the Args section, and the example provides context. This fully compensates for the lack of schema-level description (0% 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 'Get comprehensive metrics for a portfolio.' with a specific verb and resource, and lists the included metrics. This distinguishes it from siblings like get_portfolio (basic info) and get_individual_stock_metrics (stock-level).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for obtaining full portfolio metrics but does not explicitly state when not to use it or provide comparisons with sibling tools. No guidance on prerequisites or exclusions, so it is only minimally adequate.

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 responsibility for behavioral transparency. It discloses caching behavior (ref_id, pagination via get_cached_result) and return structure, but does not mention any side effects or read-only nature. The caching info adds valuable context beyond what annotations would provide.

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 well-structured with sections for Args, Returns, Example, and Caching Behavior. Every sentence adds value, and the example is concise yet illustrative. No redundant 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 presence of an output schema (though not shown in the input, context indicates it exists), the description still provides a detailed Returns section. It covers caching and pagination. A minor gap is the lack of error handling or prerequisite mention (e.g., portfolio existence), but overall it is sufficiently complete for a straightforward data retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, but the description compensates fully by explaining each parameter: name, return_type (with explicit enum-like values), and as_percentage (with meaning). This adds significant semantic value beyond the bare 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 as 'Get returns data for a portfolio' and specifies different return types (daily, log, cumulative). It distinguishes itself from sibling tools like get_portfolio_metrics by focusing specifically on return calculations, and the examples further clarify use cases.

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 examples and explains each parameter clearly, including different return_type options and the as_percentage flag. However, it does not explicitly contrast with alternative tools (e.g., get_portfolio_metrics) or state when not to use this tool, which would enhance guidance.

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 states the tool returns sample data (read operation) with realistic parameters, implying no side effects or destructive actions. It does not elaborate on data limits or mutability, but the simplicity of the tool makes this adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences plus a bullet point. The main purpose is stated in the first sentence ('get pre-defined sample portfolio data for quick testing'), making it front-loaded. No unnecessary words.

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 (no parameters, clear output schema), the description is complete. It specifies the tool returns sample portfolio data for testing, and ties it to a sibling tool (create_portfolio). The output schema exists and is referenced, so explanation of return values is unnecessary.

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 zero parameters, so the description does not need to add parameter detail. According to the guidelines, for 0 parameters the baseline score is 4. The description adds value by specifying the output is a dictionary ready for create_portfolio().

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 pre-defined sample portfolio data for testing. It uses a specific verb ('get') and resource ('sample portfolio data'), distinguishing it from sibling tools like create_portfolio which actually create portfolios.

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 indicates usage for 'quick testing' and explicitly mentions the output is 'ready for use with create_portfolio()', providing clear guidance on when to use this tool (testing) and how to chain it with another tool. It does not specify when not to use it, but the context is sufficient.

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

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

The description explains the read-only behavior of fetching trending data, including the return structure (coins, fetched_at). Without annotations, this adequately conveys the tool's behavior and side-effect-free nature.

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, front-loaded with the main purpose, and includes a helpful example in just a few lines. Every sentence adds 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 parameterless tool with a simple output, the description fully covers what the tool does, what it returns, and how to use it. No additional information is necessary.

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 zero parameters, the schema coverage is 100%. The description adds no parameter details as none are needed, meeting the baseline expectation for a no-parameter tool.

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 trending cryptocurrencies from CoinGecko, specifying the 24-hour timeframe. This distinguishes it from sibling tools like search_crypto_coins or list_crypto_symbols.

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 notes the tool is 'useful for discovering popular assets to analyze', providing a clear use case. However, it does not explicitly mention when to avoid using it or alternatives, but the simplicity makes this less critical.

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 should disclose read-only nature, performance, or failure modes. It implies read-only but does not explicitly state safety or side effects. It provides return details but lacks behavioral completeness.

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 very concise: two sentences plus a returns line. No wasted words. Front-loaded with the core action.

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 parameters and presence of an output schema, the description covers the essential purpose and returns. It is complete enough for this simple tool, though it could mention typical use cases.

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 zero parameters and schema coverage is 100%, so baseline is 4. No additional parameter info 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 checks server health status and lists specific return values (cache status, stored portfolio count). It is a distinct operation among sibling tools focused on portfolio actions.

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 vs. alternatives. The description does not mention contexts such as diagnostics or monitoring, nor does it exclude other 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 provided; description discloses return format and example but doesn't explicitly state it's read-only or safe. Adequate but not rich.

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?

Description includes docstring-style Returns and Example sections, which is slightly verbose. Could be more concise while retaining 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?

Fully describes return value (symbols, count, usage), provides example, and integrates with create_portfolio. Output schema exists to cover details.

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?

No parameters in schema; coverage is 100%. Description adds no param info, but baseline for zero-param tools is 4. No need for further explanation.

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?

Description clearly states the tool lists supported crypto symbols and CoinGecko IDs. It differentiates from siblings like search_crypto_coins and get_crypto_info.

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?

Description implies use for getting symbols to use with create_portfolio via the 'usage' field, but lacks explicit when-to-use or when-not-to-use compared to alternatives.

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 for behavioral disclosure. It describes the output structure but does not mention side effects, authorization requirements, rate limits, or data freshness. The description meets basic transparency but lacks deeper details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise at about 100 words, including an example. It is well-structured: a clear first-line purpose, followed by details, then an illustrative example. Every sentence adds value 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 tool's simplicity (0 params, simple list operation) and the presence of an output schema (not shown but indicated), the description covers the essential aspects: what it returns (list of portfolios with metrics), including count. It provides sufficient context for the agent to understand the tool's action.

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 zero parameters, so the description does not need to explain parameters. According to guidelines, a baseline of 4 is appropriate when no parameters exist. The description does not add any parameter information, but none 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 'List all stored portfolios with summary information,' specifying the verb, resource, and scope. It distinguishes from sibling tools like get_portfolio (single portfolio) and create_portfolio, and includes an example that reinforces its purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for listing all portfolios, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., get_portfolio for a specific portfolio) or when not to use it. The usage context is implied by sibling tool names but not directly 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, but the description discloses the use of numerical optimization (scipy), the return structure, and includes caching behavior (preview, pagination). It does not mention side effects, but this appears to be a read-only computation 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 well-structured with Args, Returns, and Example sections. The first sentence is clear. Some redundancy exists, and the caching note adds length, but overall it's efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

All parameters and return values are documented. Examples illustrate usage. The caching behavior is noted. Missing is a mention of prerequisites (e.g., portfolio must exist), but the tool is still sufficiently complete.

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?

Despite 0% schema description coverage, the description provides full meaning for all four parameters: name, method (with enum-like list), target_return, and target_volatility. Conditions and defaults are clearly stated.

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 'Optimize portfolio weights using Efficient Frontier' and details four optimization methods. It distinguishes from sibling tools like apply_optimization and get_efficient_frontier by focusing on computing optimal weights without applying them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use each method and what parameters are needed. It lacks explicit guidance on alternatives, but the context of sibling tools provides implicit differentiation.

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

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

Without annotations, the description carries full burden. It discloses computational intensity as a behavioral trait, but does not mention side effects, permissions, or data sources. Nonetheless, it provides sufficient context for a simulation 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 well-structured with an intro, a performance note, clear Arg/Returns sections, and an example. Every sentence adds value 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 and the presence of an output schema, the description fully explains what the tool does, its performance implications, and the structure of its return values, including an example that clarifies usage. It is sufficient to differentiate from 25+ sibling tools.

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 no descriptions for its parameters (0% coverage), but the description's Args block explains that 'name' is the portfolio name and 'num_trials' is the number of simulations with a default of 5000, adding essential meaning beyond the bare 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 runs Monte Carlo simulations to find optimal portfolios by generating random weight combinations and evaluating risk/return. It distinguishes itself from the Efficient Frontier method, implying this is for random sampling approaches, which differentiates it from sibling tools like 'optimize_portfolio' or 'get_efficient_frontier'.

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 notes that the tool is computationally intensive and advises using the Efficient Frontier method for large num_trials, providing clear guidance on when not to use this tool and a specific alternative.

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 responsibility. It details the return structure (coins list, count, fetched_at) and provides an example. It does not mention rate limits or authentication, but the tool appears simple and read-only, and the description sufficiently conveys 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 but complete, with clear sections for purpose, parameters, returns, and an example. Every sentence adds value, and the important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (single parameter, no nested objects) and the fact that an output schema is described in the returns section, the description provides all necessary context for an agent to use the tool effectively, including input format and output structure.

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 only parameter, query, is well-explained with a description and concrete examples ('bitcoin', 'defi', 'layer 2'), adding significant value beyond the bare schema definition. Schema coverage is 0%, so the description compensates fully.

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?

Clearly states the tool searches for cryptocurrencies by name, symbol, or keyword. It explicitly distinguishes itself by mentioning its utility for discovering coin IDs to use with create_portfolio, differentiating it from siblings like get_crypto_info or get_trending_coins.

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 gives a specific use case (finding coin IDs for create_portfolio) and implies appropriate scenarios via the example. However, it does not explicitly exclude cases where other tools might be better, such as using get_crypto_info for detailed coin data once the ID is known.

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 exist, so description must cover behavioral traits. It mentions recalculation of metrics and a constraint (weights sum to 1.0), but does not disclose mutation permanence, required permissions, or side effects on other portfolio attributes.

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?

Well-structured with Args, Returns, and an example. The Returns line is generic but the example compensates. No superfluous text; each part serves a purpose.

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 and presence of an output schema, the description covers the main purpose, parameters, constraint, and provides an example. However, it does not differentiate from related optimization tools, which 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 0%, but the description explains both parameters: 'name: The portfolio name' and 'weights: New allocation weights per symbol. Must sum to 1.0.' This adds essential meaning, including the summation constraint, which is not in 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?

Clearly states 'Update the allocation weights of an existing portfolio' and explains that it changes weight distribution and recalculates metrics. This verb-resource pairing is specific and distinguishes it from creation or deletion tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for updating weights but does not specify when to use this tool versus alternatives like apply_optimization or optimize_portfolio. No explicit when-not or exclusion criteria are provided.

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