open-fin-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target clearly distinct data areas (income statement, balance sheet, cash flow, segments, guidance, events). Minor overlap exists between get_capital_structure and get_balance_sheet, and between get_financial_metrics and get_capital_structure, but descriptions are specific enough to avoid serious confusion.
Naming Consistency4/5
The set largely follows a clear get_* / calculate_* / project_* / validate_* snake_case pattern, making tool purposes predictable. The one noticeable deviation is 'dcf_sensitivity', which would fit better as 'calculate_dcf_sensitivity' to match the other calculate_* tools.
Tool Count5/5
At 15 tools, the server sits right at the upper edge of the ideal range, and each tool covers a meaningful part of the financial analysis and valuation workflow. No tool feels redundant or trivial.
Completeness4/5
The server covers the core financial-statement data, key metrics, management insights, and the full DCF modeling chain from projection through sensitivity. Minor gaps exist, such as no direct analyst-estimate tool or historical price series, but agents can still complete typical valuation workflows.
Average 2.9/5 across 15 of 15 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It reveals that the tool performs validation (affecting a model?) but does not say if it mutates anything, returns detailed errors, or is read-only. There is no disclosure of side effects, failure behavior, or what 'basic model consistency' concretely checks. It is not contradictory, just insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, so it is concise, but it is also under-specified. It front-loads the verb but the content is too vague to be useful. Conciseness without information earns a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single undocumented object parameter and no annotations, the description is far from complete. The output schema exists, which could clarify return values, but the essential validation rules are missing. An agent cannot know what inputs are acceptable or what output to expect beyond a generic schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the only parameter is a nested object with additionalProperties true and no inner schema. The description says 'model' is checked but does not explain the expected shape, keys, or constraints. Since the schema provides almost no meaning for the parameter, the description needed to compensate but did not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says the tool validates required fields, numeric values, and basic model consistency, but omits what specific checks are performed or what 'model' means. It does distinguish this from its siblings (get_* tools are data-retrieval: fetch financial statements and metrics. This tool does validation, so the verb is distinct, but 'model' is ambiguous and the validation scope is under-specified. It is a tautology-level explanation: 'validate' + 'model' is near the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the sibling tools. It does not say 'use after building a model' or 'use before project_financials'. With zero context about prerequisites, ordering, or alternatives, an agent can't decide when to invoke it. No exclusions or alternative names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
没有注解，描述承担全部行为披露责任。描述只说了'获取指标'，未说明数据来源、TTM如何计算、输出格式、权限要求或可能的限制。对无注解的工具来说，行为透明明显不足。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
单句描述且无冗余，结构性良好。但过于简短，没有充分利用篇幅提供有价值的区分性和使用指导信息，接近欠规格而非真正的简洁。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
工具只有两个参数且其中一个是枚举，复杂度较低，但无注解、无输出schema内容展示，描述未提供足够的上下文来让代理正确调用。缺少返回值说明、期间语义、适用场景等关键信息。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
schema描述覆盖率为0%，描述完全没有提到参数。虽然枚举值annual/quarterly/ttm和默认值ttm提供了部分自解释信息，但描述没有解释period如何影响输出，也没有补充ticker格式或计算口径，未能补偿schema的空白。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述使用了具体动词'Get'并明确了资源类型（盈利、回报、利润率、杠杆指标），核心目的清楚。但它没有与同级工具（如get_income_statement、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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述完全没有提供何时使用该工具、何时使用更新或替代方案的建议。没有提及该工具适合与报表工具搭配使用，也没有说明ticker、period等参数的选择场景。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not say whether this is a read-only operation, how the guidance is computed or sourced, whether it reflects trailing or forward-looking data, or anything about response behavior. For a tool named 'get' it is safe to assume read-only, but that is conjecture, not disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler. It is concise, but it earns its conciseness at the cost of substance — brevity alone is not a virtue when critical information is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a data-retrieval tool with one parameter, an output schema, and no annotations, the description is adequate at the bare minimum level: the agent knows roughly what it gets and that it needs a ticker. It does not explain what 'management guidance and outlook' includes (EPS estimates? revenue ranges? commentary?), nor what distinguishes it from get_concall_summary, which likely returns related qualitative commentary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the ticker parameter at all. The schema only says ticker is a required string, so the agent is left to guess whether format matters (e.g., case, exchange suffix). The description adds zero value for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource: 'get the latest quantitative management guidance and outlook' — this tells the agent what it retrieves. However, it does not explicitly distinguish it from siblings like get_financial_metrics or get_concall_summary, so an agent could not tell from the description alone which tool to choose among those overlapping ones.
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 use this tool versus alternatives such as get_concall_summary or get_financial_metrics. The context must be inferred from the tool name and the generic phrase 'management guidance and outlook,' which is too thin to route an agent reliably.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that inputs should be decimal rates but does not state the formula used (e.g., E/(E+D) * Re + D/(E+D) * Rd * (1-t)), whether tax_rate should be decimal or percentage, output behavior, or any assumption (e.g., market values). For a calculation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no waste. It is front-loaded with the verb and resource. However, it is so brief that it sacrifices useful detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 required parameters and no output schema, the description is incomplete for confident use. It omits the WACC formula, decimal vs percentage convention for each rate input, and output format, and does not mention that market values should be in the same currency unit. An agent could call it with wrong conventions (e.g., percentages instead of decimals, tax rate given as 25 instead of 0.25).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions 'decimal-rate inputs' without mapping to specific parameters. It does not clarify semantics like tax_rate being decimal, cost rates as decimals, or market values in currency units. The parameters are named self-evidently, but description compensates little for zero schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description says 'Calculate weighted average cost of capital from decimal-rate inputs' – a clear verb (calculate) and resource (WACC) with the key input format note. It is not a tautology, but it does not distinguish itself from sibling tools like validate_financial_model or calculate_dcf.
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 this is for computing WACC from decimal-rate inputs but provides no explicit guidance on when to use this tool versus alternative financial tools like calculate_dcf or get_capital_structure. There are no exclusions or listed alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It signals a read operation ('Get') and a time scope ('upcoming and recent'), which is useful. But it does not explain what event types are included, what 'recent' means, or how results are ordered or filtered.
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?
One short sentence with zero filler; the verb and temporal scope are front-loaded and every word earns its place. It is concise without being padded, though it borders on under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with an output schema present, the description covers the basic purpose and is a minimum-viable definition. However, the absence of annotations, parameter documentation, and event-type definition leaves gaps an agent would need to resolve before or after calling it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions the required 'ticker' parameter. The parameter name is self-explanatory, but its format (e.g., 'AAPL' vs. exchange-qualified symbols) is undocumented in both the schema and the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get upcoming and recent company events'), and the temporal scope ('upcoming and recent') adds useful precision. It is the only sibling tool dealing with events, so an agent can distinguish it from the financial-statement and DCF tools. However, it does not define what counts as an 'event' (earnings call, dividend, conference), so differentiation is clear but not explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The intended use case is only implied by the word 'events' in contrast to the financial-statement siblings, with no exclusions, prerequisites, or explicit alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only lists returned metrics and does not mention units, currency, point-in-time basis, as-reported versus adjusted figures, or any other operational traits. It is not misleading, but it is very thin.
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 efficient sentence that front-loads the resource and immediately lists the outputs. It contains no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one required parameter, an output schema exists, and the description states the core purpose. However, it lacks usage guidance and any behavioral or semantic detail, making it only minimally viable for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description does not mention the ticker parameter at all. The input schema provides only the name and type, so no additional meaning, format, or example is added to help the agent understand acceptable values.
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 uses a specific verb ('Get') and names the resource ('capital structure') with concrete contents: cash, debt, net debt, and diluted shares outstanding. This clearly distinguishes it from statement-level siblings, although it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus related tools like get_balance_sheet or get_financial_metrics. There are no contextual cues, exclusions, or alternative references, leaving tool selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only source. It discloses the output content but says nothing about data availability by ticker/quarter, latency, or whether a missing summary returns null. No side effects or limitations are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One clear, front-loaded sentence with no filler. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, but the description omits any detail about the optional quarter parameter or data-source caveats. An agent cannot reliably format a quarter-specific request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description doesn't mention either parameter. The 'quarter' parameter exists but is undocumented, leaving its format and meaning unknown.
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 ('earnings-call summary'), and names the content (themes, risks, sentiment). This clearly differentiates it from sibling tools like get_income_statement or get_management_guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over siblings such as get_management_guidance or get_company_events. The only usage context is implicit in the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral-disclosure burden. It only conveys 'historical income statements' and 'public company ticker,' leaving unspecified how period and limit defaults affect behavior, what data is returned, or any limitations. The scope constraint is useful, but behavioral detail is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence with the core action and resource front-loaded. Every word earns its place, and there is no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The input schema documents required fields, defaults, and the period enum, and an output schema exists, so return-value details are not the description's responsibility. However, the description does not help route the agent among the many sibling financial tools or explain parameter semantics, making it minimally complete but not self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain parameter meaning. It clarifies ticker as a public-company identifier and 'historical' loosely suggests a time dimension, but limit and the annual/quarterly/ttm period options are left entirely to the schema without any added context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves historical income statements for a public company ticker, identifying the specific resource and operation. It does not explicitly contrast with get_balance_sheet or get_cashflow_statement, but the income-statement focus is unambiguous enough to distinguish the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for obtaining income statements, but it gives no guidance on when to prefer it over sibling tools such as get_balance_sheet or get_cashflow_statement, and no exclusions or alternative routing are mentioned. An agent choosing among overlapping financial-statement tools gets no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for behavioral disclosure. It mentions the returned data types (price, market capitalization), but omits details about currency conversion, ticker validation, data freshness, failure modes, or any side effects. This is minimal disclosure for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler. It front-loads the core operation and object of the call. It is concise but not over-specified; still, it could add a little more useful information without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return structure is covered, but the description lacks guidance on when to use this tool, what the currency option implies, and how it relates to the broader financial data suite. For a simple market data tool this is adequate at a basic level but leaves meaningful usage gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that 'ticker' identifies the entity and that the output relates to price and market cap, but it provides no explanation of the 'currency' parameter beyond what the enum and default already show.
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 ('Get') and resource ('latest price and market capitalization') scoped to a ticker. This clearly distinguishes it from sibling tools that retrieve income statements, balance sheets, cash flows, or financial metrics.
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 when-to-use or when-not-to-use guidance is provided. The description implies the tool is for current market data, but it does not identify alternatives or conditions for choosing this over the sibling financial data tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry behavioral disclosure. It indicates a read-only historical operation, but fails to mention response format, how limit and period affect returned data, or any other runtime behavior. This is thin for an unannotated tool.
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?
One clean sentence, front-loaded with the core action and no filler. It's appropriately concise for a three-parameter tool, though it could have gained a fifth point by briefly noting limit/period semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return documentation is not needed, and sibling context helps disambiguate. But with no parameter documentation and no annotations, the agent must guess at limit and period semantics. The definition is minimally adequate, not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to compensate for parameter meaning. It implicitly covers ticker but says nothing about limit or period beyond the schema's enum values. An agent cannot fully infer what limit controls or what 'ttm' means from the given text.
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 uses a specific verb-resource pair ('Get historical cash flow statements') and names the target ('public company ticker'). It distinguishes the financial statement type from siblings like get_income_statement and get_balance_sheet, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when historical cash flow data is needed for a public company, and sibling names clarify the domain. However, it offers no explicit when-to-use versus alternatives, no exclusions, and no guidance on choosing annual, quarterly, or ttm periods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a read-style historical lookup, but does not disclose output format, pagination behavior, data limitations, normalization, or units. This is a significant gap for an unannotated 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 a single, front-loaded sentence with no filler words. It immediately conveys the action, the resource, and the audience, so every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter tool with an output schema, the description is minimally adequate: an agent knows what data it provides and what input is required. However, it omits guidance on how 'limit' and 'period' behave, when to use annual versus quarterly versus TTM, and how to pick between this and sibling statement tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate by explaining the parameters. It only repeats 'ticker' as a public company ticker and says 'historical,' leaving 'limit' and 'period' to be inferred from their names, defaults, and enum values. No meaningful parameter-level guidance is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource ('historical balance sheets') and the target ('public company ticker'), which is specific enough to identify the tool's purpose. It naturally differentiates from sibling income statement and cash flow tools, but it does not explicitly name or contrast those alternatives, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: an agent would call this when it needs a company's historical balance sheet data. However, there is no explicit when-to-use or when-not-to-use guidance, no mention of alternatives, and no clarification of when to prefer another financial statement tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the high-level computation but does not disclose whether this is a pure calculation, how assumptions are applied, whether any external data is fetched, or what edge-case behavior occurs. There is no contradiction with annotations, but the behavioral surface is largely underexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence with no filler. It front-loads the action and resources, and every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The input schema is self-describing and an output schema exists, so the description does not need to enumerate return fields. Even so, it omits the key context that this is a forward-looking projection tool distinct from historical statement getters, and it gives no guidance on when to invoke it. The definition is adequate only if the agent relies on the schema and sibling list, not the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Per the context signal, schema coverage is 100%, so the schema already documents the assumptions object and its defaults/constraints. The description adds no details about the parameters (e.g., that tax_rate is a decimal or that ebit_margin defaults to 0.18), so it contributes no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Project' with explicit financial outputs (revenue, EBIT, NOPAT, unlevered free cash flow), which clearly distinguishes it from sibling data-retrieval tools like get_income_statement and calculate_dcf. It could be slightly stronger by saying 'forecast' or 'based on assumptions,' but it is not vague or tautological.
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 mention of when to use this tool over alternatives. The sibling names suggest a projection-vs-historical distinction, but the description never states that this is a forward-looking model or that get_* tools should be used for historical data. Agents must infer usage from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It clearly indicates a pure calculation producing a per-share matrix, which implies read-only behavior. However, it does not explain how the rate arrays are iterated or how assumptions.discount_rate relates to discount_rates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with an active verb and the key deliverable front-loaded. There is no filler, repetition, or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a nested-object financial model with three required parameters and no annotations, one sentence is not enough. The output schema may cover return values, but the description omits usage context, the meaning of the scalar discount_rate within assumptions, and how this tool differs from the single-point DCF sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description must compensate, but it never mentions the assumptions object or its required fields. It maps 'WACC' and 'growth rates' to discount_rates and terminal_growth_rates, yet leaves the role of assumptions.discount_rate ambiguous relative to the discount_rates array.
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: 'Calculate a per-share DCF sensitivity matrix across WACC and growth rates.' The phrase 'sensitivity matrix' clearly differentiates it from the sibling calculate_dcf tool, which likely performs a single-point valuation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus calculate_dcf, calculate_wacc, or project_financials. The word 'sensitivity' implies scenario analysis, but there are no explicit alternatives, exclusions, or conditions for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it does state the result and the method. However, it is thin on details such as how terminal growth is handled, especially since the visible schema does not include a terminal-growth-rate parameter, leaving some ambiguity about the actual computation.
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?
One sentence, front-loaded with the action and result, with no filler or redundant restatement of the schema. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a calculation tool with an output schema, the description need not explain return values, but it leaves two material gaps: it gives no usage/exclusion guidance versus sibling valuation tools, and it mentions terminal-growth DCF without a corresponding terminal-growth parameter in the visible schema. This makes the definition adequate but incomplete for confident autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The top-level schema description coverage is high, so the baseline is 3 even without per-parameter prose in the tool description. The output terms 'enterprise' and 'per-share' hint at the roles of net_debt and shares_outstanding, but the description adds no explicit guidance on the required free_cash_flows array or discount_rate semantics beyond what the schema already encodes.
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 (calculate), a specific resource/method (terminal-growth DCF), and the exact outputs (enterprise, equity, and per-share value). This makes it easy to distinguish from siblings like calculate_wacc and dcf_sensitivity, even before opening the schema.
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 when-to-use or when-not-to-use guidance is provided. There is no mention of alternatives such as dcf_sensitivity for scenario analysis, project_financials for projected cash flows, or calculate_wacc for the discount rate, so an agent must infer usage from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It correctly indicates a read-only retrieve operation and notes that data follows reported business segments, but it does not mention potential missing segment data for some tickers or how segments are defined. This is adequate but leaves some uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the key information—what data is retrieved and at what granularity—making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with two parameters and an output schema, so the description covers the core purpose. However, missing parameter semantics and lack of any guidance on data availability make it only minimally complete for an agent that needs to decide when this data is reliable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain either parameter. The ticker and period are left entirely to the schema's enum and type definitions. The description only names the output fields, not the input semantics, so it fails to compensate for the lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches revenue and operating income by reported business segment, which is a specific verb and resource. This distinguishes it from sibling tools like get_income_statement, which return company-wide financials rather than segment-level data.
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 phrase 'reported business segment' makes the intended use case clear: retrieving segment breakdowns when needed. It does not explicitly exclude alternatives like get_financial_metrics or get_income_statement, but the segment focus implicitly differentiates it.
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:

[![open-fin-mcp MCP server](https://glama.ai/mcp/servers/HareRam123/open-fin-mcp/badges/card.svg)](https://glama.ai/mcp/servers/HareRam123/open-fin-mcp)

Score Badge

Copy to your README.md:

[![open-fin-mcp MCP server](https://glama.ai/mcp/servers/HareRam123/open-fin-mcp/badges/score.svg)](https://glama.ai/mcp/servers/HareRam123/open-fin-mcp)

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/HareRam123/open-fin-mcp'

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