ROIC.ai Financial Data MCP Server

Official

by roicai

Overview Schema Related Servers Score Discussions

JavaScript

Hybrid

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes, such as listing exchanges versus searching tickers versus retrieving financial statements. Minor overlaps exist (e.g., get_enterprise_value and get_valuation_multiples both include EV metrics, and list_tickers/search_tickers/search_ticker_by_identifier are similar but with different lookup methods), but descriptions sufficiently clarify scope.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern using list_, search_, or get_ prefixes. Names are descriptive and predictable (e.g., list_industries, get_cash_flow, search_ticker_by_identifier). There are no mixed naming conventions or vague verbs.
Tool Count3/5
With 25 tools, the set falls into the borderline-heavy range (16-25). Each tool has a specific financial metric or report, but some could be consolidated (e.g., grouping ratio families). The count is justifiable for a broad financial data API but feels slightly high.
Completeness5/5
The server covers a comprehensive range of financial data: company profiles, news, earnings calls, historical and latest prices, core statements, multiple ratio categories, and valuation metrics. There are no obvious gaps or dead ends for a read-only financial data server.
Average 4/5 across 25 of 25 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
Add a glama.json file to provide metadata about your server.
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.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds no additional safety context. It also does not disclose behavioral traits such as response format, pagination, default period behavior, or how the data is ordered. The listed data components add content context but no behavioral nuance.
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, direct sentence that front-loads the verb and resource and uses a concise list of key data points. Every word contributes useful information, and there is no redundancy or filler.
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?
With no output schema, the description should clarify what the return data looks like. It partially does by naming common cash flow components, but it does not mention that multiple periods can be returned, how date sorting works, or any quirks. For a tool with 8 parameters, the description is minimal but not dangerously vague, especially since the schema covers input semantics.
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% with all 8 parameters explicitly documented, so the description does not need to repeat parameter details. It adds no extra meaning beyond the schema; the data components mentioned in the description relate to response fields, not input parameters, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves cash flow data and enumerates specific data points (operating, investing, financing cash flows, CapEx, free cash flow, dividends), making its function unmistakable and distinct from sibling financial statement tools.
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 provides no guidance on when to use this tool versus alternatives, no mention of typical use cases, and no exclusions or comparisons with other tools like get_income_statement. It merely states what it does, not when it should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the specific metrics returned, which is useful because there is no output schema, but it does not disclose any further behavioral traits such as pagination, defaults, or historical depth.
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?
Single sentence, front-loaded with the action and resource, and lists the metrics without excess words. Every word earns its place.
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?
The tool has 8 parameters and no output schema, but the schema thoroughly documents all parameters. The description explains what the return will contain (the five metrics), which is the key missing piece. It does not explain date/period filtering, but that is available in the schema, so the description is adequate for an experienced 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 all 8 parameters already have descriptions in the schema. The tool description does not add any parameter-specific semantics beyond listing the metric names, which maps to the return value rather than to parameters.
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 uses specific verb 'Get' with resource 'enterprise value metrics' and explicitly lists the metrics (market cap, EV, EV/Sales, EV/EBITDA, EV/EBIT). This clearly distinguishes it from sibling valuation tools like get_valuation_multiples by focusing on enterprise value specifically.
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?
No guidance on when to use this tool versus alternatives. It does not mention any when/when-not conditions or reference sibling tools like get_valuation_multiples or get_profitability_ratios. The description simply states what it returns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds minimal context beyond that, such as that only the most recent transcript is returned, and does not describe error behavior or availability. This is a reasonable baseline given annotations cover the key safety traits.
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 one short, front-loaded sentence that immediately states the action and object. Every word is useful, with no filler or redundancy.
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?
The tool is simple with one well-documented parameter and helpful annotations. The description adequately states the result (the most recent earnings call transcript). However, with no output schema, it could optionally clarify the transcript format or behavior when no transcript exists, leaving minor room for improvement.
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 single required parameter 'identifier' is fully documented in the schema with examples (ticker, CIK, CUSIP, or ISIN), achieving 100% schema description coverage. The tool description does not add any parameter details, so the baseline score of 3 applies.
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 retrieves the most recent earnings call transcript for a company. The phrase 'most recent' differentiates it from sibling tools like get_earnings_call_transcript and list_earnings_calls, giving a specific verb, resource, and scope.
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?
No explicit usage guidance is provided. The description does not mention when to prefer this tool over get_earnings_call_transcript or list_earnings_calls, nor does it state any prerequisites or alternative conditions. The intended use is only weakly implied by the tool name and 'most recent' phrasing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds no additional behavioral details such as return format, pagination, or time-series behavior. It is not contradictory but provides no extra context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that enumerates the key outputs without unnecessary words. It is front-loaded with the verb and resource, making it immediately scannable for an agent.
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?
With no output schema, the description should indicate what the returned data looks like, but it only lists ratio names without mentioning time-series structure or how the period filtering works. The parameter names (period, date_start, date_end) imply time series, but the description does not explicitly confirm this. Overall adequate but with a clear gap in return structure understanding.
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 fully documents all parameters (identifier, limit, order, period, dates, fiscal years). The description adds no parameter-specific meaning, only listing the ratio types returned. Baseline 3 is appropriate since the schema handles parameter semantics.
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 purpose with a specific verb ('Get') and resource ('credit and debt ratios'), and enumerates the specific ratios covered (net/total debt to EBITDA, debt to equity/capital/assets, interest coverage). This distinguishes it from sibling ratio tools like get_liquidity_ratios and get_profitability_ratios.
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 the tool is for obtaining credit and debt ratios but does not explicitly state when to use it over alternatives or provide exclusion criteria. The list of ratios gives context, but there is no direct guidance on selection among sibling ratio tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context (e.g., data delay, market status), but it does not contradict 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 sentence with no filler, directly stating the operation. It is appropriately sized for a simple one-parameter read tool.
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, the fully documented parameter, and the provided annotations, the description sufficiently covers what the tool does and how to invoke it. No output schema exists, but the return value is self-evident from the tool's name.
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 fully documents the 'identifier' parameter with supported formats (ticker, CIK, CUSIP, ISIN) and an example, achieving 100% schema coverage. The description adds nothing beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('most recent stock price'), clearly stating the tool's purpose. The qualifier 'most recent' distinguishes it from the sibling tool 'get_stock_prices', which implies historical price data.
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?
No guidance is provided on when to use this tool versus alternatives like 'get_stock_prices' or 'get_company_profile'. The description simply states the action without contextual cues or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read behavior is covered. The description adds a list of metrics, which clarifies the scope of data returned but does not disclose additional behavioral aspects such as period handling, normalization, or any quirks. With annotations present, this is acceptable but not exceptional.
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 sentence that front-loads the main purpose ('Get per-share metrics') and then lists the metrics. It is concise, with no wasted words or redundancy. Every part contributes to the overall meaning.
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 has 8 parameters and no output schema, the description does not fully explain what the response looks like (time series? object? how period filters interact?). It lists the metrics but does not clarify the output structure or behavior with parameters like limit/order/fiscal year. This is a moderate gap for a data retrieval 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 8 parameters are already described in the input schema. The description does not add any additional parameter-level meaning beyond listing the metrics, which does not map specifically to parameters. Baseline 3 is appropriate since the schema carries the heavy lifting.
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 verb ('Get') and the resource ('per-share metrics'), and lists specific metrics (EPS, diluted EPS, revenue, EBITDA, dividends, book value, cash flow, free cash flow per share). This distinguishes it from sibling tools like get_income_statement or get_cash_flow, which would provide raw figures rather than per-share values.
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 when to use the tool (when per-share metrics are needed) via the list of metrics, but does not explicitly state alternatives or exclusion criteria. It lacks guidance like 'use get_income_statement for raw income statement data.' This is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds context about the returned fields and accepted identifier types, but it does not disclose behaviors like error handling for invalid identifiers or response format details. With annotations covering the core safety aspects, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately states the tool's purpose, and provides a compact list of returned fields. Every word contributes to understanding, with no redundancy or filler.
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 a single parameter and no output schema, the description covers the essential aspects: what it returns and what identifier formats it accepts. It could mention error behavior, but given the low complexity and existing annotations, the description is sufficiently 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 schema already describes the identifier parameter fully, noting that it can be a ticker, CIK, CUSIP, or ISIN, with 100% schema description coverage. The description repeats this information without adding additional semantic meaning, so it does not elevate beyond the schema baseline.
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 uses the specific verb 'Get' and names the resource 'detailed company profile' with an explicit list of fields (description, CEO, employees, sector, industry, exchange, country). It clearly distinguishes itself from sibling tools like get_company_news or get_income_statement by focusing on company attributes, and it specifies accepted identifier types (ticker, CIK, CUSIP, ISIN).
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 that this tool is for obtaining a company profile, but it does not explicitly state when to prefer this tool over alternatives such as search_ticker_by_identifier or get_company_news. No exclusions or alternative tool references are provided, leaving the usage context indirectly inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing a safe read operation. The description adds the list of returned items but does not disclose pagination behavior, ordering defaults, or any other behavioral nuances beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence that immediately states the purpose and enumerates key outputs. No redundancy, no filler—every word contributes.
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 simple data-retrieval tool with no output schema, the description covers the key return fields. All parameters are fully specified in the schema. The description doesn't mention defaults like period/limit, but those are already in the schema, so the tool is sufficiently 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?
Schema description coverage is 100%, with all 8 parameters fully documented in the input schema. The description adds no parameter-specific semantics, relying entirely on the schema's existing explanations.
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 uses a specific verb ('Get') and clearly identifies the resource ('income statement data') while enumerating the exact data fields (revenue, gross profit, operating income, net income, EPS, EBITDA, margins). This distinguishes it from sibling tools like get_balance_sheet or get_cash_flow.
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 explains what data is returned but provides no explicit guidance on when to choose this tool over alternatives, lacks exclusions, and doesn't reference sibling tools. Usage must be inferred from the tool name and field list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the specific ratios returned, which is useful but not rich behavioral context. It does not discuss pagination, default ordering, or error behavior; however, the bar is lower given the annotations, so a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single sentence that front-loads the verb and resource, followed by a succinct list of the included ratios. Every word adds value; there is no redundancy or filler.
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 simple list-like nature of this tool and the rich schema covering all 8 parameters, the description is mostly complete. It lacks an explicit statement about the return format (e.g., time-series per period), but the named ratios and the tool's context among sibling financial data tools make the intended output clear enough.
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%, meaning every parameter (identifier, limit, order, period, date filters, fiscal year filters) already has a clear description. The tool description adds no parameter-level information beyond what the schema provides, so the baseline score of 3 applies.
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 uses a specific verb ('Get') and identifies the resource ('liquidity ratios'), then enumerates the exact ratios included (cash, current, quick, cash-flow-to-liabilities, Altman Z-Score). This clearly differentiates it from sibling tools like get_profitability_ratios or get_credit_ratios.
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?
No explicit guidance on when to use this tool versus alternatives is provided. The reader must infer from the ratio names that this is for liquidity analysis. There are no exclusions or alternative tool mentions, so it meets the 'implied usage' standard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds a listing of the specific ratios returned, which is useful scope information, but does not disclose additional behavioral traits such as historical time-series behavior or calculation nuances.
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 sentence that front-loads the core purpose and lists all key output enums. Every word earns its place with no redundancy or filler.
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?
The tool has 8 parameters and no output schema, yet the description plus schema cover the essential intent and filters. The description could explicitly mention that results are returned over multiple periods, but the period/limit/date parameters implicitly convey this. Overall, it is adequate for a financial ratios lookup 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% for all 8 parameters, so the schema already documents parameter meanings thoroughly. The description adds no extra parameter semantics beyond the schema, which is acceptable but not enriching.
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 uses a specific verb 'Get' with the resource 'profitability ratios' and enumerates exact ratio types (ROE, ROA, ROIC, margins, etc.). This clearly distinguishes it from sibling tools like get_credit_ratios and get_liquidity_ratios.
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 when profitability ratios are needed, but does not explicitly state when to use this over alternatives or provide exclusions. There is no mention of related tools for other ratio categories, leaving the agent to infer from naming and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds 'OHLCV' to indicate return format, but does not disclose pagination, rate limits, or error behavior. Since annotations lower the bar, the additional context about output format is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource, with no redundant words. It efficiently conveys the tool's 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 no output schema, the OHLCV mention helps signal return content. All parameters are fully described in the schema, and annotations provide safety context. The description is sufficient for a simple historical data retrieval tool, though it could specify return structure (e.g., a list of records).
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%, so baseline is 3. The description adds minor context by mentioning 'optional date range and ordering,' which reinforces the purpose of date_start, date_end, and order parameters, but does not significantly extend beyond schema 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 clearly states the tool gets historical stock price data (OHLCV) for a company, using the verb 'Get' and specifying the resource. 'Historical' distinguishes it from sibling get_latest_stock_price, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'historical' implies use for past price data, but the description does not explicitly state when to use this tool versus alternatives like get_latest_stock_price. No exclusions or alternatives are mentioned, so usage context is implied rather than explicit.
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. The description adds the behavior that it returns last/avg/high/low values, which is useful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that enumerates the exact metrics and aggregate types. No filler, every word conveys essential information. Ideal conciseness.
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 rich schema (all parameters described) and annotations (read-only, non-destructive), the description adequately completes the picture by listing the specific multiples and the output summary forms (last/avg/high/low). It does not explain response shape in detail, but for a simple retrieval tool this is sufficient.
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 8 parameters. The description adds no parameter-specific details; it focuses on output content (the multiples). This is baseline performance for fully-documented 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 the tool retrieves valuation multiples and lists the exact metrics (P/E, P/B, P/S, P/CF, P/FCF, EV/Sales, EV/EBITDA, EV/EBIT). This specific list distinguishes it from sibling tools like get_profitability_ratios or get_enterprise_value.
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?
No explicit guidance on when to use this tool versus alternatives. While the metric list implies its scope, it does not mention that other tools like get_enterprise_value cover EV components or that get_profitability_ratios covers margins. The description provides no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the types of data returned but does not disclose behavioral details such as pagination, filtering behavior, or date-range handling beyond what the schema parameters imply. This is acceptable given the strong annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that front-loads the tool's purpose and key output categories. Every word contributes meaning, and there is no redundancy.
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 has 8 parameters, no output schema, and good annotations, the description provides a minimal but adequate overview. It lacks explicit usage guidance and does not describe the structure of the returned balance sheet data in detail, but the schema and annotations compensate for much of the missing context. It does not fully clarify what 'key balance-sheet ratios' includes or that multiple periods are returned.
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?
All 8 parameters have descriptions in the schema, so the baseline is 3. The description does not add parameter-specific explanations; the listed data fields (assets, liabilities, etc.) refer to the response content rather than input parameters. The schema carries the full burden for parameter semantics.
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 uses a specific verb 'Get' and identifies the resource as 'balance sheet data' with enumerated contents (assets, liabilities, debt, equity, shares outstanding, ratios). This clearly distinguishes it from sibling tools like get_income_statement or get_cash_flow.
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 context that this tool is for balance sheet data, which implicitly signals when to use it. It does not explicitly state alternatives or exclusions, but the context is unambiguous enough for an agent to route balance-sheet-related requests here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read. The description adds the list of metrics but does not disclose any additional behavioral traits such as default period, time-series structure, or limitations. A 3 is appropriate given annotations cover safety.
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?
Single sentence, front-loaded with the action and resource. Zero wasted words. Very concise.
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?
The tool has 8 parameters and no output schema, so the description should clarify what the return value looks like. It lists metrics but doesn't state whether results are time series, what periods are covered by default, or how the yield metrics are calculated. The schema handles filtering parameters, but the output format remains ambiguous.
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 thoroughly documents all 8 parameters. The description does not add parameter-specific guidance, but the schema already compensates. Baseline 3 is justified.
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 uses the verb 'Get' with a specific resource ('yield metrics') and enumerates the exact metrics included. It clearly distinguishes this tool from sibling tools like profitability ratios or valuation multiples, which cover different metric categories.
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 implies usage by naming the metrics, but does not explicitly state when to prefer this over alternatives like get_enterprise_value or get_valuation_multiples. No exclusions are mentioned, but the context is clear enough for a knowledgeable user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context that the output includes ticker counts, giving a clearer picture of what the tool returns 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?
A single, front-loaded sentence with no wasted words, effectively communicating the tool's 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?
For a zero-parameter read-only listing tool, the description is sufficient: it states the resource and key output detail. It doesn't specify exact return format, but that's not essential given the simplicity and annotations.
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 has zero parameters, so the description inherently covers all needed info. It reinforces that the tool lists all industries with no filtering or arguments required.
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 uses a specific verb 'List' with resource 'industries' and adds output detail ('number of tickers in each'), distinguishing it from sibling tools like list_sectors and list_exchanges.
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?
No guidance on when to use this tool versus alternatives; the description simply states what it does without any reference to sibling tools or relevant scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context (that it returns exchange info) but does not disclose filtering behavior, pagination, or exact output format. With annotations present, the added value is modest, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence plus a short second sentence stating the return value. It is front-loaded with the action verb and contains no fluff.
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?
The tool is a simple search operation with four parameters and no output schema. The description explains the core purpose and return value at a high level, which is adequate for a tool of this complexity. It could be improved by naming the sibling search_ticker_by_identifier to clarify the difference, but this is a minor gap.
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?
All four parameters have descriptions in the schema (100% coverage), and the description adds no additional parameter-level meaning. The baseline is 3 since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for stock tickers by symbol or company name and returns matching companies with exchange info. This distinguishes it from list_tickers (which lists all tickers) and search_ticker_by_identifier (which likely searches by a specific identifier), though it does not explicitly name the sibling.
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 implies the tool is used when you need to find tickers by a user-supplied query. It gives clear context but does not explicitly mention exclusions or alternative tools. The sibling search_ticker_by_identifier exists, but no when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing that this is a safe read operation. The description does not add extra behavioral details such as potential errors, case sensitivity, or return format. While it doesn't contradict annotations, it provides no additional transparency beyond the structured data.
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, compact sentence with no extraneous information. It directly states the purpose and essential identifier types, making it highly efficient and well-structured.
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?
For a simple lookup tool with 2 required parameters and no output schema, the description is sufficiently complete. It covers what the tool does and the accepted identifier types, which is all that is needed for a straightforward lookup operation. The annotation provides safety context, so no further details are required.
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 fully describes both parameters (type enum and identifier text). The description adds value by specifying the format lengths ('9-char' for CUSIP, '12-char' for ISIN) and clarifying that CIK is an SEC identifier. This extra context aids validation and helps the agent select the correct format.
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 ('Look up') and the resource ('stock ticker') and specifies the exact identifier types (CIK, CUSIP, ISIN), making it distinct from sibling tools like search_tickers which likely search by name/ticker. This is a specific verb+resource+scope definition.
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?
Usage is implicitly clear: use this tool when you have a CIK, CUSIP, or ISIN to find a ticker. However, there is no explicit guidance on when not to use it or mention of alternative tools like search_tickers for name-based searches. The context is implied rather than stated, so it stands at a baseline level.
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 note readOnlyHint=true and destructiveHint=false, so safety is transparent. The description adds that results are articles, supports pagination, and allows optional date filtering, which provides useful behavioral context beyond the annotations, though 'recent' is left undefined.
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, efficiently written sentence that leads with the core action and object, and includes the key modifiers (pagination, date filtering) without waste. Every word earns its place.
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 read-only news retrieval tool with fully documented parameters and simple behavior, the description is adequate. It does not explain the return structure, but no output schema exists and the tool's behavior is straightforward. The vagueness of 'recent' is a minor gap.
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% and every parameter has its own description. The tool description merely echoes pagination and date filtering without adding any new parameter-level detail, so the 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 uses a specific verb (Get) and resource (recent news articles for a company), and distinguishes this tool from all sibling tools, which focus on financial metrics, tickers, and exchanges. The scope is clear 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 clearly implies the tool is for retrieving company news, and no sibling tool covers news, so the use case is evident. However, it does not explicitly state when not to use it or name alternatives, so it falls just short of full 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 destructiveHint=false. The description adds the useful context that not all calls may be available (via the hint to list first), which is 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?
Two sentences, front-loaded with the primary action and followed by a practical usage hint. No redundant words or filler.
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 simple read-only retrieval tool with strong annotations and clear purpose, the description is sufficient. The absence of an output schema is mitigated by the straightforward nature of the operation, and the list-first hint provides necessary context.
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% with clear definitions for year, quarter, and identifier. The description adds minimal extra meaning beyond reinforcing 'by year and quarter', so the 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 the tool retrieves a specific earnings call transcript, scoped by year and quarter. It distinguishes from siblings like get_latest_earnings_call by emphasizing 'specific' and the year/quarter qualifiers.
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?
Explicitly instructs to use list_earnings_calls first to find available calls, providing a clear prerequisite. It does not explicitly state when not to use the tool, but the guidance strongly implies the intended workflow.
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. The description adds meaningful context about the returned metrics (turnover, days, cash conversion cycle), which helps the agent know what to expect from the tool. 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 single front-loaded sentence that packs the complete purpose into one line with no fluff. Every word earns its place, listing the key metric categories efficiently.
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 read-only ratio tool with full schema coverage and annotations, the description is sufficient: it names the returned metrics and is consistent with the read-only annotation. A longer description might elaborate on response structure, but that is not essential given the tool's simplicity and the existing structured metadata.
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 8 parameters are fully described in the schema. The description does not need to add parameter-level detail, and it doesn't; it instead clarifies output content. The baseline of 3 is appropriate because the schema carries the burden.
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 uses the specific verb 'Get' with the resource 'working-capital ratios' and enumerates the exact metrics (receivable/inventory/payable turnover and days, cash conversion cycle). This cleanly differentiates it from sibling ratio tools like get_profitability_ratios or get_liquidity_ratios.
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 makes the domain clear by specifying working-capital efficiency and the exact metrics returned, allowing an agent to infer when to use it. However, it does not explicitly name alternatives or state when not to use it, which is a minor gap given the many sibling ratio tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds the returned field list but does not disclose behavior such as pagination, default limit, or ordering. The qualifier 'available' is vague, so it adds modest value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states purpose and output fields, the second gives an alternative. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with the schema and annotations, sufficiently covers what the tool does and its read-only nature. It lacks an explicit note about pagination or result limits, but the schema documents the default limit. For a simple read-only list tool, this is adequate, though a bit more context on return shape would elevate it further.
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?
All three parameters (limit, listed, exchange) have descriptions in the input schema, so schema coverage is 100%. The tool description does not add any additional parameter semantics or examples, so it meets the baseline but provides no extra value.
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 available stock tickers' and enumerates the returned fields (symbol, name, exchange, type, listed status). It also explicitly distinguishes this tool from search_tickers, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs users to 'Use search_tickers for a targeted lookup', providing a clear alternative. This implies the current tool is for broad listing, which is valuable guidance for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds behavioral context about what is included (year, quarter, date) and explicitly notes the absence of transcript text, which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, and the only extra sentence adds a meaningful exclusion. 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?
For a simple list tool with 2 parameters and an output schema absent, the description sufficiently defines the returned content (year, quarter, date) and clarifies the boundary with transcript retrieval. It is complete for the intended use.
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 does not add parameter-specific meaning beyond the schema's already clear definitions of identifier and limit, but it does not need to compensate.
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 'List available earnings calls for a company' with a specific verb and resource, and adds that results include year, quarter, and date. This distinguishes it from siblings like get_earnings_call_transcript by explicitly excluding transcript text.
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 context that it lists calls for a company and excludes transcript text, implying use for bibliographic info rather than transcripts. It does not explicitly name alternative tools, but the exclusion gives a clear when-not signal.
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, establishing a safe read operation. The description adds that the tool returns ALL exchanges and includes the number of tickers per exchange, which is useful behavioral/return info beyond the annotations, especially with no output schema present.
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, front-loaded sentence of 11 words. It states the verb, object, and key output detail without any filler or redundant information. Every word earns its place.
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?
For a zero-parameter list endpoint with strong read-only annotations, the description fully conveys what the tool does and what it returns (all exchanges with ticker counts). The absence of an output schema is compensated because the return shape (exchanges with numbers) is directly inferable from the description.
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 tool has zero parameters, so the description does not need to explain parameter semantics. Per the rubric, a baseline of 4 applies for 0-parameter tools, and the description correctly focuses on the output rather than input.
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 uses a specific verb ('List') and resource ('stock exchanges') with scope ('all') and output detail ('number of tickers on each'). This clearly distinguishes it from sibling list tools for tickers, sectors, industries, and countries.
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 does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or alternative tools. Usage is implied by the naming and description—if you need exchanges with ticker counts, this is the intended tool—but no explicit guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the baseline is 3. The description adds meaningful behavioral context beyond annotations by stating the output includes 'the number of tickers from each' and that it lists 'all' countries, which implies no filtering or pagination. This extra detail justifies a 4.
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, concise sentence that contains no filler words. It communicates the full purpose in an efficient manner.
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?
For a simple, zero-parameter list tool with read-only annotations and no output schema, the description adequately specifies the return concept (countries with ticker counts). It does not need to explain return format or additional behavior, making it complete.
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 tool has no parameters (0 params), which gives a baseline of 4 per the rubric. The schema covers all parameters vacuously, and there is nothing additional to explain in the description.
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 function: 'List all countries with the number of tickers from each.' It uses a specific verb (List), specifies the resource (countries), and adds the metric (number of tickers), which distinguishes it from sibling tools like list_exchanges or list_sectors.
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 context that this tool is for listing all countries, each with a ticker count. While it does not explicitly mention alternatives or exclusions, the specificity of the resource makes its usage evident, deserving a 4 rather than a lower score.
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, so the safety profile is set. The description adds behavioral detail by specifying that the output includes ticker counts, which is beyond what the annotations provide and helps the agent understand the return structure.
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, front-loaded sentence with no filler. Every word contributes to understanding the tool's purpose and output.
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?
For a zero-parameter, simple listing tool with clear annotations, this description is complete. It tells the agent exactly what will be listed and what accompanies each sector. There are no missing prerequisites or return value ambiguities given the simplicity.
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 tool has no parameters, so the schema coverage is trivially complete. With zero parameters, the description doesn't need to explain any parameter semantics; the baseline of 4 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 all market sectors') and the specific resource ('sectors'), and adds the output detail ('with the number of tickers in each'). This unambiguously distinguishes it from sibling tools like list_exchanges and list_industries.
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 context for when to use the tool (when you need market sectors and their ticker counts) without explicitly excluding alternatives. It doesn't name other tools, but the specificity of the resource makes the usage context obvious.
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:

[![agents-plugin MCP server](https://glama.ai/mcp/servers/roicai/agents-plugin/badges/card.svg)](https://glama.ai/mcp/servers/roicai/agents-plugin)

Score Badge

Copy to your README.md:

[![agents-plugin MCP server](https://glama.ai/mcp/servers/roicai/agents-plugin/badges/score.svg)](https://glama.ai/mcp/servers/roicai/agents-plugin)

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/roicai/agents-plugin'

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