Finance Toolkit

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.2.0
Disambiguation2/5
Several tools occupy overlapping territory: 'overlap' and 'volatility' both include Bollinger Bands and Keltner Channels, while 'performance' and 'risk' share volatility-related metrics. 'search_categories' vs 'search_by_category' are especially easy to confuse, and 'search_metrics' vs 'search_instruments' sound similar despite different purposes.
Naming Consistency2/5
Most tools are single-word category nouns like 'breadth', 'liquidity', and 'models', but then four tools use snake_case verbs: 'search_categories', 'search_by_category', 'search_metrics', 'search_instruments'. There is no consistent verb_noun or noun pattern across the set.
Tool Count3/5
At 26 tools, the server is on the heavy side of the ideal range, but each tool represents a distinct finance domain category and the three search tools help navigate the large surface. It is borderline rather than egregiously overstuffed.
Completeness5/5
The toolkit covers technical analysis, fundamental ratios, valuation, risk, performance, econometrics, options, fixed income, macro data, ESG, discovery, and raw market data. There are no obvious dead ends or missing core workflows for a data/analytics-focused finance server.
Average 4/5 across 26 of 26 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 3 community issues answered or closed in the last 6 months
- 319 commits in the last 12 weeks
- Last stable release on August 18, 2026
- 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.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the description need not repeat those. It adds some behavioral context by specifying the ticker requirement (though this contradicts the schema) and supporting quarterly or date-range options. However, it does not describe output behavior, error conditions, or how multiple tickers are handled beyond a comma-separated format, leaving gaps that annotations don't cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bloated, repeating the full list of indicator names that already exist in the enum. It front-loads the purpose but then dumps the entire enum list in a single paragraph, which is redundant and wastes tokens. A concise reference to the schema or a few examples would be more efficient. The description is not appropriately sized for its content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (25 parameters, many indicator-specific), the description provides only a high-level overview (ticker requirement, quarterly/date support) and a list of indicators. It does not explain which parameters are needed for which indicators (though the schema covers some), nor does it mention that the output schema is available. The description also omits guidance on parameter interactions and fails to resolve the ticker requirement ambiguity, making it incomplete for such a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but many parameter descriptions are placeholders like 'Value for diluted.' or 'Value for periods.' that add little meaning. The description adds a few useful notes (ticker requirement, quarterly/date support), but it also incorrectly states tickers are required when the schema lists them as optional, confusing parameter semantics. It does not clarify which optional parameters apply to which indicators beyond what the schema already says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'Pre-computed financial models' and lists the specific models (WACC, DuPont, DCF, etc.), which conveys a specific verb (compute) and resource (financial models). It distinguishes from sibling categories by listing its unique indicators, though it doesn't explicitly name alternatives like 'valuation' or 'profitability' tools, so it lacks a direct differentiation statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions prerequisites ('Requires tickers=...') and options (quarterly, date range), but it does not provide guidance on when to choose this tool over sibling categories (e.g., momentum, liquidity). There is no explicit 'when-to-use' or 'when-not-to-use' advice, and no mention of alternatives, so agents receive little direction on tool 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, idempotentHint, and openWorldHint, so the safety profile is established. The description adds only the tickers requirement and indicator list, but no deeper behavior like error handling, return format, or rate limits, so it meets but doesn't exceed expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is front-loaded and informative, but the long list of indicators duplicates the enum in the input schema, creating redundancy and length. This list adds bulk without explaining each indicator or its parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 39 parameters and 34 possible indicators, the description should explain which parameters apply to which indicator. It only provides a flat list of indicators and a ticker requirement; parameter-indicator mapping is left entirely to the schema, which has many tautological descriptions. An output schema exists but return semantics are not described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% description coverage, so the baseline is 3. The description adds guidance on tickers ("Requires tickers='AAPL'") and lists indicators, but most parameters remain poorly explained with generic "Value for X" schema descriptions; the description does not compensate for the 30+ parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states "Option pricing and Greeks (Black-Scholes model, binomial tree, delta, gamma, theta, vega, rho, implied volatility)", which clearly identifies the tool's domain and distinguishes it from broader siblings like volatility or models. It also enumerates 34 available indicators, making the scope concrete. However, it lacks an explicit verb, so it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context with "Requires tickers='AAPL' — use comma-separated values for multiple tickers," and lists the available indicators to choose from. It does not explicitly name alternatives or when-not-to-use, but the context is sufficient for a domain-specific tool.
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?
Beyond the readOnlyHint annotation, the description explains that the tool automatically applies to price data, which is a behavioral detail. It does not discuss rate limits, error handling, or output structure, but the read-only and idempotent hints already cover the main expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose. The list of indicators is somewhat redundant with the enum in the schema, but it is brief and does not overwhelm. The two paragraphs are well-structured and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (19 parameters), the description does not explain the meanings of many parameters (e.g., short_window, standardize, volume_divisor) or the output format. However, the schema descriptions compensate, so the description is minimally sufficient but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides detailed descriptions for all parameters (100% coverage). The description adds limited extra value by clarifying that tickers should be comma-separated and by listing the available indicator names, but it does not explain windows, standardization, or other nuances beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool provides market breadth technical indicators and lists several examples (e.g., McClellan Oscillator, OBV). It distinguishes the category from sibling tools like momentum or liquidity by naming the indicator family, though it does not explicitly contrast with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a key usage hint that price data is automatically handled ('no need to fetch prices first') and specifies that tickers should be provided. However, it does not mention when not to use this tool or mention alternative tools, leaving some ambiguity about selection among sibling indicators.
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, openWorldHint, and idempotentHint, covering the safety profile. The description adds the scoping fact that it doesn't need tickers or countries, but it doesn't disclose other behavioral aspects like pagination behavior or response shaping beyond what's in the schema. With annotations provided, this meets a baseline but adds limited extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a short purpose statement followed by a list of 27 indicators. The list is necessary to inform the agent of valid choices and avoids excessive prose. It front-loads the core purpose and is structured clearly, though the indicator list could have been linked to the enum rather than repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 21 parameters, the description is notably incomplete. It does not explain that parameters like price_lower, volume_higher, etc., are filters applied only to certain indicators, nor does it clarify which indicators accept which filters. The schema's placeholder descriptions ('Value for price_lower') add little. While an output schema exists, the description still fails to give the agent a coherent picture of how to combine the indicator with the other parameters. This is a significant gap given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (though most are trivial 'Value for X'), so the baseline is 3. The description itself adds no parameter semantics beyond listing possible indicator values, which are already in the enum. The schema's indicator description (with the example and behavior of omission) is helpful, but it's not from the tool description. Thus, no added value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'market discovery tools' (lists, screeners, gainers/losers, etc.), and the 'No tickers or countries needed' hint distinguishes it from sibling tools dealing with specific instruments or metrics. It's specific enough about the resource category, though it covers a broad set of sub-functions via the 'indicator' parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'No tickers or countries needed', which tells agents when to use this tool (for market-wide discovery without specific instrument identifiers). It lists available indicators, giving a clear menu of use cases. However, it doesn't explicitly name alternative tools for scenarios with tickers or countries, so guidance is clear but not exhaustive.
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 openWorldHint, so the safe calculation nature is established. The description adds that parameters are passed directly and enumerates indicators, but it does not describe return behavior, response format, or edge cases beyond what annotations and schema already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then clarifies the input style, then enumerates the indicators. It is reasonably concise given the breadth of the tool, though the indicator list partially duplicates the enum in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity of 40 parameters and 12 indicators, the description could do more to map indicators to their relevant parameters. It provides the indicator names and general input guidance, but stops short of helping an agent determine which parameters to supply for each specific calculation; output-schema presence helps but does not fully compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter descriptions in the schema are extensive, so the description doesn't need to repeat all 40 parameters. It does add helpful examples like coupon_rate, maturity, and spot_rates, though it also mentions face_value which does not appear in the schema, causing slight confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs bond and derivative valuation calculations with a specific list of supported indicators, such as duration, yield-to-maturity, and Z-spread. It also distinguishes this tool from market-data siblings by noting that no tickers or countries are needed and that parameters are provided directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context: it is for calculations using direct bond/derivative parameters rather than ticker-based lookups, and it lists available indicators. However, it does not explicitly say when to prefer this tool over sibling tools like valuation, rates, or options, nor does it give exclusions 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?
Beyond the readOnly/idempotent annotations, the description adds that price data is fetched automatically (no need to fetch prices first) and enumerates available indicators. Minor limitation: no mention of output format or rate limits, but annotations cover critical side-effect aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and organized into two short paragraphs. The list of indicators is redundant with the schema enum, but it adds a quick reference. No filler or excessive detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complex input schema, the description provides helpful context (price data handling, indicator list) but omits a clear definition of 'overlap' and lacks guidance on parameter interactions. The presence of an output schema may cover return formatting, but the description alone is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies 'tickers' and 'indicator' (comma-separated, list of options) and 'show_columns' indirectly. However, many parameters (af_start, af_increment, sensitivity) have generic 'Value for X' descriptions in the schema, and the description does not enrich them. Schema coverage is 100% but semantics are weak for most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool computes technical overlap indicators (SMA, EMA, Bollinger Bands, Keltner Channels) and lists available indicators. It clearly identifies the resource (price data) and the general action, but could be more precise about the 'overlap' concept and differentiate from sibling categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for overlap indicators and notes no need to fetch prices separately, but does not explicitly contrast with sibling tools like momentum or volatility. It lacks clear when-to-use vs alternatives guidance.
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 openWorldHint=true, so the safety profile is covered. The description adds that price data is fetched automatically and that omitting the indicator returns the list of available indicators, which is useful. However, it doesn't disclose details like rate limits, pagination, or what happens with invalid tickers, but given the annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. It uses a short paragraph and a bullet-like list of indicators. It avoids unnecessary fluff and provides essential usage hints. Slightly more structure could be added, but it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18 parameters, 7 indicators) and the presence of an output schema, the description is reasonably complete. It covers the key usage points: automatic price fetching, required tickers, indicator list, and window defaults. It doesn't explain return values, but the output schema covers that. It could mention the 'show_columns' parameter for reducing output, but that's in the schema. Overall, adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds context for the 'indicator' parameter (required, omitting returns list) and the 'tickers' parameter (comma-separated, required). It also explains the 'window' parameter defaults for different indicators. This adds value beyond the schema, but the schema already does most of the work, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes volatility technical indicators (ATR, True Range) and lists the available indicators. It distinguishes itself from siblings by focusing on volatility metrics, though it doesn't explicitly contrast with other technical analysis tools like momentum or overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: it states that price data is fetched automatically (no need to fetch prices first), requires tickers, and lists available indicators. It also mentions that omitting the indicator returns the list of available indicators. However, it doesn't explicitly state when to use this tool versus alternatives like momentum or overlap.
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 openWorldHint, so the safety profile is covered. The description adds the 'Requires tickers' constraint and the indicator list, but it does not describe output shape, p-value conventions, or behavior when required inputs are omitted. With an output schema present, this is acceptable but not especially rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first three sentences are compact and front-loaded, but the description then appends a 48-item 'Available indicators' list that duplicates the tool's own enum. This creates a long, dense wall of text that undermines conciseness and adds little value for an agent that can already read the enum in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 80 parameters and 48 selectable indicators, the description provides the essential context: what the tests are, when to use them, and the tickers requirement. The presence of an output schema, annotations, and a detailed indicator enum reduces the need to document return formats and every parameter; still, per-indicator selection guidance is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 per the rubric. The description adds a tickers requirement and repeats the indicator enum, but it does not add meaningful semantics for the other 79 parameters beyond what the schema already provides, many of which have generic descriptions like 'Value for p.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Statistical/econometric tests on price or return series') and enumerates concrete test families such as ADF, Johansen, Granger causality, and ARCH-LM, making the tool's scope unambiguous. It clearly differentiates this tool from sibling metric categories by emphasizing hypothesis testing and inference rather than simple metric calculation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does 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 for pairs-trading/spread-modeling foundations or diagnosing return-series properties.' It also gives a concrete invocation hint ('Requires tickers=\'AAPL\''). However, it does not mention when not to use it or point to alternative sibling tools, so it stops short of top-tier 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?
With readOnlyHint, openWorldHint, and idempotentHint already present, the description adds useful behavioral context: price data is handled automatically, tickers are required, and multiple tickers are supported via comma separation. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is front-loaded and useful, but the description includes a long list of 22 indicator names that duplicates the indicator enum in the input schema. The list adds bulk without much new information, making the description less concise than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (27 parameters) and rich schema, the description provides a reasonable overview but does not clarify which parameters apply to which indicators or how to pick among the many indicator options. The output schema and annotations help, but the description leaves important selection guidance to the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema carries most parameter meaning. The description adds that tickers is effectively required and that defaults differ by indicator, but many parameters still rely on generic schema descriptions like 'Value for window_1' without further explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing momentum technical indicators (RSI, MACD, Stochastic Oscillator, etc.) and is distinct from categories like volatility, breadth, and performance. It lacks an explicit verb like 'computes' or 'returns,' but the scope and examples make the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context: apply momentum indicators to price data automatically, no need to fetch prices first, and tickers must be supplied as 'AAPL' or comma-separated values. It does not explicitly mention when not to use it or recommend sibling tools, so it stops short of 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?
The description adds useful behavioral detail beyond the readOnly/idempotent annotations: cumulative=true returns a compounded growth index rebased to 1, rolling=N changes output to a rolling N-period value, and period='daily' is explicitly rejected. This gives the agent practical expectations about output shape and supported frequencies without contradicting 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core sentences are dense and informative, front-loading the main metrics and key parameter behaviors. However, the long 'Available indicators' list duplicates the input schema enum and appears truncated mid-word with 'g', which is redundant and structurally messy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is an indicator hub with 26 parameters and an output schema, the description covers the most important decision-relevant behavior: available metric families, cumulative/rolling semantics, required tickers, and unsupported daily periods. It does not explain benchmark_ticker defaults or factor-specific parameters, but those are already documented in the schema and the description provides enough orienting context for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 26 parameters. The description adds meaningful semantics for high-leverage parameters by explaining cumulative=true, rolling=N, period options, tickers formatting, and required indicator behavior. This goes beyond the schema's generic per-parameter descriptions, especially for rolling and cumulative combinations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as 'Pre-computed risk-adjusted performance metrics' and enumerates specific metrics (Sharpe, Sortino, Alpha, Beta, CAPM, etc.), which distinguishes it from sibling tools like momentum, volatility, and risk. However, it lacks an explicit action verb such as 'calculates' or 'returns', and the broad tool name 'performance' makes the purpose slightly less crisp than a direct command.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage constraints: tickers must be supplied like 'AAPL', comma-separated for multiple tickers, and period='daily' is unsupported with explicit alternatives ('use weekly, monthly, quarterly, or yearly'). It does not, however, explain when to use this tool instead of sibling tools such as risk or volatility, or when to choose one indicator family over another.
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 idempotentHint=true, so the safety profile is covered. The description adds 'Pre-computed' as behavioral context and mentions that this tool avoids raw financial statements, but it does not disclose much beyond that. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening sentences are concise and front-loaded with the key purpose and usage guidance. However, the large list of available indicators duplicates the enum already present in the input schema, making the description longer than necessary without adding new information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—12 parameters, a rich input schema, an output schema, and clear annotations—the description provides the essential selection and invocation cues: indicator choice, tickers requirement, time-series options, and differentiation from raw financial statements. It does not need to restate every schema detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds a meaningful operational note: tickers must be set (e.g., 'AAPL') even though the schema does not mark tickers as required. It also highlights quarterly and date-range parameters. The many other parameters are well documented in the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing pre-computed profitability ratios and names major metrics like gross margin, ROE, and ROA. It distinguishes itself from raw financial statements and, through its metric list, from sibling ratio categories, though it lacks an explicit verb like 'Returns' or 'Gets'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use instead of raw financial statements' and gives a practical invocation requirement: 'Requires tickers="AAPL"'. It also mentions quarterly=true and start_date/end_date support, giving clear usage context, though it does not explicitly contrast with sibling tools like solvency or liquidity.
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, openWorldHint, and idempotentHint, and the description adds meaningful behavioral context: FRED-backed indicators return no data without an API key, only return a 'United States' column, and rolling/trailing have specific smoothing/sum semantics. 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense but overly long and poorly structured as a single wall of text. The 'Available indicators' list duplicates the enum in the input schema and is truncated mid-word ('g'), which is a structural defect. It could be tightened with headers and by removing redundant enumeration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 16 indicators and 18 parameters, the description covers the most important cross-cutting constraints: country requirements, ticker prohibition, FRED API key dependency, and rolling/trailing behavior. The output schema and rich input schema cover the remaining details, so the description is complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds value beyond the schema by explaining how countries should be used, that tickers= must not be used, and what rolling/trailing mean in practice. This is more than the schema's generic parameter descriptions provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing interest rate data and enumerates specific rate families (central bank policy rates, government bond yields, EURIBOR, ECB/Fed rates, Treasury yield curve, etc.), which distinguishes it from sibling tools like fixed_income or government. It lacks an explicit verb like 'retrieve' or 'get', but the resource scope is 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage constraints: requires countries='United States', forbids tickers=, supports start_date/end_date and quarterly=true, and explains rolling/trailing behavior. It also clarifies the optional FRED API key and which indicators are affected. It does not name sibling tools as alternatives, so it stops short of a 5.
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 openWorldHint, so the safety profile is covered. The description adds that it returns pre-computed ratios and supports multiple tickers, but does not mention any side effects, data source variability, or rate limits. This adds moderate context beyond annotations but not rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the purpose and includes a long list of indicators. The indicator list is redundant with the schema enum, but the overall length is manageable and the essential information is up front. It earns a high score for being relatively concise while conveying core details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 params, many indicators) and the presence of a detailed schema and output schema, the description adequately sets expectations: it identifies this as an efficiency-ratio tool, explains it should replace raw financial statements, and lists supported metrics. It does not explain all parameter behaviors, but the schema covers those. The description is complete enough for an agent to know when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 12 parameters already have detailed descriptions. The description restates tickers format and quarterly/date support, and lists indicators already present in the enum, adding little extra semantic value. Also, the claim 'Requires tickers=...' conflicts with the schema where tickers is optional with a default, creating minor confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool provides 'Pre-computed efficiency ratios' and enumerates specific metrics (asset turnover, inventory turnover, DSO, DPO, CCC). It also distinguishes itself from raw financial statements and lists available indicators, making the purpose and scope 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'Requires tickers=...' and 'Use instead of raw financial statements.' It mentions support for quarterly and date range parameters, but does not explicitly contrast with sibling tools (e.g., liquidity, solvency) or state when not to use it. Still, the classification by ratio type is evident from the name and sibling list.
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 and idempotentHint, indicating safe read operation. The description adds that it returns a Markdown table or error message, providing context beyond 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and front-loaded with purpose. However, the Args/Returns section duplicates schema information, making it slightly less efficient than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 required parameter, output schema present, annotations provided), the description covers all essential aspects: purpose, parameter, and return format. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The description text repeats the same information (category examples) without adding 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List every available metric/tool') and the resource ('within a category'), with specific examples of categories. It distinguishes itself from sibling tools which are individual category names, as this tool aggregates items within a given category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (to discover available metrics/tools in a category) but does not explicitly state when to use this tool versus alternatives like 'search_metrics' or individual category tools. There is no 'when not to use' 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 declare readOnlyHint=true and idempotentHint=true, but the description adds context beyond that: it clarifies that tickers are required, explains quarterly toggle, and lists all supported indicators. It also states 'pre-computed' and recommends using it over raw statements, which conveys the tool's derived nature. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and usage guidance, then lists the available indicators. The indicator list is somewhat redundant with the schema enum but still useful for quick scanning. It is concise overall, though the final list sentence is long. No wasted prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 13 parameters and a full schema plus output schema, the description covers the essential context: what the tool does, when to use it, and key usage constraints. It does not explain return formats, but the output schema exists. The description is sufficiently complete for an agent to invoke the tool correctly, especially with the indicator list and example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does 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 reinforces tickers as a requirement and names quarterly/start_date/end_date, but these are already well-documented in the schema. The indicator list duplicates the enum. The description adds minimal new semantic value beyond the schema, though it does give a concrete example (tickers='AAPL').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides pre-computed solvency ratios (debt-to-equity, interest coverage, debt-to-assets, net debt to EBITDA), giving a specific verb+resource and distinguishing it from sibling tools like liquidity or profitability. It also lists the exact available indicators, leaving no ambiguity about its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use instead of raw financial statements', providing a clear when-to-use recommendation. It also gives an example requirement (tickers='AAPL') and mentions quarterly flag and date range support. However, it does not explicitly state when not to use it or mention alternatives like liquidity for other ratio types.
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, openWorldHint, and idempotentHint. The description adds valuable behavioral context: two indicators 'require a Premium FMP subscription' and 'are fetched on first use only.' This goes beyond the annotations and alerts users to potential access restrictions and caching behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first paragraph is concise and front-loaded with essential information. The second paragraph is a long list of indicators, but it is a single sentence and serves as a useful reference. Some redundancy exists because the same list appears in the schema enum, but the overall structure is clear and not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, 1 required, output schema present), the description covers the essential usage scenarios: ticker requirement, quarterly/dates, and the premium subscription caveat. It doesn't explain return values, but the output schema fills that gap. The description is sufficiently complete for an AI agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented. The description reinforces key parameters like tickers, quarterly, and start_date/end_date, but does not add deeper semantic meaning beyond what the schema provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 'Pre-computed valuation ratios' and lists specific metrics (P/E, EPS, EV/EBITDA, etc.). It distinguishes itself from sibling tools by focusing on valuation and explicitly says to use it 'instead of raw financial statements.' The purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Requires tickers="AAPL"' and 'use comma-separated values for multiple tickers.' It explicitly directs users to use this tool instead of raw financial statements, which is an alternative. It lacks explicit when-not-to-use instructions relative to sibling tools, but the guidance 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?
Discloses typo tolerance, fuzzy matching rules for tokens <4 chars, and return format (Markdown table or guidance message), adding value beyond readOnly and idempotent 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one sentence for purpose, then bullet-point details. No wasted words, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a simple search tool with one parameter: covers behavior, return format, and fuzzy details. Could mention when to prefer siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers the query parameter with 100% description coverage; description adds example queries ('debt', 'moving average', etc.) that help understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool searches across all metrics by keyword with typo tolerance, distinguishing it from category-based siblings like search_by_category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for fuzzy keyword search across metrics, but no explicit when-to-use or alternatives compared to siblings like search_instruments.
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 value by specifying the return format ('Formatted Markdown table of matching instruments, or an error message'), which goes beyond 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured docstring with clear sections (Args, Returns). Every sentence serves a purpose, no fluff, and the main purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, both fully described in schema and description, output schema exists), the description fully covers what the tool does and returns. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does 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 examples for 'query' (e.g., 'Apple', 'META', '0000320193') and clarifies the default for 'search_method', providing additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search for ticker symbols by company name, symbol, CIK, CUSIP, or ISIN,' specifying the verb and resource. It distinguishes from sibling tools like 'search_by_category' and 'search_metrics' 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding instruments by identifiers but does not explicitly provide guidance on when to use this tool versus alternatives. It lacks when-not-to-use or exclusionary context.
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?
With readOnlyHint=true, openWorldHint=true, and idempotentHint=true already declared, the safety profile is fully covered by annotations — the burden on the description is low. The description adds genuine value on top by disclosing the dual-query-style behavior (tickers vs countries) and characterizing rolling/trailing as 'smoothing/summation.' No contradiction with the read-only annotations; the description consistently implies pure data access.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, each with a distinct job: state the domain, give usage patterns, differentiate from siblings. The 'Available indicators' enumeration replaces longer prose and mirrors the enum. For a 13-parameter dispatcher tool this is appropriately sized — nothing extraneous, nothing missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex dispatcher with 13 parameters, an output schema, and safe read-only annotations, the description covers the essential decision surface: domain, parameter-selection strategy, special smoothing behavior, and indicator list. The presence of an output schema relieves it of explaining return values. It could have more explicitly stated the dispatcher pattern (one call = one of three named endpoints) and acknowledged the annual/quarterly dimension, but nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with rich per-parameter descriptions, so baseline is 3. The description elevates this by disambiguating the easily-confused rolling (smoothing) and trailing (summation) parameters, and by teaching which parameter family fits which indicator. A minor blemish: the schema's indicator enum example ('get_asset_turnover_ratio') is stale and inconsistent with the actual enum values, which the description partially papers over by listing the three real indicator names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a clear domain statement ('Environmental and ESG data') followed by specific, actionable examples mapping indicators to parameters ('For ESG scores... use tickers="AAPL"'). Closes with explicit sibling differentiation ('This is the only tool that accepts BOTH tickers= and countries=') which positions it squarely against the breadth/momentum/volatility family. The verb+resource is specific and the tool's dispatcher role is evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete when-to-use-which-parameter guidance (tickers for ESG scores, countries for carbon/renewable data) and flags the rolling/trailing behavior with examples. The 'only tool that accepts BOTH' phrasing helps rule out alternatives, though it never names a specific sibling to prefer instead. Loses a point for not addressing when NOT to use this tool (e.g., single-instrument financial metrics that belong to siblings like momentum or valuation).
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, covering the safety profile. Description adds meaningful behavioral info: mandatory countries constraint, prohibition on tickers, and explains rolling vs trailing data transformations. No contradictions. Could mention pagination or output size limits but output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs. First paragraph explains purpose and key constraints; second lists indicators. Front-loaded. No fluff. The indicator list is redundant with schema enum but serves as quick reference. Sufficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high schema coverage and output schema present, the description is complete. It covers all critical usage constraints (countries required, tickers forbidden, date/frequency options) and clarifies the main non-obvious parameters (rolling vs trailing). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. However, description adds critical information: countries must be provided (default empty but required), tickers= not used, rolling=N and trailing=N semantics clarified (moving-average vs trailing sum), and shows comma-separated example. This elevates beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's function: government fiscal metrics by country (debt, deficit, expenditure, revenue, tax revenue). It lists all 11 available indicators explicitlyaining any ambiguity about scope. The verb 'get' and the resource 'fiscal metrics' with country parameters 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit conditions: requires countries='United States' (with comma-separated for multiple), supports date range and quarterly, and explicitly warns NOT to use tickers=. This gives strong practical usage guidance. Minor gap: doesn't mention when to prefer this over sibling economic tools, but that's acceptable given the tool's clear domain.
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 openWorld, so the description doesn't need to restate safety. It adds useful behavioral details such as returning the list of indicators when omitted, behavior of standardize and growth parameters, and how show_columns affects output, which 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that covers key facts: what it provides, the required tickers, and the available indicators. It avoids redundancy and is easy to parse, with the parameter list neatly embedded in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no explicit output schema, the description sufficiently conveys what to expect: pre-computed ratios, options for standardization/growth, and filtering via show_columns. It also informs about placeholder behavior when indicator is omitted. Missing details like exact output format are not critical for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with detailed descriptions for every parameter. The description supplements this with practical examples (e.g., comma-separated tickers, quarterly=true, start_date/end_date) and clarifies that indicator is required, adding value beyond the schema's generic text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool provides pre-computed liquidity ratios, lists the specific indicators available (current, quick, cash, working capital, etc.), and distinguishes it from raw financial statements. This clearly defines the tool's purpose and sets it apart from other ratio-focused 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using this tool instead of raw financial statements and explains required parameters (indicator) and optional ones (tickers, quarterly, date range). However, it doesn't explicitly contrast with sibling ratio tools like profitability or solvency, though the name and indicator list make the use case 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?
Beyond the readOnly/openWorld/idempotent annotations, the description discloses meaningful behavioral traits: two indicators are US-only and ignore the countries argument, they require a FRED API key, and they always return only a 'United States' column. It also clarifies that rolling is moving-average smoothing and trailing is a trailing-period sum, adding real 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well organized: scope, key usage constraints, transformation options, special-case caveats, and a clear indicator list. The indicator list partially duplicates the schema enum, and the 'Requires countries="United States"' phrasing is slightly ambiguous, but every sentence contributes operational content and the text is 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters, an output schema, and a multi-indicator tool, the description covers the critical operational context: country requirements, date/quarterly support, rolling/trailing transforms, FRED-specific limitations, and the full indicator set. An output schema exists and covers return structure. Minor gaps include not clarifying the OECD/GMDB source distinction in the description and the slightly ambiguous 'Requires countries' wording.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all 13 parameters with good descriptions, so the baseline is 3. The description adds extra semantic value by explaining comma-separated countries, prohibiting tickers, clarifying rolling/trailing behavior on raw series, and highlighting country/API-key constraints for FRED indicators. It does not exhaustively elaborate every parameter, but the schema covers those adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's scope: 'Labour and social metrics by country' and enumerates the exact indicators available (unemployment, productivity, population, poverty, income inequality, nonfarm payrolls, initial jobless claims). This distinguishes it from sibling tools like 'macroeconomics' or 'government' and gives a specific, actionable purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong practical guidance: countries must be specified, comma-separated values are supported, tickers should NOT be used, and date/quarterly/rolling/trailing parameters are supported. It also flags the FRED API key requirement and US-only behavior for two indicators. However, it does not explicitly name alternative tools or state when to prefer a sibling tool over this one.
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?
While annotations already mark this as read-only, idempotent, and open-world, the description adds beyond that by specifying ticker requirements, indicator list, and the unusual behavior of two indicators that ignore most parameters. This supplements the annotation with practical operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear lead sentence, usage guidance, and a bullet list of indicators. It's slightly verbose but efficiently organized, front-loading the key purpose and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (20 parameters, many indicators, output schema), the description covers the main purpose, usage boundaries, and special cases. It doesn't repeat output schema details because that's already present, and it provides enough context for an agent to select and invoke the tool appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so baseline is 3. The description adds some context (e.g., tickers format, special case for two indicators) but does not clarify vague schema fields like 'Value for fill_nan' or 'Value for show_errors'. It does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool provides raw financial data across numerous categories (prices, statements, profiles, etc.) and contrasts it with dedicated tools for pre-computed metrics. This clearly distinguishes it from its siblings such as momentum, volatility, and profitability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit direction: 'Use this ONLY for raw data needs' and points to alternative tools for ratios, performance, risk, or model metrics. It also notes the ticker requirement and explains that get_market_risk_premium and get_commitment_of_traders ignore most parameters, providing clear when-to-use and when-not-to-use guidance.
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?
Beyond the annotations (readOnlyHint, idempotentHint), the description reveals significant behavioral traits: some indicators require a free FRED API key, six indicators return only 'United States' regardless of countries, get_commodity_forward_curve returns dated futures contracts instead of a country series, and rates/ratios are returned as decimal fractions. These details go well beyond what annotations or schema convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but packed with essential usage details and special cases that are necessary for correct invocation. It front-loads the core purpose and then organizes guidance logically (general usage, then indicator-specific notes). Given the tool's complexity (19 params, 44 indicators), the length is justified and not fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a highly complex tool with many parameters, indicators, and edge cases. The description covers the major pitfalls: required countries, source selection, FRED key requirements, US-only behavior, rolling/trailing semantics, and output format (decimal fractions). The presence of an output schema reduces the need to describe return values, and the description addresses the remainder comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, so baseline is 3. The description adds meaning by explaining rolling as moving-average smoothing and trailing as trailing N-period sum, clarifying source selection (gmdb_source, oecd_source), and detailing special parameter requirements (commodity for forward curve, countries for most indicators). This enriches understanding beyond the schema's field-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides macroeconomic indicators for countries and lists a comprehensive set of specific indicators (GDP, CPI, inflation rate, etc.), which clearly distinguishes it from sibling finance/metric tools like momentum or liquidity. It uses a specific verb-resource construction and the scope is 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage instructions: requires countries='United States', do not use tickers, supports start_date/end_date, quarterly, rolling, trailing, and includes special-case guidance for specific indicators (oecd_source for CPI, commodity for forward curves, FRED key for US-only indicators). It lacks explicit exclusions for when not to use the tool, but the unique domain makes the differentiation 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, idempotentHint, and openWorldHint, so the safety profile is clear from the structured data alone. The description adds value by explaining behavioral nuances beyond the schema, such as the `rolling` behavior for different indicators and the `method` parameter defaults for specific indicators. There's no contradiction, so no points deducted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but the complexity of the tool (47 parameters, 42 indicators) justifies it. The most critical information is front-loaded, and the 'Available indicators' list, while lengthy, improves usability since it can be referenced directly. One minor deduction for some redundancy with schema enums, but overall it's well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and 47 parameters, the description covers the most critical constraints and interactions well. It explains the date handling via `period`, the roll-up via `rolling`, and default behaviors for parameters like `method`. However, it doesn't discuss all parameter combinations, and some less-common parameters like `within_period` or `show_full_results` are left to the schema. Still, it covers the critical mass for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description provides crucial semantic context that the schema lacks. For example, it explains how `moving` and `period` interact, clarifies the meaning of `tickers` (comma-separated), and details the `method` parameter's per-indicator defaults. It also explains the `threshold_percentile` parameter, which is not explained in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing pre-computed risk metrics, listing a comprehensive set of metrics (VaR, CVaR, EVaR, GARCH, etc.). It differentiates from siblings by focusing solely on risk-related indicators and providing a large list of 'Available indicators'. The scope is explicit and detailed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage constraints: 'Requires tickers='AAPL'' and 'Does NOT support period='daily''. It also explains how to use `rolling` and `period` together, and notes the behavior when `indicator` is omitted. These details far exceed what's in the schema, giving clear guidance on when and how to use 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 provide readOnlyHint=true and idempotentHint=true, so the description adds value by specifying the return format (Markdown table). 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a returns line, all concise and front-loaded with the core purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema, the description is complete: it explains what the tool does, how to use it, and what it returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% by default. Description doesn't need to add parameter info, and baseline is 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all metric categories and their tool counts. It distinguishes from siblings by positioning itself as an overview tool, separate from the specific category tools and search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use this first to understand available categories before calling list_metrics_by_category. Provides clear sequential usage guidance.
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:

[![FinanceToolkit MCP server](https://glama.ai/mcp/servers/JerBouma/FinanceToolkit/badges/card.svg)](https://glama.ai/mcp/servers/JerBouma/FinanceToolkit)

Score Badge

Copy to your README.md:

[![FinanceToolkit MCP server](https://glama.ai/mcp/servers/JerBouma/FinanceToolkit/badges/score.svg)](https://glama.ai/mcp/servers/JerBouma/FinanceToolkit)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/JerBouma/FinanceToolkit'

If you have feedback or need assistance with the MCP directory API, please join our Discord server