The FinData MCP server provides real-time financial data for AI agents across five tools, with pay-per-call micropayments ($0.01/call) via x402 on Base — no signup or API keys required, just an EVM wallet with USDC.
Stock Quotes (stock_quote): Retrieve real-time (15-min delayed) stock price, volume, change %, and market cap for any NYSE/NASDAQ/global ticker (e.g., AAPL, TSLA).
Company Fundamentals (company_fundamentals): Access revenue, earnings, P/E ratio, market cap, sector, beta, dividend yield, and company description for any publicly traded company.
Economic Indicators (economic_indicator): Query 800,000+ US macroeconomic series from the Federal Reserve FRED database, including GDP, CPI, unemployment, interest rates, and yield curves.
SEC Filings (sec_filing): Retrieve full text of SEC filings from EDGAR — 10-K, 10-Q, 8-K, proxy statements, and S-1s — by ticker symbol or CIK number.
Crypto Prices (crypto_price): Get cryptocurrency price, market cap, 24-hour volume, and 7-day sparkline via CoinGecko using a coin ID (e.g., bitcoin, ethereum, solana).
The server integrates seamlessly with MCP clients like Claude Desktop and Cursor.
Stock market data, company fundamentals, FRED macroeconomic indicators, SEC EDGAR filings, and cryptocurrency prices for AI agents — all in one MCP server. Free trial: 50 calls/day. Pay-per-use: $0.01/call via x402 micropayments on Base. No signup, no API key.
Financial data for AI agents. Five tools covering real-time stock prices (NYSE, NASDAQ, 50,000+ tickers), equity fundamentals (P/E ratio, earnings, market cap), 800,000+ FRED economic series (GDP, CPI, inflation, interest rates, Treasury yields), SEC EDGAR filings (10-K annual reports, 10-Q, 8-K), and crypto prices (Bitcoin, Ethereum, 8,000+ coins). Works with Claude Desktop, Cursor, Windsurf, and any MCP client.
Install:
pip install findata-mcpSet your wallet key (any EVM wallet with USDC on Base):
export EVM_PRIVATE_KEY=your_private_key_hereAdd to Claude Desktop — edit ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"findata-mcp": {
"command": "findata-mcp",
"env": {
"EVM_PRIVATE_KEY": "your_private_key_here"
}
}
}
}Add to Cursor — edit .cursor/mcp.json in your project root:
{
"mcpServers": {
"findata-mcp": {
"command": "findata-mcp",
"env": {
"EVM_PRIVATE_KEY": "your_private_key_here"
}
}
}
}Restart your client. You now have five financial data tools available.
Related MCP server: MCP Financial Data Gateway
Tool | What it returns | Cache |
| Price, volume, change %, market cap | 1 min |
| Revenue, P/E, sector, beta, dividend yield, description | 1 hr |
| 800,000+ FRED series (GDP, CPI, rates, yield curves) | 6 hr |
| Full text of 10-K, 10-Q, 8-K from SEC EDGAR | 24 hr |
| Price, market cap, 24h volume, 7-day sparkline | 1 min |
stock_quote(ticker="NVDA"){
"ticker": "NVDA",
"price": 878.35,
"change": 12.40,
"change_pct": 1.43,
"volume": 41200000,
"market_cap": 2150000000000,
"currency": "USD"
}company_fundamentals(ticker="AAPL"){
"ticker": "AAPL",
"name": "Apple Inc.",
"sector": "Technology",
"market_cap": 3280000000000,
"pe_ratio": 33.2,
"revenue": 383285000000,
"beta": 1.24,
"dividend_yield": 0.0044
}economic_indicator(series_id="FEDFUNDS"){
"series_id": "FEDFUNDS",
"title": "Federal Funds Effective Rate",
"units": "Percent",
"frequency": "Monthly",
"latest_value": 4.33,
"latest_date": "2026-02-01"
}Common FRED series: GDP, CPIAUCSL (inflation), UNRATE (unemployment), DGS10 (10-year Treasury), FEDFUNDS.
sec_filing(ticker="AAPL", form_type="10-K"){
"ticker_or_cik": "AAPL",
"form_type": "10-K",
"filing_date": "2025-11-01",
"document_url": "https://www.sec.gov/Archives/...",
"content": "UNITED STATES SECURITIES AND EXCHANGE COMMISSION..."
}Also accepts ticker_or_cik (legacy) or symbol as aliases for ticker.
$0.01 per call. No signup, no API keys, no monthly fees.
Payment happens automatically via x402 — an open micropayment protocol. Your MCP client signs a USDC transfer on Base mainnet for each call. You need:
An EVM wallet private key (set as EVM_PRIVATE_KEY)
A small USDC balance on Base mainnet (~$1 covers 100 calls)
That's it. No accounts, no rate limits, no billing pages.
The pip install package is a thin MCP stdio server. It proxies your tool calls to a hosted backend, automatically handling x402 payment signing. Data comes from Yahoo Finance, FRED, SEC EDGAR, and CoinGecko.
Your AI agent → findata-mcp (local stdio) → Backend (Railway) → Data providers
signs x402 payment verifies paymentVariable | Required | Default | Description |
| Yes | — | Wallet private key with USDC on Base |
| No | Production URL | Override for self-hosted backend |
uvx (no install needed):
uvx findata-mcpPyPI: findata-mcp
Smithery: live
Glama: live
mcp.so: live
MIT
Full fundamental data: revenue, earnings, P/E ratio, market cap, sector, beta, dividend yield, and company description.
Args: ticker: Stock ticker symbol (e.g. AAPL, TSLA, MSFT) symbol: Alias for ticker — use either ticker or symbol
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | No | ||
| symbol | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Cryptocurrency price, market cap, 24h volume, and 7-day sparkline via CoinGecko.
Args: coin_id: CoinGecko coin ID in lowercase-hyphenated format (e.g. bitcoin, ethereum, solana, chainlink) symbol: Alias for coin_id coin: Alias for coin_id
| Name | Required | Description | Default |
|---|---|---|---|
| coin_id | No | ||
| symbol | No | ||
| coin | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
US macroeconomic data from the Federal Reserve FRED database: GDP, CPI, unemployment, interest rates, yield curves, and 800,000+ economic series.
Args: series_id: FRED series ID (e.g. GDP, CPIAUCSL, UNRATE, FEDFUNDS, DGS10) indicator: Alias for series_id — use either series_id or indicator
| Name | Required | Description | Default |
|---|---|---|---|
| series_id | No | ||
| indicator | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Full text of SEC filings from EDGAR: 10-K annual reports, 10-Q quarterlies, 8-K material events, proxy statements.
Args: ticker_or_cik: Stock ticker (AAPL) or SEC CIK number (320193) symbol: Alias for ticker_or_cik ticker: Alias for ticker_or_cik form_type: SEC form type (10-K, 10-Q, 8-K, DEF 14A, S-1)
| Name | Required | Description | Default |
|---|---|---|---|
| ticker_or_cik | No | ||
| symbol | No | ||
| ticker | No | ||
| form_type | No | 10-K |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Real-time (15-min delayed) stock price, volume, and change % for any NYSE/NASDAQ/global ticker.
Args: ticker: Stock ticker symbol (e.g. AAPL, TSLA, MSFT, NVDA) symbol: Alias for ticker — use either ticker or symbol
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | No | ||
| symbol | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.3.3company_fundamentalscrypto_priceeconomic_indicatorsec_filingstock_quoteEach 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The financial MCP for AI agents - 90+ financial tables, SEC filings, signals, alt-data.
Real SEC, 13F, insider, congress & macro data your AI agent can cite. Hosted MCP, 24 tools.
Twelve Data MCP: real-time & historical market data (stocks, crypto, forex, etc).
China A-share market data for research, backtesting and AI agents via MCP.
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
