QuantOracle
Server Quality Checklist
Latest release: v2.2.0
- Disambiguation3/5
The tools are grouped by domain but some have overlapping functionalities, such as indicators_regime and indicators_regime-classify, and risk_portfolio vs risk_full-analysis. The presence of consolidated 'replaces' tools alongside individual ones can confuse an agent about which to use.
Naming Consistency4/5Tool names follow a domain_prefix_descriptive pattern, but there is some inconsistency with hyphens vs underscores (e.g., crypto_apy-apr-convert, options_implied-vol) and varied lengths. Overall, the pattern is clear and predictable.
Tool Count2/5With 74 tools, the count is very high for an MCP server. While each tool serves a distinct purpose in quantitative finance, the sheer number makes it difficult for an agent to efficiently navigate and select the right tool.
Completeness5/5The server covers a comprehensive range of quantitative finance computations including options, risk, portfolio, technical indicators, fixed income, FX, crypto, and statistics. It addresses common and advanced needs, with few obvious gaps for the intended domain.
Average 4.2/5 across 74 of 74 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 6 of 6 community issues answered or closed in the last 6 months
- 41 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations indicate readOnlyHint and idempotentHint, the description misleadingly says 'Provide a covariance matrix' whereas the input schema requires separate volatilities and correlation matrix, causing confusion about the actual input format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the tool's purpose. Minor redundancy exists ('Equal risk contribution portfolio weights' vs. 'Use when computing...'), but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters and no output schema, the description lacks details on how optional parameters like 'risk_budget' are used, error conditions, or explicit mention of return values beyond weights and risk contributions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 4 parameters, so the baseline is 3. The description adds no extra parameter meaning; the 'covariance matrix' mention contradicts the schema, but the schema descriptions themselves are adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes equal risk contribution (risk parity) portfolio weights, using specific verb 'compute' and resource 'risk parity weights'. It is distinct from sibling tools like 'portfolio_optimize' which handle other optimization methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Use when computing equal risk contribution (risk parity) portfolio weights', providing clear context but no explicit guidance on when not to use or alternatives such as 'portfolio_optimize'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds minimal behavioral context beyond stating output metrics; lacks details on data requirements or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. Clearly front-loaded with purpose and usage instruction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool. Lacks mention of minimum returns array length (minItems:5) from schema, but schema covers it. Output summary is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description mentions 'Provide returns and risk-free rate' but does not elaborate beyond schema. Output description is helpful but not parameter-specific.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it computes the Sharpe ratio from a return series and lists output metrics. However, it does not explicitly distinguish from sibling tools like stats_probabilistic-sharpe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when computing the Sharpe ratio from a return series', providing clear usage context. Does not mention when not to use or list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-only, idempotent, and non-destructive. The description adds no behavioral detail beyond the annotations, but does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (4 sentences), front-loading the key information (Kelly Criterion, discrete/continuous modes) without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description outlines the return values (full Kelly, half-Kelly, etc.) and usage context. Since there is no output schema, the description adequately covers what to expect. Missing details like handling of edge cases or validation are not critical for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 5 parameters with descriptions (100% coverage). The description adds context by stating 'Provide win probability and win/loss ratio' and mentions the two modes, reinforcing the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool calculates the Kelly Criterion for optimal bet sizing in discrete or continuous modes. However, it does not explicitly differentiate from sibling tools like risk_position-size, which may also involve position sizing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use when determining optimal bet/position sizing using the Kelly Criterion,' giving clear context. It does not provide when-not-to-use advice or mention alternatives, such as risk_position-size.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. The description adds valuable output details (Pearson/Spearman matrices, eigenvalues, eigenvectors, explained variance ratios) beyond annotations, justifying a score above baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise: two sentences cover purpose, usage, and return values. No unnecessary words, though could be more structured. Efficient for agent consumption.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description explains return values adequately. However, it mentions 'covariance matrices' in the first sentence but the returns only list correlation matrices, creating a slight inconsistency. Otherwise sufficient for a 3-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. The description adds context about providing a '2D array of return series,' which is similar to the schema's 'Named data series' example. Marginal added value, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it computes correlation matrices with optional eigenvalue decomposition. Distinguishes from sibling tools like risk_correlation by mentioning eigenvalue decomposition, though not explicitly compared.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Use when computing a correlation matrix with eigenvalue decomposition for multiple assets.' Does not state when not to use or mention alternatives, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the pricing formula name but does not elaborate on other behavioral aspects like no side effects, auth needs, or rate limits. With good annotation coverage, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. The first sentence acts as a clear title, the second provides usage guidance, and the third summarizes parameters and output. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks detail on output format (e.g., single number vs object) and does not explain floating vs fixed strike usage nuances. With 10 parameters and no output schema, more context would be helpful for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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. The description lists some parameter categories but does not add meaning beyond what is already in the schema descriptions. Baseline 3 per rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool prices lookback options (floating/fixed strike) using Goldman-Sosin-Gatto formulas. The name and title reinforce this, and it distinguishes from sibling tools like derivatives_asian-option and derivatives_barrier-option.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when pricing lookback options', which is clear. However, it does not mention when not to use it or provide alternatives among the many derivative pricing siblings, missing an opportunity to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it uses normal or Student-t assumptions, but does not explain required sample size (min 10 returns) or other behavioral constraints. Some value added but not substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose, usage, and output. No extra words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has full schema and annotations, but no output schema. The description covers main outputs (VaR, CVaR, distribution parameters) but misses details on distribution assumption selection and optional parameters like portfolio_value and holding_period_days. A more complete description would explain these.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 4 parameters with descriptions (100% coverage). The description does not add new information about parameters; it only mentions 'returns and confidence level' which are already in schema. Baseline set to 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it computes parametric VaR and CVaR, and specifies inputs and outputs. It distinguishes itself from sibling risk tools like risk_montecarlo, risk_stress-test by focusing on parametric methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use when computing Value-at-Risk and Conditional VaR using parametric methods.' This provides clear context for when to use, but does not explicitly mention when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds that it uses analytical formulas and returns price plus adjustment factors. This adds some behavioral context but does not delve into assumptions, limitations, or error conditions. Given annotations cover safety, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. It front-loads purpose, then usage guidance, then return values. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a computational tool without output schema, the description lists return values (price, vanilla equivalent, adjustment factors). It covers inputs and outputs adequately for an agent to understand usage. Could be improved by noting the analytical formulas' assumptions, but not necessary for minimal completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description mentions 'spot, strike, barrier level, barrier type, and standard option parameters,' which maps to parameters but adds no new detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The tool explicitly states it is for 'pricing barrier options using analytical formulas,' specifying the verb and resource clearly. It distinguishes itself from siblings like 'derivatives_asian-option' or 'derivatives_lookback-option' by focusing on barrier options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises 'Use when pricing knock-in or knock-out barrier options,' providing clear context. It does not explicitly list when not to use or suggest alternatives, but the specificity of barrier options compared to sibling tools is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds return values (Z-spread, OAS, default probability, LGD) but no additional behavioral traits beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first defines purpose, second provides usage guidance and outputs. No wasted words, important info front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers inputs and outputs sufficiently given no output schema. Mentions all key return values. Missing a note about prerequisites (e.g., need market data) but schema covers input format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has a clear description. The tool description merely lists required params without adding new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it computes credit spread and Z-spread from bond price vs risk-free curve, and specifies the use case for corporate bond default probability. Distinguishes from sibling fixed-income tools like 'fixed-income_bond' and 'fi_yield-curve-interpolate'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: 'Use when computing Z-spread and implied default probability... Provide bond price, coupon, maturity, and risk-free curve.' Lacks explicit exclusions or alternatives, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety and idempotency. The description adds only that it returns interpolated yields, which is expected. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words. Purpose is front-loaded. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input requirements and output expectations. It lacks mention of ordering constraints for tenors, but given the tool's simplicity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains each parameter. The description reinforces 'observed maturities and yields, plus query maturities' but adds no new meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Yield curve interpolation' with specific methods, clearly distinguishing the tool's verb and resource. No sibling tool has the same purpose, making it unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when interpolating a yield curve at arbitrary maturities,' providing clear usage context. It does not include when-not or alternatives, but the specificity is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, signaling safe, side-effect-free behavior. The description adds that it returns composite signals and trend classification but does not disclose any additional behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the purpose and usage. Every word earns its place—no redundancy or filler. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description compensates by listing the computed indicators and signals. Parameters are fully covered. It lacks edge-case info (e.g., NaN handling, minimum price length beyond minItems=5) but is largely complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters well. The description adds 'Provide an array of prices and optional volumes' but this largely echoes the schema. It does not clarify the period's effect or data constraints beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes '13 technical indicators + composite signals' from price series and lists the specific indicators. It distinguishes itself from siblings like indicators_crossover and indicators_regime by offering a broad set of indicators in one call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when you need multiple technical indicators computed from a price series.' This provides clear context for when to use, but does not include exclusions or comparisons to siblings, which would elevate it further.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it returns price, 10 Greeks, and breakdown, which is useful but not essential beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: a headline summarizing the tool, then a clear usage and returns statement. Every word is meaningful and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description compensates by listing return values (price, 10 Greeks, intrinsic/time value breakdown). This is sufficient for typical use, though edge cases are not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters have descriptions. The description mentions some parameters (spot, strike, time, rate, volatility) but adds no new meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs Black-Scholes pricing with 10 Greeks, listing specific return values. This directly differentiates it from sibling tools like options_implied-vol (implied volatility) and options_strategy (multi-leg strategies).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when you need to price a European option or compute Greeks' and lists required inputs. It does not explicitly state when not to use or name 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds beyond these by stating that the tool returns a ranked list with detailed outputs (legs, profit/loss, breakevens, etc.) and that it is paid-only. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with only a few sentences. It front-loads the purpose and return format, and includes a usage note. Every sentence is necessary and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and annotations, the description covers the main aspects: purpose, required inputs, return contents, and a usage note. It does not explain the scoring criteria or how the ranking works, but overall it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 well. The description mentions providing spot price, outlook, vol_view, T, sigma, r, but this adds minimal value beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool ranks top options strategies given market outlook and volatility view, and lists what it returns (P&L, breakevens, etc.). It is specific about the verb 'rank' and resource 'options strategies', but does not explicitly differentiate from sibling tools like 'options_strategy' or 'options_spread-scan'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Use when agents need to pick the best options strategy given a market outlook', which provides clear context. It also notes 'PAID ONLY — no free tier', giving a usage restriction. However, it does not provide alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, non-destructive behavior, which the description does not contradict. The description adds behavioral context by listing the output fields (optimal weights, expected return, volatility, Sharpe ratio, efficient frontier points), which is useful beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the main purpose, and no redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return values adequately given no output schema, but the missing covariance matrix input and lack of detail on the mode parameter limits completeness. Sibling tools exist that are similar, but the description does not differentiate enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description mentions a 'covariance matrix' input that is not present in the schema, causing inconsistency. This misleads the agent about required inputs. The description adds no meaningful extra meaning beyond the schema and introduces inaccuracy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns optimal weights for three specific objectives: max Sharpe, min volatility, or risk parity. This distinguishes it from sibling tools like portfolio_risk-parity-weights and provides a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('when optimizing portfolio weights') and what inputs are required (expected returns and a covariance matrix). However, it does not mention when not to use or provide alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. The description adds value by detailing the return structure (trade list, costs, drift, weights) and mentions pricing, which enhances transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: one sentence for purpose, one for usage, one for inputs/outputs, and one for pricing. Every sentence adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explicitly lists return fields, making it comprehensive. It covers inputs, usage, and outputs, though it could briefly explain that the tool does not execute trades.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-defined. The description briefly summarizes parameters but adds minimal new semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'generate trade list to rebalance' with specific inputs and outputs. It distinguishes itself from siblings like portfolio_optimize by focusing on rebalancing with given target weights, but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when generating the exact trades needed to rebalance a portfolio' and notes the paid tier, providing clear context. However, it does not mention when not to use this tool or alternative tools like portfolio_optimize for weight generation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the tool returns 'portfolio P&L under each scenario with component-level breakdown', but no additional behavioral traits (e.g., rate limits, prerequisites) beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short, focused sentences. The first states the tool's purpose, the second gives usage and output. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description mentions the return type (P&L per scenario with breakdown), which is helpful. It covers what to provide and what to expect, but could elaborate on how scenario shocks interact with position attributes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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. The description mentions 'Provide portfolio weights, asset returns, and scenario definitions', which adds context but largely maps to schema properties. It does not introduce new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Portfolio stress test across multiple scenarios', specifying the verb (stress-test) and resource (portfolio). It distinguishes from sibling tools like 'risk_portfolio' or 'risk_var-parametric' by focusing on multi-scenario stress testing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when stress-testing a portfolio against multiple scenarios', providing clear when-to-use guidance. It does not mention when not to use or list alternatives, but the context of siblings implies this tool is for multi-scenario tests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool is safe. The description adds that it returns future value, total interest, and growth factor, providing minimal extra context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first defines the core function, the second gives usage guidance and return values. No wasted words, appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and rich schema with annotations, the description covers the essential information. It lists return values even without an output schema. Minor gaps: no mention of edge cases like negative rates, but schema handles constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds little beyond summarizing which parameters to provide. It does not explain the payment_timing enum or annuity details beyond schema, but schema already covers them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes the future value of a present lump sum and/or annuity stream, using a specific verb (compute) and resource (future value). It distinguishes from siblings like tvm_present-value which does the inverse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when computing the future value of a present sum' and instructs to provide present value, rate, and periods. It does not explicitly list conditions not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds context by listing the return values (liquidation price, distance to liquidation, margin call price). It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loading the purpose. It could be more structured (e.g., bullet points for returns) but is still efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description compensates by specifying return values. It covers the main inputs and outputs, but could mention data sources or assumptions for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description only mentions a subset of parameters (entry price, leverage, position side, maintenance margin) and does not add significant meaning beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'liquidation price calculator for leveraged positions' and specifies the inputs and outputs. It is specific and distinct from sibling tools, as no other liquidation price calculator exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when computing the liquidation price for a leveraged position,' providing clear context. It does not mention when not to use or alternatives, but given the tool's unique purpose, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by listing specific return values (price, duration, convexity, accrued interest). Annotations already declare readOnlyHint and idempotentHint, and the description aligns with no side effects claimed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a list of outputs—no wasted words. Key information is front-loaded: purpose, usage, and output summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description lists outputs and hints at input flexibility ('yield or price'), it misaligns with the schema (which only has ytm). This inconsistency reduces completeness. No output schema exists, so description should be precise; it is not fully accurate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents parameters. The description only slightly adds context by mentioning 'yield or price', but this is inconsistent with the schema (which has no price parameter). No extra semantic depth beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes bond price, duration, convexity, and DV01, with explicit outputs listed. It distinguishes itself from siblings like fixed-income_amortization and fi_yield-curve-interpolate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use when pricing a bond or computing yield, duration, and convexity.' It lists required inputs but does not explicitly exclude alternatives or mention when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by stating the output (implied forward rates) and the process (bootstrapping), which goes beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three short sentences, each serving a distinct purpose: stating the function, providing usage guidance, and describing the output. No unnecessary words, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose and output but lacks details about the bootstrapping method (e.g., interpolation), constraints (e.g., forward_start < forward_end), or edge cases. Given the tool's moderate complexity (4 parameters, no output schema), more information would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add new parameter-level information beyond what the schema already provides; it only summarizes the overall goal. Thus, it meets but does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool bootstraps forward rates from a spot yield curve, specifying the verb (bootstrap), resource (forward rates), and input (spot yield curve). It also mentions the output (implied forward rates between tenor pairs), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use when bootstrapping forward rates from a yield curve,' providing clear context for when to use this tool. However, it does not mention when not to use it or provide alternatives, which is a minor gap given the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true and idempotentHint=true. Description adds critical behavioral info 'PAID ONLY — no free tier' and mentions return structure, without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two paragraphs with front-loaded purpose and succinct usage instructions. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given rich schema, clear annotations, and no output schema, the description adequately explains purpose, usage, required inputs, and paid status, making it complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description restates parameter names and types but does not add new semantics beyond what the schema's descriptions already provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'Rank cheapest effective hedges for a given position' and lists specific hedge types, clearly distinguishing this tool from sibling tools like options_strategy or risk_position-size.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use when agents need to hedge an existing position' and lists required parameters, providing clear context for when to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds output details (returns real yield, breakeven inflation, risk premium) and parameter trade-offs, providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, usage, outputs. No fluff, all sentences are essential. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (4 params, no output schema, strong annotations), the description adequately covers purpose, inputs, and outputs. It could optionally explain the Fisher equation relationship but is complete enough for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds value by clarifying the alternative relationship between inflation_expectation and tips_yield, and confirms the default tenor_years. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Real yield and breakeven inflation from nominal yields' and further clarifies it computes real yield, breakeven inflation, and inflation risk premium. It clearly identifies the tool's function but does not differentiate from sibling tools like macro_inflation-adjusted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use when computing real yield and breakeven inflation' and specifies input alternatives (nominal yield + inflation expectation or TIPS yield). It lacks explicit when-not-to-use or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool is safe. The description adds that it returns an array of price/payoff pairs and key metrics, providing useful 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the primary purpose and usage. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of multi-leg options and no output schema, the description only briefly mentions the return format (array of pairs) and metrics (breakevens, max profit/loss). It could benefit from specifying the exact structure of the return array.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds limited value beyond summarizing that legs require strike, premium, quantity, and type. It does not provide additional constraints or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool generates data points for plotting options payoff diagrams. The verb "generate" and resource "payoff diagram data" are specific, and it distinguishes itself from sibling tools like options_price or options_strategy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage scenario: "Use when you need payoff/P&L data points for plotting an options strategy." While it does not explicitly mention when not to use or list alternatives, the context of siblings makes the purpose clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the critical behavioral constraint that the tool is 'PAID ONLY — no free tier', which is beyond annotations. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a paid note, front-loading the purpose. It is concise with no redundant information, though the second sentence could be slightly more structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description adequately explains inputs (holdings with specifics), outputs (Sharpe, VaR, drawdown, etc.), and the paid status. It mentions specific stress test scenarios and that it combines multiple analyses, providing sufficient context for use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all four parameters. The description adds some context by mentioning that holdings need 'values, target weights, and return series', but this aligns with schema descriptions. Minimal added value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a 'full portfolio health check' combining risk metrics, correlation, drawdown, rebalance, and stress test. It clearly distinguishes from siblings by stating it 'replaces 6 individual calls', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the tool 'when you need a complete portfolio health check' and that it replaces multiple individual calls, implying preference over separate tools. However, it does not explicitly state when not to use it or list specific alternatives, leaving some gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the tool is safe and deterministic. The description adds behavioral context by listing the outputs: realized volatility, annualized vol, and rolling vol series. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with only two sentences: the first lists the volatility methods, and the second states usage and outputs. Every sentence is essential, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (multiple methods) and no output schema, the description is adequate but has a minor inconsistency: it says 'Provide returns' but the input schema requires price arrays (close, low, high, open). This could confuse an agent. It could also clarify which parameters are needed for each method.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions 'Provide returns and optional annualization factor' but does not add significant meaning beyond what the parameter descriptions already provide. It adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes realized volatility using multiple methods (close-to-close, Parkinson, Garman-Klass, Yang-Zhang) from OHLC data. This distinguishes it from sibling tools like stats_sharpe_ratio or stats_zscore which compute different metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when computing historical/realized volatility from a return series.' It provides clear context but does not mention when not to use it or explicitly name alternatives. However, the context is sufficient for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return values: 'position size, costs, signals, regime, Kelly sizing, and FAVORABLE/CAUTION/UNFAVORABLE verdict.' This adds context beyond annotations (readOnlyHint, idempotentHint) about the combined nature and verdict output. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with two sentences and a few additional lines. It front-loads the main purpose and then details. Minor redundancy ('Complete trade evaluation' repeated) but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, no output schema), the description covers the tool's purpose, inputs, outputs, and pricing. It doesn't explain the verdict or signal details, but provides sufficient context for an agent to understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description mentions providing 'entry/stop/target prices, account size, and recent price history' which maps to required parameters, but adds little meaning beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Complete trade evaluation: sizing, risk/reward, Kelly, costs, regime, signals. Replaces 5 individual calls.' It specifies the verb 'evaluate' and the resource 'trade', and distinguishes from siblings by highlighting it as a combined alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Use when evaluating whether to take a specific trade.' It also provides input requirements and notes 'PAID ONLY — no free tier.' While it mentions replacing 5 individual calls, it doesn't explicitly list those alternatives or specify when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns effective price, price impact percentage, and output amount after slippage. Annotations already indicate read-only and idempotent behavior, and the description adds no contradictions. It could mention that the estimate is based on the constant-product formula and does not account for real-time market effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: the first defines the tool, the second gives usage guidance, and the third lists outputs. It is concise, front-loaded, and contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (5 parameters, no output schema), the description adequately covers inputs and outputs. It could be improved by clarifying that results are estimates based on the constant-product formula, but it is still fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions. The description adds context like 'trade size and pool reserves' and the return values, which slightly supplements the schema. However, the benefit is minimal given the schema already describes each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a DEX slippage estimator for constant-product AMM (x*y=k), with a specific verb and resource. It is distinct from sibling tools like crypto_impermanent-loss or risk_transaction-cost.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using it when estimating slippage on a DEX trade with constant-product AMM math, which provides clear context. It does not explicitly exclude non-constant-product AMMs or mention alternatives, but the usage is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. Description adds that it returns 'option price via geometric closed-form or Turnbull-Wakeman approximation', which is valuable behavioral detail beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a list of required inputs. No wasted words; front-loaded with purpose and method. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, methods, required inputs, and return value, which is sufficient for a pricing tool with well-documented schema. No output schema exists, but the return is clearly implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully described. The description lists key parameters (spot, strike, time, rate, volatility, averaging type) but does not add new semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Asian option pricing' with two specific methods (geometric closed-form or Turnbull-Wakeman approximation), distinguishing it from siblings like barrier options or standard options pricing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when pricing Asian (average-price) options', providing clear context for when to invoke this tool, though it does not explicitly mention when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds behavioral context by stating the outputs ('Returns: option price, early exercise boundary, and tree node values'), which is not in the annotations. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. First sentence states purpose, second sentence provides usage and outputs. Front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description mentions the return values (price, early exercise boundary, tree node values). For a tool with 9 parameters and no nested objects, this is sufficient to use the tool without additional context. However, it could mention edge cases or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description merely lists parameter names ('Provide spot, strike, time, rate, volatility, steps, and exercise style'), which adds no new meaning beyond the schema's existing descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool does 'CRR binomial tree pricing for American and European options.' It uses a specific verb ('pricing') and resource ('American and European options'), and distinguishes itself from sibling tools like 'derivatives_asian-option' by naming the model (CRR) and option types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use guidance: 'Use when pricing American or European options via the CRR binomial lattice.' It lists required inputs. However, it does not explicitly state when not to use this tool or suggest alternatives, which would have made it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds context on input requirements (arrays of strikes, calls, puts, open interest) and outputs, complementing annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences cover purpose, usage, and data expectations without redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists all return values. It explains input structure adequately. Minor gaps: output format (e.g., skew metrics structure) not specified, but overall sufficient for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented. The description summarizes inputs as 'strikes, calls, puts, and open interest' but adds no new semantic depth beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes option chains for skew, max pain, and put-call ratios, listing specific outputs. It distinguishes from sibling tools like 'options_implied-vol' by offering a comprehensive analytics suite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes explicit direction: 'Use when analyzing an options chain for skew, max pain, and put-call ratios.' It provides clear context but does not explicitly exclude other uses or name alternatives, leaving room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds value by explaining the output: 'Returns: parity check, theoretical values, and any arbitrage amount.' This behavioral context goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the tool's purpose, and the second provides usage instructions and expected outputs. Every sentence is necessary, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters (5 required) and no output schema, the description adequately explains what the tool does and returns. It could mention default values for optional parameters, but the schema already handles that. Overall, it is sufficiently complete for a mathematical tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description lists key inputs ('call price, put price, spot, strike, rate, and time') but omits the optional 'q' (dividend yield). It doesn't add significant meaning beyond the schema, earning a middle score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Put-call parity check and arbitrage detection.' This is a specific verb-resource combination that distinguishes it from sibling derivatives tools like options_price or options_implied-vol, 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.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when checking put-call parity or detecting arbitrage opportunities,' providing clear guidance on when to use it. However, it does not discuss alternatives or when not to use it, which would be helpful but is not critical given the tool's niche.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe read operation. The description adds that the tool returns fair value and over/undervaluation percentage. No contradictions. Could mention assumptions (e.g., relative PPP), but adequate given annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. First sentence provides a clear title-like purpose, followed by usage instructions and output. Perfectly front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given annotations and schema, the description covers what the tool does, required inputs, and output. No output schema, but return values are described. Could be more detailed about assumptions (e.g., using relative PPP), but sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all four parameters. The description paraphrases some inputs but adds no significant new meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates fair value using PPP, with a specific verb ('estimation') and resource ('FX rate using PPP'). It distinguishes from sibling tools like fx_forward-rate or fx_carry-trade by highlighting the PPP methodology, though no explicit comparison is made.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('when estimating fair value of an FX rate using PPP') and what inputs to provide (domestic/foreign price indices, base-period exchange rate). Does not mention when not to use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds value by specifying the return outputs: current ATR, normalized ATR as % of price, history, and volatility regime. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is only 3 sentences covering purpose, usage, and outputs. No filler, front-loaded with key information, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description lists the return values (ATR, normalized ATR, history, regime). It is complete enough for a volatility indicator tool. Minor gap: no mention of input length requirements or edge cases, but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters (high, low, close, period). The description only says 'Provide an array of prices,' which adds no new meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it computes Average True Range (ATR) with normalized ATR and volatility regime classification. Specific verb+resource, and no sibling tool duplicates this functionality, so it is well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when measuring volatility via Average True Range,' providing a clear context for use. However, no mention of when not to use or alternatives (e.g., other volatility indicators), so not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idlempotentHint=true, destructiveHint=false. The description adds value by listing the exact retracement and extension levels returned, which is behavioral detail beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a list of levels. It is front-loaded with the purpose and has no fluff. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description enumerates the exact retracement and extension levels returned. For a simple calculation tool with well-known inputs, this provides sufficient context 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: all three parameters (swing_high, swing_low, direction) are described in the schema. The description's mention of 'Provide a high price and low price' adds no new semantics beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it computes Fibonacci retracement and extension levels, specifies exact levels returned, and identifies required inputs (high and low prices). It distinguishes itself from sibling tools like indicators_bollinger-bands or indicators_atr by being specific to Fibonacci calculations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when computing Fibonacci retracement and extension levels.' It does not provide exclusions or alternatives, but the context is clear enough for an agent to decide when to invoke this tool versus other technical indicators.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive. The description adds value by detailing the return categories (trend regime, volatility regime, change signals), enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the purpose and usage, then lists outputs. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a classification tool with 3 well-documented parameters, the description covers purpose, usage, and outputs. It lacks details on algorithm assumptions but is adequate for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description mentions 'Provide a price series' linking to the 'prices' parameter, but does not explain 'sma_period' or 'vol_window' beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool classifies market regime (trend, volatility, risk) and lists specific outputs. It uses a specific verb ('classify') and resource ('market regime'), distinguishing it from sibling tools like 'indicators_crossover' or 'indicators_technical'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use when classifying market regime (trending vs ranging, high vs low volatility)', providing clear context. However, it does not mention when not to use or explicitly name alternatives, though sibling tools imply other uses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds the return information (net premium, max profit/loss, P&L data), which is critical since there is no output schema. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, then usage, then input format, then output. No redundant words; every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately complex tool (multi-leg options), the description covers purpose, usage, input, and output. Lacks specifics about error handling or edge cases, but annotations suffice. No output schema, but description lists return items adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds little beyond specifying the input structure ('array of legs with strike, premium, quantity, and type'). This mirrors the schema without new insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear, specific verb+resource: 'Multi-leg options strategy P&L, breakevens, max profit/loss, risk/reward.' It contrasts with sibling tools like options_price (single option) and options_implied-vol (volatility), distinguishing its multi-leg focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use when analyzing a multi-leg options strategy' and provides examples (spreads, straddles, etc.). While it doesn't list when not to use, the clarity implies alternatives exist for single-leg strategies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details what the tool returns (max drawdown, duration, recovery time, etc.), adding value beyond annotations which already declare readOnlyHint and idempotentHint. It accurately describes the computation without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first names the function, second provides usage and output. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter, no output schema, and annotations covering safety and idempotency, the description is adequately complete. It specifies input format and output metrics, though order or temporal assumptions could be clarified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of 'equity_curve' as 'Array of portfolio equity values over time.' The tool description adds 'Provide an array of returns' but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as performing 'Drawdown decomposition with underwater curve' and lists specific outputs (max drawdown, duration, etc.). It distinguishes itself from sibling risk tools like correlation, kelly, or portfolio by focusing exclusively on drawdown analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use when analyzing drawdown characteristics of a return series,' providing clear context. It does not specify when not to use or mention alternatives, but the guidance is direct and sufficient given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint=true and idempotentHint=true, indicating safe computation. The description adds the list of 22 metrics and optional benchmark, but no unexpected behaviors or side effects beyond what annotations suggest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct, with two clear sentences and a compact list of metrics. It front-loads the key output (22 risk metrics) and uses minimal yet informative language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters with high schema coverage, no output schema, and clear annotations, the description adequately explains inputs and outputs. It could be slightly more specific about return format, but overall it's complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining that benchmark_returns is optional for relative metrics, which is not fully detailed in the schema. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it computes 22 risk metrics from a portfolio returns series, listing specific metrics like Sharpe, Sortino, VaR. This is specific to the tool and distinguishes it from siblings such as risk_drawdown or risk_correlation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly advises use when you have a series of portfolio returns and need comprehensive risk analytics, and notes when benchmark returns are needed. While it doesn't explicitly exclude other contexts, the guidance is clear given the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it returns position size, dollar risk, and shares, but doesn't elaborate on computational behavior (e.g., rounding, fractional shares). It is adequate but adds little beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a concise list of returns. Every word contributes, with no fluff. The structure is front-loaded with the core purpose, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and straightforward calculation, the description explains input and output sufficiently. Mentioning units or rounding could enhance, but it is complete enough for the agent to understand usage and expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description adds context by grouping inputs ('account value, risk percentage, entry price, stop-loss price') and clarifying that risk_per_trade is a fraction with a default of 0.02, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it calculates position size using fixed fractional method with risk/reward targeting. The verb 'calculating' and specific resource 'shares/contracts' precisely define the tool's purpose, distinguishing it from siblings like risk_kelly and risk_drawdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use: 'when calculating how many shares/contracts to buy given account size and risk tolerance.' It lists required inputs but does not explicitly compare with alternatives like risk_kelly, though the context of siblings allows inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, destructiveHint=false) already indicate safety. The description adds behavioral details: it returns simulated terminal prices, percentile distribution, expected value, probability of profit, and path statistics. It also notes performance limits and API fallback, providing context beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a note; no wasted words. The first sentence captures the core functionality, and the note provides essential usage constraints. Information is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and no output schema, the description covers purpose, usage limits, and expected outputs (terminal prices, percentiles, etc.). It lacks error handling details but is fairly complete for a simulation tool with defaults. Annotations further enrich context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all 7 parameters described in the input schema. The description mentions 'starting price, drift, volatility, time horizon, number of simulations' and contributions/withdrawals, but does not add significant meaning beyond what schema descriptions already provide. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs GBM Monte Carlo simulation with contributions/withdrawals, up to 5000 paths, and lists returned outputs (terminal prices, percentiles, etc.). It distinguishes from sibling tools which focus on bonds, indicators, options, or risk metrics, none of which are Monte Carlo simulations for asset price paths.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when running a Monte Carlo simulation for asset price paths' and provides performance constraints: keep simulations ≤ 1000 and years ≤ 30 for MCP, and directs to REST API for larger simulations. It does not mention when not to use this tool versus alternatives, but the usage context is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe, non-mutating nature is clear. The description adds valuable behavioral context by specifying the return values (test statistic, p-value, critical values, hedge ratio, spread series), which is not available from schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of two concise sentences: the first identifies the tool, and the second provides usage guidance and output summary. Every word serves a purpose, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description compensates by listing the expected return values. Annotations cover safety. However, it could be slightly more complete by noting input requirements (e.g., equal length series), but overall it is adequate 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions 'Provide two price series', which aligns with the required parameters series_x and series_y, but adds no additional semantic nuance beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly identifies the tool as 'Engle-Granger cointegration test with hedge ratio and half-life', which is a specific and well-known statistical test. This clearly distinguishes it from sibling tools like stats_correlation-matrix or stats_hurst-exponent, providing a precise verb-resource pair.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the tool 'when testing if two time series are cointegrated (mean-reverting pair)', which directly addresses usage context. While it does not explicitly list alternatives, the context of sibling tools and the clear purpose make the guidance effective.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses return values: best-fit distribution, parameters (mean, std), goodness-of-fit statistics (KS test, chi-squared), and Q-Q plot data. Annotations already indicate readOnlyHint=true and idempotentHint=true, and the description adds specific behavioral context beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded: first sentence states purpose and ranking, second gives use case and outputs. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers distribution types, required input, and all outputs (parameters, statistics, Q-Q plot). No output schema exists, so description must carry the burden, which it does adequately for a single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'data', with description 'Array of data to fit distributions to'. The description adds minimal extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'fit data to common distributions' and specifies the resource (data array) and ranking by goodness of fit. It distinguishes from sibling tools like stats_normal-distribution by focusing on multiple distributions and ranking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says 'Use when fitting data to standard distributions (normal, lognormal, uniform)' and instructs to provide a data array. It lacks explicit when-not-to-use or alternatives, but the guidance is clear and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=true and destructiveHint=false, so the description adds value by disclosing the algorithm (MLE) and output structure (parameters, conditional volatility, forecasts). No contradictions—the forecast operation aligns with read-only and idempotent hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the essential purpose. Every sentence adds distinct value—purpose, usage guidance, and output summary—with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no output schema), the description effectively outlines the output (GARCH parameters, conditional volatility, forecasts) and the estimation method (MLE). It could mention assumptions like data frequency or stationarity, but it covers the core elements sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The description mentions 'provide a return series', matching the required 'returns' parameter, but adds no new semantic detail about parameters beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'GARCH(1,1) volatility forecast using maximum likelihood estimation', clearly stating the verb (forecast), resource (volatility), and model type. This distinguishes it from sibling tools like 'stats_realized-volatility' or 'risk_var-parametric' that 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.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when forecasting future volatility using a GARCH(1,1) model. Provide a return series.' It gives a clear condition for use, though it lacks explicit 'when not to use' or alternatives. Nonetheless, the guidance is direct and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the agent knows it's safe. The description adds behavioral details like the outputs (R-squared, t-stats, etc.) and that it uses OLS, which is beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states what it is, the second gives usage and outputs. Front-loaded, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so the description compensates by listing return values including slope, intercept, R², etc. It also ties confidence_level to confidence intervals. Missing edge cases but adequate for a stats tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 3 parameters. The description mentions 'provide x and y arrays' but does not add new meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'OLS linear regression', which is a specific verb-resource pair. It distinguishes from sibling statistical tools like stats_polynomial_regression or stats_cointegration by specifying linear regression.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when fitting a linear regression (OLS). Provide x and y arrays.' This gives clear when-to-use guidance, though it does not mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by detailing the return values (coefficients, R², fitted values, residuals), providing behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the purpose, and the second gives usage and outputs. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers inputs (from schema) and outputs (explicitly listed). Complexity is moderate, and the description is sufficient for an agent to understand usage. No mention of edge cases or constraints, but not required for a standard regression tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description merely restates 'Provide x, y arrays, and degree' without adding new constraints or usage details. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs polynomial regression of degree n with goodness-of-fit metrics. It uses specific verbs ('fitting a polynomial') and specifies the resource (x, y arrays) and outputs (coefficients, R², fitted values, residuals). It is distinct from sibling tools like stats_linear-regression.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context: 'Use when fitting a polynomial of degree n to data.' It does not explicitly state when not to use or name alternatives, but the context is sufficient for basic guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's mention of 'Returns: present value and discount factor' adds value by disclosing outputs. No contradictory or missing behavioral info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first defines the tool, second gives usage and returns. No wasted words, front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial calculation tool with 5 parameters, no output schema, and good annotations, the description covers purpose and returns. It lacks detail on parameter units or special cases (e.g., rate format), but is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds little beyond what the schema already explains (e.g., 'provide future value, discount rate, and number of periods' is redundant with schema descriptions). Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes 'present value of a future lump sum and/or annuity stream', using specific financial terms that distinguish it from sibling tools like tvm_future-value, tvm_irr, and tvm_npv.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use when computing the present value of a future cash flow', providing a clear usage context. However, it does not explicitly mention when not to use it or suggest alternatives among sibling TVM tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds 'Deterministic' (consistent with idempotency) and enumerates return fields (total return, Sharpe, etc.). Also mentions 'PAID ONLY' as a behavioral constraint. No contradictions; adds useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 4 sentences, front-loaded with purpose, then strategies, usage, and returns. Every sentence adds value with no redundancy. It efficiently packs all essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 params, 1 nested, no output schema), the description fully covers the tool: explains strategies, parameter shapes, and return fields including equity curve and vs buy-and-hold. Also notes it's paid. No gaps for agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 6 parameters described). The description reinforces the params object structure per strategy, but the schema already includes example structures. Since schema covers the parameter meanings, the description adds minimal new semantics beyond usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs deterministic backtests of four specific strategies (SMA crossover, RSI mean reversion, momentum, Bollinger breakout). It distinguishes itself by noting it replaces 10+ individual calls, making the purpose precise even among many financial siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use when backtesting a trading strategy on price history' and lists the supported strategies, providing clear context. It lacks explicit exclusions or alternatives, but the paid restriction is noted. Given rich sibling list, some guidance on when not to use would improve, but it's still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the tool returns equivalent APY, APR, daily/weekly/monthly rates, and effective annual rate, which is valuable context beyond the annotations. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose, the second provides usage guidance and output summary. Every sentence contributes meaning without redundancy, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description lists the returned metrics (equivalent APY, APR, daily/weekly/monthly rates, effective annual rate). All three parameters are fully documented in the schema, making the description complete for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already describes all three parameters, including defaults and allowed values. The description does not add significant new information about parameters, hence 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Convert between APY and APR with configurable compounding frequency,' specifying the verb (convert) and resource (APY/APR). This differentiates it from sibling tools which cover other financial calculations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when converting between APY and APR with different compounding frequencies,' providing clear context. It does not mention when not to use or alternatives, but for a straightforward conversion tool this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds return value expectations (annualized cost, projected payments, carry trade estimate) beyond annotations, but could mention that no trades are executed or data limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose, usage scenario, and outputs. It is front-loaded and contains no unnecessary words, making it efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description conveys main outputs but lacks detail on 'regime detection' and does not explain how results are presented. With no output schema, more specifics on structure or edge cases would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context by mentioning 'holding period' (not a direct parameter but implied) and links inputs to outputs, slightly enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs 'funding rate analysis with annualization and regime detection,' a specific verb+resource. It distinguishes from siblings by specifying 'perpetual futures funding rates' and listing outputs not found in other crypto tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when analyzing perpetual futures funding rates,' providing clear usage context. However, it does not mention when not to use it or name alternative tools for related tasks like swap comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds output details (percentage, hold vs LP value, breakeven ratios) that go beyond annotations, improving transparency. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two highly focused sentences with no wasted words. Front-loaded with core purpose, then usage and output summary. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description lists three return values, which is good for a no-output-schema tool. However, it oversimplifies v3 usage by not mentioning lower/upper tick parameters explicitly. Could be more complete on parameter-specific constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds context by specifying 'provide initial prices and current prices' and the v2/v3 distinction, which maps to parameters. Adds moderate value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it is an impermanent loss calculator for Uniswap v2/v3, distinguishing it from siblings like backtest_strategy or crypto_dex-slippage. Verb+resource is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when calculating impermanent loss for a liquidity provider position', providing clear context. Does not list alternatives or when-not-to-use, but the scope is well-defined and distinct from other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description adds that it returns a period-by-period unlock schedule with cumulative totals, which is consistent and adds value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose and usage guidance. No redundant information, every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description adequately states it returns a period-by-period unlock schedule with cumulative totals. Combined with schema descriptions for parameters, the tool is fully specified for its simple computational role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The overall description summarizes key inputs (total tokens, cliff period, vesting duration, TGE unlock percentage) but does not add significant detail beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes a token vesting schedule with cliff, linear/graded unlock, and TGE, distinguishing it from all sibling tools which cover other financial calculations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when computing a token vesting schedule with cliff and linear vesting', providing clear context for when to invoke. It does not mention exclusions, but the specific domain is sufficiently narrow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint, and the description adds return value details (forward rate, parity-implied rate, arbitrage) without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and immediate value, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema coverage and annotations, the description provides complete context: what, when, inputs, and outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with parameter descriptions; the description lists required parameters but adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is an interest rate parity calculator with arbitrage detection for FX pairs, distinguishing it from sibling tools like fx_forward-rate or fx_carry-trade.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies when to use (computing covered/uncovered interest rate parity) and lists required inputs, but does not explicitly mention when not to use or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. Description adds return details (bands, %B, bandwidth, squeeze flag, position) that enrich behavioral understanding without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines what it is, second gives usage and outputs. No redundancy, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the straightforward computation tool, the description covers purpose, usage, and outputs. No output schema exists, but return fields are listed, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with complete descriptions. Description only mentions 'period/multiplier' corresponding to window and num_std, adding no new meaning beyond the schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes Bollinger Bands with %B, bandwidth, and squeeze detection. It specifies the verb 'compute' in the usage guideline and includes a list of return values, distinguishing it from sibling tools like indicators_atr.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when computing Bollinger Bands with squeeze detection.' Provides clear context but does not mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by detailing the return objects: current MA values, crossover signals, history, and signal strength.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. Each sentence serves a purpose: stating the tool's function and providing usage and return information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no output schema), the description sufficiently covers purpose, usage, inputs, and outputs. Annotations and schema are comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all parameters. The description says 'Provide prices and two MA periods' but does not add new details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Golden/death cross detection with signal history', which is a specific verb+resource. It distinguishes from sibling indicator tools by focusing on moving average crossovers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when detecting moving average crossovers', providing clear context. However, it does not mention when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by detailing the return values (correlation matrix, covariance matrix, eigenvalues). Annotations already indicate read-only, idempotent, and non-destructive behavior, so no contradiction. The description could mention whether the output is symmetric or includes diagonal, but it is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and contains no redundant or extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description clearly states the three return components (correlation, covariance, eigenvalues). For a single-parameter tool with well-defined behavior and annotations, the description provides complete context needed for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage and includes a detailed description of the 'series' parameter with an example. The description's mention of '2D array of return series' adds minimal extra nuance, as the schema already describes it as an object with array-of-number values. Schema does the heavy lifting, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes NxN correlation and covariance matrices from return series, specifying the output includes Pearson correlation, covariance, and eigenvalues for PCA. It distinguishes itself from sibling risk tools like risk_drawdown and risk_kelly by its focus on correlation/covariance matrices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use when computing an N×N correlation matrix for multiple assets.' However, it does not provide explicit when-not-to-use guidance or mention alternative tools for related but distinct tasks (e.g., covariance only or PCA only).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating safe, read-only behavior. The description adds that the tool calculates probability, p-value, and required track record length, providing transparency on output without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences plus a brief note on returns. Front-loaded with the core purpose and academic reference, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explicitly states the return values: probabilistic Sharpe ratio, p-value, and required track record length. Combined with the purpose and parameter guidance, the description is complete for a statistical test tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description mentions 'returns and a benchmark Sharpe,' which adds context but does not significantly enhance understanding beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes the Probabilistic Sharpe Ratio to test statistical significance of an observed Sharpe ratio against a benchmark. It distinguishes itself from simpler Sharpe ratio tools by emphasizing statistical testing, and references the underlying academic work.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use when testing whether a Sharpe ratio is statistically significant.' It also directs the user to provide returns and a benchmark Sharpe. However, it does not mention when not to use or provide alternatives like stats_sharpe-ratio for simple calculation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return values (z-scores, mean, standard deviation, flags) and distinguishes static vs rolling via window parameter. Annotations (readOnlyHint, idempotentHint, destructiveHint) are consistent, and description adds behavioral context beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The first sentence states purpose, the second adds usage guidance and return information. Well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains return values in the absence of an output schema, covering z-scores, mean, standard deviation, and flags. The description also implies behavior for rolling vs static, making it complete for a function of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description mentions 'rolling and static' and 'extreme value detection', which aligns with window and threshold parameters, but adds minimal new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes rolling and static z-scores with extreme value detection, using specific verbs and resources. It distinguishes itself from sibling statistical tools by focusing on z-scores and extreme flags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states usage for 'computing z-scores for statistical analysis or detecting extremes', providing clear context. However, it does not mention when not to use or offer alternative tools among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent. Description adds that it returns interpolated surface, skew, term structure, smile parameters, which gives the agent insight into the output. No description of side effects or prerequisites beyond the inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus a bullet-like list of returns. Every sentence adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool without output schema, the description adequately lists the main outputs. It covers inputs and purpose. However, it lacks edge cases or guidance on data quality. Given the tool's moderate complexity, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are documented. Description summarizes that inputs are arrays of strikes, expiries, and IV values, which aligns with the schema. It adds context by linking parameters to the overall goal, but does not add new details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it builds an implied volatility surface from market data. Uses specific verb 'Build' and identifies the resource. Distinguishes from siblings like options_implied-vol by mentioning surface, skew, term structure, smile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Use when constructing an implied volatility surface from market data.' However, no mention of alternatives or when not to use this tool compared to siblings like options_implied-vol or derivatives_option-chain-analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by detailing the outputs (carry return, spot return, total return, annualized P&L breakdown) and confirming it is a calculation tool. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the purpose, followed by usage guidance and input/output summary. Every sentence is informative and non-redundant, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (7 parameters, no output schema), the description provides sufficient context: purpose, inputs, and outputs. It does not specify formulas or edge cases, but the schema covers parameter units, and the tool is a standard financial calculation, so the description is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing basic descriptions for all 7 parameters. The description adds context by mapping parameters to carry trade concepts ('high-yield and low-yield rates, entry spot rate, exit spot rate'), enhancing understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'Currency carry trade P&L decomposition', a specific verb-resource combination. It distinguishes itself from sibling tools (all other FX tools have different purposes) and explicitly lists inputs and outputs, leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Use when analyzing carry trade P&L decomposition', providing explicit guidance on when to invoke this tool. Although it does not mention alternatives or when not to use, the sibling tools are all distinct, so no exclusion is necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the tool is safe and idempotent. The description adds behavioral context: it combines multiple indicators, requires at least 30 closing prices, returns specific fields (trend direction, volatility regime, RSI, SMA, strategy suggestion), and is paid-only. This goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two short paragraphs. The first line acts as a title summarizing the tool's output. Every sentence adds value—purpose, usage context, requirements, returns, and access restriction. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and no output schema, the description adequately covers the goal, inputs (min 30 closes), and outputs (trend, vol, RSI, SMA, strategy suggestion). It does not detail return formats or optional parameter usage, but the schema covers parameter descriptions, so completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 7 parameters have descriptions). The description only mentions 'closing prices (min 30)' which is already in the schema. No additional parameter semantics are added beyond the schema, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Combined regime classification: trend, vol, RSI, direction, strategy suggestion.' It explicitly distinguishes itself from sibling tools by saying it 'Replaces technical + regime + realized-vol,' indicating it consolidates multiple separate calls into one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use this tool: 'Use when you need a complete market regime assessment... Instead of calling technical + regime + realized-vol separately.' It also provides a prerequisite ('Provide closing prices (min 30)') and notes that it's 'PAID ONLY — no free tier,' guiding the agent on appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already indicate safe read-only operation, description adds that it uses Fisher equation and outputs real return, purchasing power change, and cumulative real growth, which is helpful beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: action, usage with required inputs, and outputs. No redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers outputs and formula but lacks explicit return structure. However, given no output schema, it is adequate and useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions; description adds context that 'periods' and 'initial_value' are for cumulative calculation, enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it converts nominal returns to real returns using Fisher equation, differentiating from siblings like macro_real-yield by specifying the formula and outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when converting nominal returns to real returns using the Fisher equation' but does not provide when-not-to-use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds that the tool returns two outputs (implied rate and deviation), which is useful. No behavioral traits beyond annotations are disclosed, but the description aligns well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three sentences, front-loading the purpose and usage, then stating return values. No superfluous text; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple calculation with no output schema, the description covers purpose, when-to-use, and return values adequately. It could mention the formula or assumptions, but the schema fills in parameter details, making it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 7 parameters. The description reinforces that certain parameters (inflation, target inflation, output gap, neutral rate) are key, but does not add significant new meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes the Taylor Rule interest rate prescription, specifying the verb 'estimating' and the resource 'appropriate policy interest rate'. It effectively distinguishes itself from sibling tools by its unique focus on a specific monetary policy rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use when estimating the appropriate policy interest rate via the Taylor Rule', providing clear guidance on when to invoke the tool. Though alternatives are not mentioned, the specificity makes misuse unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides behavioral details beyond annotations: it specifies the Newton-Raphson iteration method, convergence in 5-8 iterations, and the return values (implied volatility, convergence info, Greeks). Annotations only indicate read-only and idempotent hints; the description adds significant 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences with no wasted words. It front-loads the tool's identity ('Newton-Raphson implied volatility solver') and then efficiently covers when to use, inputs, and outputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately covers return values (implied volatility, convergence info, Greeks). It could be improved by mentioning error conditions or precision, but it is sufficiently complete for a finance solver tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 lists the key parameters (spot, strike, time, etc.) but does not add new semantic meaning beyond the schema. It summarizes rather than enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Newton-Raphson implied volatility solver' that backs out implied volatility from market price. This purpose is distinct from sibling tools like options_price, which likely compute forward prices. The verb 'solver' and resource 'implied volatility' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use when you know the market price of an option and need to back out the implied volatility.' This provides clear context, though it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the model covers commission, spread, and market impact, and specifies the return structure (total cost, breakdown, percentage), which enhances transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: definition, usage, return. All information is front-loaded and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and no output schema, the description provides a high-level overview and return format. It omits detailed guidance on advanced parameters like adv or participation_rate, but schema descriptions cover those. Adequate for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds high-level guidance ('Provide trade size, price, spread, and commission structure'), helping map real-world concepts to parameters, and clarifies the model's components.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it estimates total transaction costs from commission, spread, and market impact. It is specific and distinct from sibling tools like risk_position-size or risk_kelly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when estimating total transaction costs...' providing clear guidance. It does not mention when not to use or alternatives, but given the tool's specific focus, this is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint, indicating a safe, deterministic operation. The description adds that it returns 'Hurst exponent, classification, and confidence,' which enriches understanding of the output without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the tool's purpose, followed by usage guidance and return value. No redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the essential aspects: purpose, interpretation, input hint, and output. Lacks an output schema, but the description compensates by listing return components. Could be enhanced by noting the tool is safe and read-only, but annotations already provide that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by specifying 'Provide a price or return series,' which gives more concrete guidance than the schema's 'Time series data.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool calculates the Hurst exponent via R/S analysis and explains the interpretation of H values for mean-reversion, random walk, or trending. It clearly distinguishes itself from sibling statistical tools by focusing on this specific analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use: 'Use when determining if a time series is mean-reverting..., random walk..., or trending...' It does not explicitly state alternatives or when not to use, but the context is sufficient for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the return structure (CAGR, total return, equivalent annual return), confirming no side effects. No contradictions; description adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. First sentence states the core purpose, second gives usage guidance and return values. Perfectly front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists return values (CAGR decimal, total return, equivalent annual return) but does not explain the format of forward projections when include_projections is true. For a tool with no output schema, slightly more detail on the projections output would improve completeness, but it is largely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description mentions 'beginning value, ending value, and number of years' which maps to start_value, end_value, years. It does not provide additional meaning beyond the schema for the include_projections parameter. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The title and description explicitly state the tool computes Compound Annual Growth Rate with optional forward projections, using specific verbs and resource. It clearly distinguishes from sibling TVM tools like tvm_future-value, tvm_irr, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use when computing compound annual growth rate,' providing clear context. While it does not explicitly state when not to use alternatives, the sibling tools cover other TVM calculations, implying proper usage. Lacks explicit exclusions but is still effective.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, idempotentHint, destructiveHint. The description adds behavioral details: max 100 per batch, pricing as sum of individual endpoint prices, throughput improvement. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loaded with purpose, and every sentence adds value. It efficiently conveys usage, constraints, and benefits without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batching multiple computations), the description covers purpose, usage, constraints (max 100), pricing, and ideal scenarios. No output schema, but the description adequately explains return value implicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (single parameter 'requests'). The description adds semantic value by explaining the structure ('array of {endpoint, params} objects') and endpoint format ('e.g., 'options/price''), which goes beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute multiple computations in a single request,' specifying the verb (execute) and resource (multiple computations). It distinguishes from siblings which are individual endpoint tools like 'options_price' or 'risk_portfolio'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when you need to execute multiple computations efficiently' and provides context like 'bundle up to 100 calls for ~6x throughput improvement' and ideal use cases such as 'backtests, parameter sweeps, and portfolio-wide calculations.' It lacks explicit when-not-to-use but is still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by specifying the return values (rebalancing needed, drift per asset, trade list), which exceeds annotation coverage and helps the agent understand output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and contains no redundant information. Every sentence earns its place, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no output schema), the description covers purpose, usage, parameter semantics, and return values adequately. It is complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. Description adds value by explaining the output structure and connecting parameters (target weights, current weights) to the function, enabling the agent to anticipate results beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'drift detection and trade computation' for portfolio rebalancing, distinguishing it from siblings like portfolio_rebalance-plan which likely generates a full rebalance plan. The verb+noun combination is specific and informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when checking if a crypto portfolio needs rebalancing,' providing clear context. However, it does not mention when not to use or explicitly compare to alternatives, but the usage scenario is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it returns specific outputs like monthly payment and schedule, which is consistent and non-contradictory. No additional behavioral traits needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs, front-loaded with the title-like phrase. Every sentence adds value: purpose, usage, input, output. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and a simple calculation tool, the description sufficiently covers what it does (schedule with extra payments), inputs (principal, rate, term, extra payment), and outputs (payment, interest, schedule). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. The description adds meaning by mentioning 'extra payment savings analysis' and listing return fields, which helps the agent understand the tool's purpose beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it produces a 'full amortization schedule with extra payment savings analysis' and explicitly says to use it when generating a loan amortization schedule. It differentiates from siblings by specifying amortization, a distinct niche among financial tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use when generating a loan amortization schedule.' It does not explicitly mention alternatives or when not to use, but the context is clear for this specialized tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so no destructive behavior. The description adds value by listing the return values (CDF probability, PDF density, z-score, quantile value, confidence interval bounds), which is beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with purpose, and every sentence adds value. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description explicitly lists all possible return values and covers the three modes of operation. It also explains parameter relationships, making the tool fully understandable for its moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters. The description adds contextual guidance on when to use each parameter (e.g., 'Provide x (for CDF/PDF), p (for quantile)'), enhancing the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Normal distribution: CDF, PDF, quantile, and confidence intervals' and details the specific computations, distinguishing it from sibling tools like stats_distribution-fit which focus on fitting rather than direct computation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states 'Use when computing normal distribution CDF, PDF, quantiles, or confidence intervals' and maps parameters to use cases (x for CDF/PDF, p for quantile, confidence_level for interval). It lacks explicit exclusions or direct alternatives, 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, non-destructive behavior, which the description aligns with. Additionally, the description discloses the Newton-Raphson method and the specific outputs (IRR decimal, annualized IRR, NPV), adding valuable 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loaded with the method and usage. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, full schema coverage, and annotations, the description fully covers what the tool does, how to use it, and what it returns. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description restates the first cash flow being negative, adding minimal extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes internal rate of return via Newton-Raphson and provides guidance on typical cash flow structure. It effectively distinguishes from sibling TVM tools like tvm_npv and tvm_future-value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('when computing the internal rate of return for a cash flow series') and provides input format. It does not explicitly exclude scenarios but is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds critical context: 'PAID ONLY — no free tier' beyond annotations (readOnlyHint, idempotentHint, destructiveHint). It also details the return values, which helps the agent understand behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first states identity, second usage, third outputs. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description explains return values. It covers required inputs and usage. Minor gaps: does not mention min items constraint (20) explicitly nor significance parameter options, but schema fills those.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, so baseline is 3. Description adds value by summarizing the output and reinforcing required inputs ('Provide two price series'). It does not repeat schema but complements it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Complete pairs trading signal' and lists all components (cointegration, Hurst, z-score, half-life, hedge ratio). It explicitly says 'Replaces 4 individual calls', distinguishing it from sibling tools like stats_cointegration, stats_hurst-exponent, stats_zscore.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description says 'Use when analyzing a pairs trading opportunity' and 'Provide two price series'. It contrasts with individual calls by noting it combines them. However, it does not explicitly state when not to use or mention alternatives beyond the replaced calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations, such as 'PAID ONLY — no free tier' and 'Provide daily returns'. Annotations already indicate readOnlyHint=true and idempotentHint=true, which are consistent with the description's promise of a non-destructive, safe analysis.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences), front-loaded with the most important information, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the metrics returned but does not specify the exact structure of the output (e.g., JSON format). Given the absence of an output schema, slightly more detail on the return format would improve completeness. However, the list of metrics is adequate for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add significant new meaning to parameters beyond what the schema already provides (e.g., 'daily returns series' is mentioned in both).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a complete risk tearsheet with a specific list of metrics (Sharpe, Sortino, VaR, etc.) and explicitly mentions it replaces 7 individual calls, distinguishing it from sibling tools like risk_drawdown, risk_kelly, and stats_sharpe-ratio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Use when you need a complete risk tearsheet for a return series. Instead of calling 7 individual risk/stats endpoints...' It also indicates that the tool is paid-only, setting clear expectations for when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, idempotentHint, destructiveHint. Description adds that it returns ranked candidates with risk/reward ratios, breakevens, and full Greeks, and notes it's paid only. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with main purpose, then usage guidelines, then return details and cost note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description explains return content (ranked candidates with risk/reward, breakevens, Greeks). Covers required parameters and usage context. Sufficient for agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 88%. Description mentions spot, vol, DTE, and strategy, which matches schema. It does not add significant new semantics beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it scans and ranks vertical spreads by risk/reward, and it replaces multiple individual options/price calls. This distinguishes it from siblings like options_price, options_strategy, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (evaluating multiple vertical spread candidates) and notes it replaces 8-16 calls. Also mentions paid tier constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds behavioral context: returns include NPV, profitability index, and discounted cash flow breakdown. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words. The key information (purpose, usage, output) is front-loaded and concisely expressed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description covers input expectations, output structure (NPV, PI, DCF breakdown), and typical usage pattern. Complete and informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds meaning by noting the first cash flow should be negative and that discount_rate is per period, which goes beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Net present value of a cash flow series' with a specific verb and resource, and distinguishes from sibling TVM tools like tvm_irr and tvm_cagr by specifying the usage context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when computing net present value of a series of cash flows' and provides practical usage hints (first cash flow typically negative). However, it does not explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/QuantOracledev/quantoracle'
If you have feedback or need assistance with the MCP directory API, please join our Discord server