FinData MCP

Server Quality Checklist

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

Latest release: v0.3.3
Disambiguation5/5
Each tool has a clearly distinct purpose targeting different financial data domains: company fundamentals, cryptocurrency prices, economic indicators, SEC filings, and stock quotes. There is no overlap in functionality, making tool selection straightforward for an agent.
Naming Consistency4/5
The naming follows a consistent snake_case pattern with descriptive noun-based names (e.g., company_fundamentals, crypto_price). However, there is a minor inconsistency with 'sec_filing' using an acronym while others use full words, slightly deviating from perfect uniformity.
Tool Count5/5
With 5 tools, the server is well-scoped for financial data retrieval, covering key areas like stocks, crypto, economics, and regulatory filings. Each tool serves a specific and necessary function without redundancy, making the count appropriate for the domain.
Completeness4/5
The toolset provides comprehensive coverage for retrieving financial data across multiple domains, with no obvious gaps for core operations. A minor gap might be the lack of tools for historical data analysis or portfolio management, but the surface is complete for basic data access needs.
Average 3.4/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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

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 mentions the source (EDGAR) and types of filings, but lacks critical behavioral details: whether this is a read-only operation, potential rate limits, authentication needs, or what the output contains beyond 'full text'. For a data retrieval tool with no annotations, this is insufficient.
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, followed by a structured 'Args:' section. It's efficient with minimal waste, though the aliasing of parameters could be more succinctly explained (e.g., noting all three refer to the same input).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with 0% schema coverage and no annotations, the description partially compensates by explaining parameter purposes and providing examples. An output schema exists, so return values needn't be described. However, for a tool fetching financial documents, more context on usage scenarios or limitations would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that 'ticker_or_cik', 'symbol', and 'ticker' are aliases for identifying companies, and 'form_type' specifies the SEC form, with examples. This adds meaning beyond the bare schema, but doesn't detail format constraints (e.g., CIK number length) or default behavior, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'Full text of SEC filings from EDGAR' and lists specific document types (10-K, 10-Q, 8-K, proxy statements). It uses a specific verb ('Full text of') and identifies the resource (SEC filings), though it doesn't explicitly differentiate from sibling tools like 'company_fundamentals' which might provide different financial data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'company_fundamentals' or 'stock_quote'. It lists the types of filings available but doesn't indicate scenarios where this tool is preferred over siblings or any prerequisites for use.
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 implies a read-only operation by listing data retrieval, but doesn't specify critical details like rate limits, authentication needs, data freshness, or error handling. For a tool with no annotations, this leaves significant behavioral gaps unaddressed.
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 structured with a clear purpose statement followed by parameter explanations. Both sentences earn their place by defining the tool's scope and clarifying parameter usage. However, the 'Args:' section formatting is slightly redundant with the parameter semantics explanation, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with output schema), the description is reasonably complete. It covers what data is returned and parameter usage. Since an output schema exists, the description doesn't need to detail return values. The main gap is lack of behavioral context, but the presence of output schema reduces the completeness burden.
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 clearly explains that both 'ticker' and 'symbol' are aliases for stock ticker symbols, providing examples (AAPL, TSLA, MSFT) and clarifying they're interchangeable. This adds meaningful context beyond the bare schema, though it doesn't detail format constraints beyond examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'full fundamental data' and lists specific metrics (revenue, earnings, P/E ratio, etc.), making the purpose evident. It distinguishes from sibling tools like 'stock_quote' by focusing on comprehensive fundamentals rather than just price data. However, it doesn't explicitly contrast with 'sec_filing' which might also provide fundamental data, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'stock_quote' or 'sec_filing'. It mentions the parameters but doesn't explain scenarios where fundamental data is preferred over simpler quotes or detailed filings. This lack of comparative context leaves the agent without clear usage direction.
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 full burden for behavioral disclosure. It mentions the data source (CoinGecko) and data fields returned, but doesn't cover important aspects like rate limits, authentication requirements, error handling, or whether this is a read-only operation. The description adds some context but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. The first sentence clearly states the purpose and data source, followed by a parameter section that efficiently explains the aliasing relationship. No wasted words, though the parameter explanation could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which presumably documents the return structure), the description appropriately focuses on purpose, source, and parameter semantics. It provides enough context for basic usage, though additional behavioral information would be helpful given the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides crucial semantic information about the three parameters, explaining they are all aliases for the same CoinGecko coin ID and specifying the required format (lowercase-hyphenated). With 0% schema description coverage and no enums, this compensation is substantial, though it could be more explicit about which parameter to prefer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves cryptocurrency price, market cap, 24h volume, and 7-day sparkline data via CoinGecko. It specifies the resource (cryptocurrency data) and source (CoinGecko), but doesn't explicitly differentiate from sibling tools like stock_quote or economic_indicator beyond the cryptocurrency focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like stock_quote for stocks or economic_indicator for economic data, nor does it specify any prerequisites or constraints for cryptocurrency data retrieval.
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 mentions the data source (FRED) and scope (800,000+ series), but doesn't disclose behavioral traits like rate limits, authentication needs, response format, or potential errors. For a data retrieval tool with zero annotation coverage, this is a significant gap in transparency.
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 appropriately sized with two sentences: one for purpose and scope, and another for parameters. It's front-loaded with key information and avoids redundancy. However, the parameter explanation could be slightly more integrated into the main text for better flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (data retrieval with many series), no annotations, and an output schema present, the description is reasonably complete. It covers the purpose, data source, and parameter usage, though it could benefit from more behavioral details. The output schema likely handles return values, so the description doesn't need to explain them.
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 explains that 'series_id' is a FRED series ID with examples (e.g., GDP, CPIAUCSL) and that 'indicator' is an alias for 'series_id', clarifying they are interchangeable. This adds meaningful context beyond the bare schema, though it doesn't detail format constraints or provide a full list of valid IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'US macroeconomic data from the Federal Reserve FRED database' and lists specific examples (GDP, CPI, unemployment, etc.). It distinguishes from sibling tools by focusing on economic indicators rather than company data, crypto, SEC filings, or stock quotes. However, it doesn't specify the exact verb (e.g., 'retrieve' or 'fetch'), keeping it from a perfect score.
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 by mentioning the FRED database and examples, suggesting it's for economic data queries. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., no comparison to sibling tools) or any prerequisites. The context is clear but not detailed enough for full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: real-time nature with 15-minute delay, supported exchanges (NYSE/NASDAQ/global), and the data points returned (price, volume, change %). It doesn't mention rate limits, authentication needs, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by parameter explanations. The two-sentence format is efficient, though the parameter section could be slightly more concise by combining the ticker/symbol relationship into one sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, no annotations, and an output schema (which handles return values), the description is quite complete. It covers purpose, behavioral context, and parameter semantics adequately, though it could benefit from mentioning any limitations or prerequisites.
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?
With 0% schema description coverage, the description fully compensates by explaining both parameters: ticker as the stock symbol with examples (AAPL, TSLA, MSFT, NVDA) and symbol as an alias for ticker. It clarifies the relationship between them (use either) which isn't evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving real-time stock price, volume, and change percentage for specific tickers. It specifies the scope (NYSE/NASDAQ/global) and distinguishes itself from siblings like crypto_price and economic_indicator by focusing on traditional stock data.
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 stock tickers only, but doesn't explicitly state when to use this tool versus alternatives like company_fundamentals or sec_filing. There's no guidance about when not to use it or what specific use cases it serves best.
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:

[![findata-mcp MCP server](https://glama.ai/mcp/servers/sapph1re/findata-mcp/badges/card.svg)](https://glama.ai/mcp/servers/sapph1re/findata-mcp)

Score Badge

Copy to your README.md:

[![findata-mcp MCP server](https://glama.ai/mcp/servers/sapph1re/findata-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sapph1re/findata-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/sapph1re/findata-mcp'

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