FinMCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
The 28 tools cover distinct data-retrieval, analysis, screening, and synthesis functions. A few analysis tools (e.g., analyze_cash_flow_quality vs detect_earnings_quality, calculate_financial_ratios vs calculate_growth_metrics) share underlying data and themes, but their detailed descriptions clearly delineate purpose. Overall, misselection risk is low.
Naming Consistency3/5
Most tools use snake_case and a clear verb (get_, calculate_, analyze_, detect_, find_), giving a generally readable set. However, several tools are noun-phrase named (bankruptcy_risk_score, peer_valuation, historical_valuation, financial_health_score, dcf_valuation), and 'ping' is a bare verb, breaking the otherwise consistent verb_noun pattern.
Tool Count2/5
At 28 tools, the set is well beyond the typical 15-tool upper bound and feels heavy for an agent to navigate. While each tool is individually purposeful, many are compositional (analyze_company, generate_investment_memo) or overlapping in theme, so the count could be tightened.
Completeness5/5
The server covers an exceptionally complete fundamental-analysis workflow for Indian equities: statements, ratios, growth, margin/cash-flow quality, red flags, valuation, DCF, peer comparison, screening, and synthesis. It explicitly scopes out data it can't reliably source (promoter holdings, related-party transactions), avoiding gaps that would mislead.
Average 4.5/5 across 28 of 28 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it does disclose meaningful behavioral traits: it operates on 'available annual history', computes specific ratios, and explicitly says it 'flags, it doesn't score or accuse' to set expectations. It does not state what happens with insufficient data, but the scope and interpretive stance are reasonably transparent.
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 core method, scope, caveat, and parameter format are packed into two tight sentences with no filler. The action verb and resource are front-loaded. Every part of the description 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 one-parameter analytical tool with an output schema, the description supplies the methodology, scope, and input format needed to call it correctly. The main missing piece is routing guidance relative to the many sibling analysis tools, plus explicit behavior on insufficient history. It is otherwise complete enough.
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?
The schema only declares a required string 'symbol' with 0% description coverage. The description compensates by defining the parameter as a ticker and providing concrete formats for NSE and BSE: 'RELIANCE', 'TCS.NS', or 'TCS.BO'. This is exactly the format guidance an agent needs to invoke the tool correctly.
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 a clear verb and resource: 'Assess cash-flow quality for an NSE/BSE-listed Indian equity across its available annual history.' It also lists specific metrics (cash conversion, receivables/inventory growth vs. revenue), making the tool's scope concrete. It does not explicitly contrast itself with sibling tools like detect_earnings_quality, so it falls short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to prefer this tool over related siblings such as detect_earnings_quality, detect_accounting_red_flags, or calculate_financial_ratios. No exclusion criteria or alternative-selection hints are provided. The 'flags, it doesn't score or accuse' remark is interpretive guidance, not usage-selection 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 no annotations, the description carries the full burden and discloses several behavioral traits: it reports margins as percentages, uses available annual history, orders oldest to newest, provides a delta, and deliberately refrains from labeling trends. This is strong behavioral context, though it could mention how missing years are handled.
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 compact and front-loaded, with no filler. Every sentence adds value, including the explicit note about not labeling trends, which prevents misinterpretation.
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 single required parameter and presence of an output schema, the description covers the essential semantics: scope, metric types, ordering, delta calculation, and the interpretation boundary. Nothing critical is missing for an agent to invoke it correctly.
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 provides zero description for the symbol parameter, but the description compensates with concrete examples ('RELIANCE', 'TCS.NS', 'TCS.BO') and the term 'ticker symbol,' which clarifies the expected format and exchange suffix conventions. This is sufficient for a single parameter.
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 tracking gross, operating, and net margins across an Indian equity's annual history, with a specific output of oldest-to-newest ordering and first-vs-latest delta. It is specific enough to distinguish itself from financial ratio and growth metric siblings.
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 is given for when to use this tool versus alternatives like calculate_financial_ratios or calculate_growth_metrics. The description explains what the tool does but not the conditions that should lead an agent to select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It specifies the output format (0-100 score plus flag list), explains what the score means (share of clean checks), and adds an important interpretive caveat that findings are observations, not proof of a problem. It does not explicitly state read-only behavior, but the analytical nature and output description make that reasonably clear.
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 efficiently front-loaded with the core action, followed by a scannable list of detection criteria, output summary, and caveat. Each sentence adds useful content; the param line is clearly separated. It is slightly longer than necessary but every portion serves a 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 one-parameter analysis tool with an output schema, the description is largely complete: it explains inputs, detection logic, output semantics, and the interpretive stance of the results. The main gap is lack of differentiation from sibling analysis tools, and it does not mention any data-freshness or coverage limitations, but these do not prevent 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?
The schema provides only a required string field named 'symbol' with no description, so the description must compensate. It does this well by defining the parameter as a ticker symbol and providing concrete examples: RELIANCE, TCS.NS, TCS.BO. This gives the agent enough format context to construct a valid call, though it does not exhaustively specify all exchange-suffix rules.
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?
Starts with a specific verb and resource: "Flag earnings-quality concerns for an NSE/BSE-listed Indian equity." The description then enumerates the exact checks performed (operating cash flow versus profit, receivables/inventory growth, other income, cash-flow backing), clearly distinguishing it from broad ratio or health-score siblings. This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies appropriate use by defining the tool's scope and output, but it does not explicitly state when to prefer this tool over closely related siblings like detect_accounting_red_flags or analyze_cash_flow_quality. There is no exclusion guidance, so an agent must infer the differentiation from purpose alone.
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 no annotations provided, the description carries full behavioral burden. It discloses important non-obvious behavior: null buyback/acquisition values mean 'not reported' rather than zero, and net debt repayment is defined as repayment minus new issuance. It also provides live-verified examples showing why data can differ by ticker, which is valuable for correctly interpreting results.
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 compact and well-ordered: what the tool does, the key output components, the critical null-semantics caveat, then the parameter. Every sentence adds value and there is no fluff or repetition of schema field names.
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 an output schema, so the description doesn't need to explain return values in detail. It covers scope, data source behavior, null semantics, and parameter format. The only small gap is clarifying what 'each available fiscal year' means in practice, but this does not prevent 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?
The schema has 0% description coverage, so the description must compensate. It does so with a dedicated :param symbol line and concrete examples ('RELIANCE', 'TCS.NS', 'TCS.BO') that clarify accepted ticker formats for NSE/BSE-listed equities. For a single-parameter tool this is sufficient, though a bit more detail about case sensitivity or exchange suffix rules would push it higher.
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 a specific action ('Show how...deployed free cash flow') on a defined resource ('NSE/BSE-listed Indian equity') and lists the exact components analyzed. This meaningfully distinguishes it from sibling tools like get_cash_flow_statement, which simply returns raw statements, or get_dividend_history, which focuses only on dividends.
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 usage context is implied: use this tool to see how a company deployed free cash flow, especially for Indian listed equities. However, it does not explicitly state when to prefer this over alternatives like analyze_cash_flow_quality or get_cash_flow_statement, nor does it mention exclusions or complementary tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It usefully discloses Yahoo as the data source, approximate coverage (~5 years annual / ~5-6 quarters), and ordering (newest period first), which an agent cannot infer from the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences plus a structured param block. Purpose and behavioral context are front-loaded, every sentence adds information, and there is no irrelevant detail.
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 two-parameter tool with an output schema, the description covers purpose, equity scope, data source, temporal depth, ordering, and parameter formats. Minor omissions like currency/units are not critical because the output schema provides structural 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 description coverage is 0%, and the description compensates by documenting both parameters: symbol with explicitly format examples (RELIANCE, TCS.NS, TCS.BO) and period with its allowed values. The period entry largely repeats the enum, so the added value is strong for symbol but modest for period.
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?
States a specific verb ('Get') and resource ('balance sheet for an NSE/BSE-listed Indian equity'), and lists the line items (assets, liabilities, equity, debt, working-capital) that clearly distinguish it from sibling statements like get_income_statement and get_cash_flow_statement.
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 implied by the resource and line items, but there is no explicit statement of when to use this tool vs get_income_statement or get_cash_flow_statement, nor any exclusions. The data-source and period context help, but alternatives are not directly addressed.
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?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that Yahoo is the data source, that approximately 5 years of annual data or 5-6 quarters are available, and that periods are returned newest-first. These details go beyond the schema and help the agent set expectations.
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 compact and well-structured: the lead sentence states the tool's purpose and content, the second sentence adds data source and availability constraints, and the parameter lines are minimal and useful. No filler or redundant wording.
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, has an output schema, and the description provides source, period depth, ordering, and parameter examples. It is sufficient for an agent to select and invoke the tool correctly. A minor gap is that it does not explain behavior for tickers with multiple listings, though the exchange-suffix examples partially cover this.
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 0%, but the description documents both parameters. The symbol parameter gains meaningful examples like 'RELIANCE', 'TCS.NS', and 'TCS.BO', which the schema lacks. The period parameter repeats the enum but also adds context by linking annual to ~5 years and quarterly to ~5-6 quarters.
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 a specific verb and resource: 'Get the cash flow statement' for an NSE/BSE-listed Indian equity, and enumerates the exact components returned (operating cash flow, capex, free cash flow, financing cash flow, dividends paid). This clearly distinguishes it from sibling tools like get_income_statement and get_balance_sheet.
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 intended use is implied: choose this tool when raw cash flow statement data is needed. However, the description does not explicitly mention alternatives or state when not to use it, such as when the agent needs analytical assessments like analyze_cash_flow_quality instead.
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 no annotations provided, the description carries the full behavioral burden. It discloses important non-obvious behavior: unresolved candidates are appended at the end rather than silently dropped, extras beyond 15 are dropped, and failed candidates do not count against max_results. This is more transparent than most descriptions, though it does not mention side effects, permissions, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with purpose in the first sentence and behavior explained in the second. The param lines are useful and not redundant with the schema. Minor repetition of 'max 15' between prose and param docs keeps it from being a perfect 5.
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 two parameters and an output schema, the description covers the essential call context: candidate source, limits, tiebreakers, and failure handling. The main gap is exactly how ticker symbols should be formatted for NSE/BSE equities, which is important for a Yfinance-based 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 0%, so the description must compensate, and it does. It explains that symbols are candidate ticker symbols (max 15, extras dropped) and that max_results counts only ranked candidates, not failed ones. It could add ticker format guidance (e.g., .NS suffix), but the provided semantics are useful and actionable.
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 names a specific verb ('screen'), a specific resource ('NSE/BSE-listed Indian equities'), and a concrete ranking method ('by financial_health_score, using earnings-quality score and red-flag count as tiebreakers'). This clearly distinguishes it from sibling tools like find_undervalued_companies or calculate_financial_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 explicitly tells the agent that candidates must be supplied because Yahoo has no NIFTY-500-style endpoint, and sets the max-15 constraint. It gives clear context for when to use the tool, though it does not explicitly name alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden and does well: it reveals that bare symbols are normalized to .NS, that an explicit .NS/.BO suffix selects the exchange, and that non-Indian symbols are rejected rather than silently returned. This covers the non-obvious behaviors an agent needs to predict outcomes.
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 about 70 words with a front-loaded purpose sentence, and every subsequent sentence adds unique value: normalization, market scope, rejection behavior, and parameter examples. No filler or repetition.
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 one-parameter tool with an output schema, the description covers the critical input format and market restrictions, so an agent can invoke it correctly. It stops just short of spelling out error behavior for unknown Indian symbols, but that is a minor omission given the output schema already documents the return shape.
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?
The schema only declares a required string 'symbol' with no description (0% coverage), so the description must compensate. It does so by giving concrete examples ('RELIANCE', 'TCS.NS', 'TCS.BO') and explaining the default NSE normalization, which is precisely the semantic information an agent needs.
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 opens with a specific verb and resource ('Get the company profile/overview') and limits scope to NSE/BSE-listed Indian equities, which clearly separates it from sibling tools dealing with financial statements, ratios, or news. The exchange-suffix behavior further clarifies exactly what kind of lookup this performs.
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 about Indian-market-only coverage and symbol normalization, but it never explicitly compares against any sibling tool or states a condition for choosing this over alternatives. The 'when to use' is only implied by the first sentence, not spelled out.
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 no annotations at all, the description carries the behavioral disclosure burden. It adds useful behavioral context by specifying the data source (Yahoo), the approximate lookback window (~5 years annual / ~5-6 quarters), and the ordering (newest period first). This goes well beyond a bare operation description, though it doesn't mention error behavior or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct, front-loaded with the main purpose, and immediately followed by compact parameter documentation. Every sentence adds value, and the size is appropriate for a two-parameter tool.
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 covers the tool's purpose, parameter semantics, data coverage, and ordering. An output schema is present, so return values do not need to be described. The only notable gap is the lack of explicit guidance on when to choose this tool versus its financial-statement siblings, but overall the context is sufficient.
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?
Schema description coverage is 0%, so the description must fully document parameters. It explains the symbol parameter with concrete ticker examples (RELIANCE, TCS.NS, TCS.BO) and clarifies that period accepts 'annual' or 'quarterly', matching the schema enum. This fully compensates for the missing 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 action (get), the resource (income statement), the market coverage (NSE/BSE-listed Indian equity), and the included metrics (revenue, gross profit, EBIT, EBITDA, net income, EPS). This makes it easy to distinguish from sibling tools like get_balance_sheet or get_cash_flow_statement.
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 income statement data through the tool name and content, but it does not explicitly state when to use it over alternatives such as get_balance_sheet or get_cash_flow_statement. There is no when-to-use or 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?
With no annotations, the description carries the full transparency burden. It does well by disclosing that ratios are 'computed by hand from the income statement and balance sheet instead of read off .info' and enumerates the six ratios. It does not cover side effects or error cases, but for a pure calculation tool the methodology disclosure adds real value.
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 compact and front-loaded: one sentence states purpose and scope, one sentence explains method, and one line documents the parameter. Every sentence adds new, non-redundant information with no 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 one-parameter tool with an output schema, the description provides enough context: what is calculated, for which securities, over which period, and via what method. A minor gap is lack of explicit behavior for unsupported tickers, but the examples and scoping largely mitigate this.
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 0%, so the description must compensate. It documents the single parameter with concrete examples ('RELIANCE', 'TCS.NS', 'TCS.BO'), clarifying accepted listing formats beyond the bare string type. It does not cover edge cases like case sensitivity, but the examples make the parameter clear.
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 strong verb-resource pair: 'Calculate valuation, profitability, liquidity, and efficiency ratios for the latest fiscal period of an NSE/BSE-listed Indian equity.' It also names the specific ratios computed, distinguishing it from generic financial data retrieval siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use it: for NSE/BSE-listed Indian equities, latest fiscal period, and ratios Yahoo leaves null. It doesn't explicitly mention alternative tools or exclusion criteria, but the scoping information is sufficient for an agent to route to this tool over data-retrieval or other calculation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and handles it well. It discloses a deliberate exclusion (promoter shareholding), explains the data-source reason, and interprets share-count trends. It does not detail output behavior, but an output schema exists, and no contradictions are 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 front-loaded with the core purpose and indicators, and every sentence earns its place. The data-source caveat is essential for correct tool selection, and the parameter documentation is compact. There is no filler or redundant restating of the tool name.
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 single-parameter tool with an output schema, the description is complete: it defines scope, lists included indicators, names the related sibling, explains a key exclusion, and provides example symbols. An agent has enough information to select and invoke the tool appropriately without ambiguity.
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 input schema only provides the parameter name and type, with 0% schema description coverage. The description compensates by documenting the symbol parameter with concrete formats ('RELIANCE', 'TCS.NS', 'TCS.BO') and tying it to the Indian-market context. This adds meaning beyond the raw 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 uses a specific verb ('Assess') and clearly defines the resource scope: capital-allocation and ownership-trend signals for NSE/BSE-listed Indian equities. It enumerates concrete indicators (ROCE trend, share-count trend, dividend consistency, capital-allocation split) and distinguishes itself from analyze_capital_allocation by pointing to it for the split.
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 strong contextual guidance: it is for Indian equities, references analyze_capital_allocation for the capital-allocation split, and explicitly excludes promoter shareholding due to a Yahoo data limitation. It stops short of an explicit 'use this tool when... versus...' statement, but the context and sibling reference make the intended usage 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?
With no annotations, the description carries the behavioral disclosure burden. It adds meaningful context: data-source limitations (no Yahoo Finance related-party data), methodological boundaries (no reliable depreciation basis), and interpretative guidance ('Flags are observations to investigate, not accusations'). It doesn't explicitly state read-only behavior, but that is inherent for a scan/analysis tool.
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 front-loaded with the core action, followed by a scannable red-flag list, then exclusions and an interpretation note. Every sentence serves a purpose, and even the 'scoped out rather than faked' aside adds valuable context without bloat.
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 single-parameter analysis tool with an existing output schema, this description is complete: it defines the scope, names concrete red flags, states limitations, explains output semantics, and gives input format examples. An agent has enough information to select and invoke the tool correctly.
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 0%, but the description documents the single symbol parameter with concrete examples ('RELIANCE', 'TCS.NS', 'TCS.BO') and clarifies the target market (NSE/BSE-listed Indian equity). This adds meaning beyond the bare schema definition and is sufficient for one simple parameter.
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?
States a specific verb 'Scan' and a precise resource: an NSE/BSE-listed Indian equity's most recent fiscal year. Enumerates concrete red-flag patterns (margin swing, debt spike, goodwill/intangible growth, exceptional items) and explicitly lists what is out of scope, making it clearly distinguishable from sibling analysis 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 clearly delimits what the tool covers and does not cover, explaining why related-party transactions and depreciation-pattern analysis are excluded. It does not name an alternative sibling or explicitly state 'use this when...', but an agent can infer the appropriate context from the scoping and exclusions.
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 no annotations provided, the description carries the full burden of behavioral disclosure. It does this well by explicitly stating that an empty dividends list is a legitimate result, not an error, and that ticker validity is checked separately via .info. This prevents a common false-positive failure interpretation. It could go further by describing the shape of the returned history, but the key behavioral traps are addressed.
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 compact, front-loaded with the primary purpose, and then adds the two most important behavioral nuances in separate sentences. The parameter docstring is clean and does not repeat schema information verbosely. Every sentence 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 simple read-only lookup with one parameter, the description covers purpose, parameter format, and error/empty-result semantics. There is no output schema, so a bit more detail about the returned structure or how stock splits are represented would improve completeness, but the current description gives an agent enough to select and invoke the tool correctly.
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?
The schema only defines symbol as a required string with no description, so the description fully compensates. It explains the symbol parameter, provides realistic examples (RELIANCE, TCS.NS, TCS.BO), and clarifies exchange-suffix conventions. For a single-parameter tool, this is complete and actionable.
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 and resource: getting dividend and stock-split history for an NSE/BSE-listed Indian equity. This clearly distinguishes the tool from financial-analysis siblings like get_stock_price_history or get_company_profile, and there is no ambiguity about what it returns.
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 tool's context clear: use it when you need dividend or stock-split data for an Indian equity. It does not explicitly name alternative tools or state when not to use it, but its purpose is specific enough that an agent can infer the appropriate usage scenario.
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?
No annotations are provided, so the description carries the behavioral burden. 'Health-check' and 'confirms' imply a read-only, non-destructive operation with no side effects, which is the key behavioral trait an agent needs. The presence of an output schema covers return-value expectations.
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. It immediately states the tool's purpose and avoids repeating any schema or annotation information.
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 health-check tool with an output schema, this description is fully sufficient. There are no inputs, side effects, or complex behaviors to explain, and the sibling context confirms its unique role.
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 parameter-semantics guidance is not needed. The description adds no parameter information, but the baseline of 4 applies because there is nothing to document.
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 this as a health-check tool with a specific verb ('confirms') and resource ('the MCP server is wired up correctly'). It is immediately distinguishable from the sibling financial-analysis tools, all of which perform data retrieval or computation rather than connectivity checks.
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 context: use when you need to verify that the server is reachable and properly connected. While it does not explicitly name alternatives or exclusions, the unique zero-parameter health-check purpose makes the appropriate usage obvious among the listed siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers meaningful behavioral context: it is a composite pipeline, it reuses other tools' results, and it benefits from shared/cached Yahoo fetches. It does not explicitly declare read-only behavior or failure modes, but for an analysis-only tool this is reasonably transparent given the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: the first sentence establishes scope and content, the second explains the composite/cached implementation advantage, and the third documents the parameter. The key purpose is front-loaded with no filler.
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?
An output schema exists, so the description does not need to enumerate return fields. It fully explains what the tool does, lists the major analysis components, identifies its relation to sibling tools, and documents the sole parameter with examples. For a complex pipeline tool, nothing essential is missing.
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?
The schema only says 'Symbol' with no description coverage, so the description fully compensates by documenting the lone parameter: ':param symbol: ticker symbol, e.g. "RELIANCE", "TCS.NS", or "TCS.BO".' Concrete examples and exchange suffix conventions remove all ambiguity.
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?
Starts with a specific verb and resource: 'Run the complete fundamental-analysis pipeline for one NSE/BSE-listed Indian equity in a single call.' It enumerates the covered analyses (profile, ratios, growth, margin trends, etc.) and explicitly notes that it 'Composes every other tool in this server,' distinguishing it clearly from the individual sibling 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 makes the primary use case clear: get a complete fundamental analysis in one call rather than invoking many separate tools. It also explains that this approach is cheaper because Yahoo fetches are shared/cached. However, it does not explicitly state when NOT to use it, such as when only a single metric or statement is needed.
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 no annotations provided, the description carries the full behavioral disclosure burden. It reveals the unsupported intraday intervals, the 500-bar cap, the dropping of oldest bars, and the `truncated` flag. This goes well beyond the bare schema and gives useful operational expectations.
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 compact and well-structured: a concise lead paragraph followed by a parameter list. Every sentence adds useful information, and the main capability 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?
For a data-retrieval tool with no annotations and minimal schema descriptions, the description covers inputs, constraints, and even a return signal (`truncated`). The output schema can handle the remaining return-value details, so nothing critical is missing for correct invocation.
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?
Schema description coverage is 0%, but the description fully documents all three parameters: symbol with concrete examples, period with allowed values, and interval with allowed values. This completely compensates for the schema's lack of 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?
States a specific verb ('Get'), resource ('OHLCV price history'), and universe ('NSE/BSE-listed Indian equity'). It is clearly distinct from siblings like get_dividend_history or get_company_profile, and the data type 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?
Provides explicit context on when this tool is appropriate: historical OHLCV for Indian equities, with intraday intervals explicitly excluded. It also explains the 500-bar cap behavior. However, it does not name a specific alternative tool for intraday data or other price-related needs.
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?
No annotations are present, but the description compensates with substantive behavioral details: data source (Yahoo, ~5 years), the years_used reporting field, exclusion of negative/missing EPS years, and the relative-to-history framing. This gives the agent a clear picture of what to expect beyond the call itself.
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?
Each sentence adds necessary information: the core operation, data limitations, exclusion rules, and parameter examples. No filler or redundant phrasing, with the main purpose stated first.
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 single-parameter read tool with an output schema, the description covers all necessary invocation details: what it does, how symbols are formatted, what data range to expect, and edge cases. It is complete and self-contained.
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?
The schema has 0% description coverage for the symbol parameter, but the description's ':param symbol:' section provides examples (RELIANCE, TCS.NS, TCS.BO) and implicitly explains exchange suffixes. This fully compensates for the missing schema-level documentation.
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 ('Compare') and names a precise resource (an Indian equity's current P/E vs its own historical annual P/E). It explicitly distinguishes itself from peer comparisons, making it clearly differentiated from sibling tools like peer_valuation.
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 states what the tool does and explicitly excludes use cases (absolute cheap/expensive judgments, peer comparison). This gives strong contextual guidance, though it does not explicitly name alternative tools to use for those cases.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the methodological variant, why it avoids the currency-mismatch issue, the classification zones, and what the model deliberately excludes. This is strong transparency about what the tool does and does not compute.
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 and uses its length efficiently. The methodological and exclusionary details are relevant and helpful, though the description is slightly dense with parenthetical asides that could be trimmed without losing essential meaning.
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 output schema exists and there is only one required parameter, the description covers everything needed: the assessment type, target market, scoring model, interpretation zones, a key exclusion, and parameter format. No critical operational gaps remain.
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?
The schema only says 'symbol' is a string, providing 0% coverage. The description compensates by defining it as a ticker symbol and giving concrete formats: 'RELIANCE', 'TCS.NS', or 'TCS.BO'. This materially helps the agent call the tool correctly.
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 and resource: 'Assess bankruptcy/distress risk for an NSE/BSE-listed Indian equity.' It also names the exact model (Altman's Z''-score emerging-market variant) and differentiates itself from related tools by explicitly noting it does not include Ohlson's O-score.
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 context for use: bankruptcy/distress assessment for Indian equities, with detailed zone cutoffs. It also states an explicit exclusion ('Does NOT include Ohlson's O-score'), but it does not name a sibling alternative to choose instead, so it stops short of full 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so thoroughly. It explains the 0-100 attractiveness score is min-max normalized within the supplied peer set only, lists the exact factors and weightings, warns the score is not absolute, and states that unresolved peers get an error field instead of failing the call.
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 dense but every sentence earns its place: purpose, usage constraint, scoring methodology, error behavior, and parameter details are all included. It is well-structured and front-loaded with the core purpose before diving into scoring details.
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?
The tool has only two simple parameters and an output schema, so the description does not need to explain return values. It covers the essential behavioral context: peer-set-relative scoring, input limits, and error handling, making it complete enough for an agent to select and invoke it correctly.
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 0%, so the description must compensate. It adds meaning to both parameters by labeling symbol as the anchor ticker and peer_symbols as peer tickers with a max of 5 and drop behavior. It could have added more detail about ticker formats but is otherwise sufficient.
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 compares valuation and quality multiples for Indian equities against explicit peer tickers, with a concrete resource and action. It also distinguishes itself from peer-discovery tools by noting Yahoo has no peer-discovery endpoint for Indian equities.
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 context that peers must be supplied and caps peer_symbols at 5, with extras dropped. It does not explicitly compare against sibling tools like compare_companies or historical_valuation, but the Indian-equity peer-comparison use case is clearly implied.
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?
With no annotations, the description carries the full burden and handles it well. It discloses the Yahoo ~5-year history limitation, clarifies that the result is at most a 4-year CAGR, and mentions `years_used` to prevent overclaiming the time span.
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 compact and front-loaded with the purpose, followed by the critical data-history caveat and parameter note. Each sentence adds necessary information without filler.
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?
An output schema exists, so return-value details are unnecessary here. The description covers what is calculated, the data horizon, the symbol format, and the `years_used` behavior, making it complete for a single-parameter tool.
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?
The schema provides zero description for the single `symbol` parameter. The description compensates by defining it as a ticker symbol and giving concrete examples such as 'RELIANCE', 'TCS.NS', and 'TCS.BO', which is sufficient for correct invocation.
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 a specific verb ('Calculate') and a precise resource: CAGR for revenue, net income, EPS, and free cash flow. It identifies the target market (NSE/BSE-listed Indian equities) and distinguishes itself from sibling tools like calculate_financial_ratios by focusing on growth metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended context is clear: use this when the agent needs CAGR growth metrics over an Indian equity's available annual history. It does not explicitly name alternative tools or state when not to use it, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and does so thoroughly. It reveals the exact equal-weighting scheme (five pillars, 20% each), the specific metrics in each pillar, the inversion behavior for valuation, and the heuristic non-predictive nature of the score. This is far beyond what a typical description discloses.
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 information-dense but not bloated. Every sentence contributes: the main purpose and output, the five-pillar breakdown, the compositional nature and warning, and the parameter documentation. The structure front-loads the core action and then provides necessary details.
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 one-parameter tool with a documented output schema, the description covers everything needed to select and invoke it correctly: symbol format, scoring methodology, pillar definitions, and a behavioral caveat. There are no significant gaps.
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?
Schema coverage is 0%, but the description fully compensates with a `:param symbol:` line that explains it is a 'ticker symbol' and gives concrete examples ('RELIANCE', 'TCS.NS', 'TCS.BO') illustrating exchange suffix conventions. For a single-parameter tool, this is complete and unambiguous.
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 a specific verb ('Score'), a specific resource ('NSE/BSE-listed Indian equity'), and a clear output range ('0-100'). It also distinguishes itself from sibling tools by naming the four underlying calculators it composes and explicitly saying it is 'not a market-validated predictive model.'
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 context: it is a composite heuristic built from calculate_financial_ratios, calculate_growth_metrics, analyze_cash_flow_quality, and historical_valuation, which implies those siblings are more appropriate for granular metrics. It also provides an exclusion by stating it is 'not a market-validated predictive model,' signaling not to use it for predictive investment decisions. It stops short of explicitly saying 'use this tool when X, use Y instead,' but the guidance is strong.
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?
With no annotations, the description carries the full burden and does so thoroughly. It discloses ranking normalization (min-max across candidate list only, not absolute), the inability to discover a universe, handling of unresolved candidates (appended, not dropped), and the semantics of max_results (failed candidates don't count). This goes well beyond the schema and gives the agent accurate expectations.
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 efficiently structured: the core purpose is front-loaded, followed by a critical limitation, then key behavioral details and parameter documentation. Every sentence adds essential information without redundancy or filler, making it easy for an agent to parse and internalize.
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 moderate complexity, two undocumented parameters, and no annotations, the description is remarkably complete. It covers input constraints, ranking methodology, score interpretation, and edge-case handling. Since an output schema exists, the description does not need to explain return fields, and the provided behavioral context is sufficient for correct invocation.
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?
Schema description coverage is 0%, so the description must fully document parameters. It does: symbols are defined as candidate ticker symbols with a max-15 constraint and 'extras are dropped', and max_results is explained with the crucial detail that unresolved candidates don't count against the limit. This adds significant meaning beyond the bare type and default 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 states a specific verb ('Screen'), a specific resource ('explicit list of NSE/BSE-listed Indian equities'), and the exact purpose ('undervaluation signals'). It further distinguishes itself by noting it cannot discover a universe and requires supplied candidates, which separates it from potential sibling screeners like find_high_quality_companies.
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 specifies the precondition: the user must supply candidate symbols because the tool cannot discover a universe on its own. It also notes the max 15 candidates and the fallback behavior for unresolved items, providing solid context for when to use this tool, though it does not explicitly name or exclude alternative sibling tools.
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?
With no annotations, the description carries full responsibility for behavioral disclosure. It explicitly states the bull/bear case is 'mechanically derived' from existing flags and labels rather than fabricated external research, and that Catalysts are 'omitted rather than invented.' This gives clear insight into the tool's data provenance and boundaries.
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 compact and front-loaded with the primary purpose, followed by two brief behavioral caveats and a param line. Every sentence adds value, with no redundancy or filler.
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?
The description explains what the tool produces (memo sections), how it derives the bull/bear case, what it intentionally excludes and why, and the required input. With an output schema also present, an agent has everything needed to select and invoke the tool correctly.
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?
Schema coverage is 0%, so the description's ':param symbol: ticker symbol, e.g. RELIANCE, TCS.NS, or TCS.BO' is the only guidance for the single parameter. It provides concrete format examples, fully compensating for the empty schema 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 opens with a specific action — 'Compose analyze_company's output into a structured research-memo shape' — and enumerates the sections included in the memo. This clearly differentiates it from the sibling data-retrieval and analysis tools and names its direct input source.
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 should be used after analyze_company has been run, since it composes that tool's output. It also states a clear limitation (no Catalysts section because analyst/news data is unavailable), which helps set expectations. However, it doesn't explicitly name alternatives or provide an if/when-not rule, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description fully carries the burden of behavioral disclosure and does so very well. It explicitly warns that Yahoo's news stream is loosely tagged and may contain broader industry/competitor/unrelated items, explains the mechanical `mentions_company` flag, and addresses both empty-success and invalid-symbol failure modes.
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 front-loaded with the core purpose and every subsequent sentence earns its place: noise caveat, relevance flag caveat, empty-result semantics, validation note, and parameter docs. All are essential to correct invocation in an agentic context.
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?
With an output schema present and only two simple parameters, the description covers all contextual gaps: result-relevance expectations, failure behavior, and parameter syntax. No critical information needed to call or interpret the tool is missing.
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?
Despite 0% schema coverage, the description fully documents both params in the `:param` block: symbol gets ticker examples (RELIANCE, TCS.NS, TCS.BO) and limit's meaning/default are stated. This adds substantial value beyond the bare input schema and gives an agent everything needed to fill the args correctly.
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 ('Get recent news headlines/summaries') and explicitly scopes the resource to NSE/BSE-listed Indian equities. This clearly distinguishes it from all sibling tools, which are financial analysis and data lookup operations rather than news retrieval.
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 the tool is appropriate: any time recent news coverage for an Indian listed equity is needed. It also clarifies edge-case behavior (empty result is legitimate, invalid symbols raise), though it does not name alternatives because none of the siblings offer news.
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?
With no annotations provided, the description fully carries the behavioral burden. It reveals the methodology (two-stage DCF with 5Y explicit growth and Gordon-growth terminal value, solved by bisection), declares that wacc and terminal_growth are overridable assumptions rather than derived values, and explicitly states the tool is not a forecast.
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 front-loaded with the core conceptual shift, then state the method, assumptions, and interpretation. Each sentence adds necessary information without filler, and the parameter breakdown is compact and useful.
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 output schema exists, the description does not need to explain return values. It covers the purpose, method, assumptions, constraints, interpretation, and caveats, providing enough for an agent to decide when to call it and what inputs to provide.
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?
Although schema description coverage is 0%, the description effectively documents all three parameters: symbol with concrete examples, wacc with default conversion, and terminal_growth with the constraint that it must be less than wacc. This compensates fully for the missing 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 explicitly states the tool's goal: solve a two-stage DCF by bisection to find the constant growth rate that makes enterprise value match current market cap plus net debt. It clearly distinguishes itself from fair-value DCF by framing it as an implied-expectations check rather than a forecast.
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 communicates when to use the tool: when you want to know what growth the current price already assumes, instead of asking what the fair value is. It stops short of explicitly naming sibling alternatives like dcf_valuation or stating exact exclusions, but the use case is clearly conveyed.
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?
With no annotations, the description carries the behavioral burden and does it well: it discloses that the comparison is neutral, that unresolved symbols populate an error field instead of failing the entire call, and that extra symbols beyond five are dropped. These are non-obvious runtime behaviors an agent needs to know.
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 compact and front-loaded: the core purpose appears first, the key distinction from peer_valuation follows, and the parameter behavior is summarized in a clear param line. Every sentence earns its place without redundancy.
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 a single parameter and a supplied output schema, the description covers the essential context: the target market, the nature of the comparison, the failure mode, and the input limit. An agent has enough information to invoke the tool correctly without needing to open schemas.
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?
The only parameter, symbols, has 0% schema description coverage, but the description fully compensates: 'ticker symbols to compare (max 5; extras are dropped)' clarifies the expected content, the limit, and the consequence of exceeding it. This adds meaningful semantics beyond the bare array-of-strings 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 names a precise verb and resource: compare profile, key ratios, growth, and health score for multiple NSE/BSE-listed Indian equities side by side. It also explicitly distinguishes this from relative-attractiveness ranking by pointing to peer_valuation, so an agent can select it correctly.
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 states when to use this tool (side-by-side comparison of fundamental metrics) and when not to use it (relative-attractiveness ranking), naming peer_valuation as the alternative. It also gives a concrete constraint (max 5 symbols) and partial-failure behavior, leaving little to inference.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so well. It discloses the model structure (5Y explicit growth + Gordon-growth terminal value), the default growth behavior, the 'stated assumption, not a prediction' caveat, and the terminal_growth < wacc constraint. These are meaningful behavioral traits beyond the raw schema.
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 front-loaded with the primary purpose, then provides model context, defaults, cross-check guidance, and parameter documentation in a logical order. Every sentence adds value; even the caveat about historical CAGR earning its place by preventing the agent from mistaking a default for a prediction.
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 DCF tool with four parameters, no annotations, and an output schema present, the description is complete. It covers what the model assumes, how defaults behave, the key constraint, and how the tool differs from reverse_dcf. Nothing critical for choosing or invoking this tool is missing.
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?
The schema has 0% description coverage, but the description provides explicit :param documentation for all four parameters. It explains symbol format with examples, growth format and default, wacc default, and terminal_growth default plus the critical constraint that it must be less than wacc. This fully compensates for the missing 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 opens with a specific verb and resource: 'Forward DCF: given growth/discount-rate assumptions, estimate intrinsic value per share and the margin of safety vs the current price.' It also explicitly contrasts itself with reverse_dcf by noting it runs the same two-stage model 'in the direct rather than solved-for direction,' which clearly distinguishes it from a very similar sibling.
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 positions this tool as the forward/direct DCF variant and points to reverse_dcf as the alternative for reverse-solved growth. It also advises cross-checking with reverse_dcf to see what growth the current price implies, giving an agent concrete guidance on when to use this tool versus a sibling.
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?
With no annotations at all, the description must carry the full burden, and it does: it discloses Indian-market filtering, demerger multiple-ticker behavior, renamed-company failures, and the real meaning of empty results.
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?
Although longer than average, every sentence serves a purpose; the core purpose and usage rule are front-loaded, and the behavioral caveats are organized clearly.
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 output schema exists and annotations are absent, this description provides all essential context an agent needs to call, interpret results, and handle edge cases for this search-first tool.
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?
Schema coverage is 0%, but the description fully compensates by defining `query` with examples and `limit` with a default and meaning, adding real semantics beyond the bare 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?
States a specific verb and resource ('Find the NSE/BSE/BSE ticker symbol for a company by name or partial name') and immediately says to use it before any other tool, making it distinct from siblings.
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?
Gives explicit when-to-use guidance ('whenever you know a company's name but not its exact Yahoo Finance ticker, before calling any other tool here') and warns against plain name searches mixing in irrelevant instruments, plus advises trying current/formal names on empty results.
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:

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

Score Badge

Copy to your README.md:

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

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/Prem07a/FinMCP'

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