AI 에이전트를 위한 실시간 금융 데이터. 주가, 기업 펀더멘털, 80만 개 이상의 FRED 경제 지표, SEC 공시 및 암호화폐 가격을 제공합니다. Base 네트워크의 x402 마이크로페이먼트를 통해 호출당 $0.01를 지불하며, 가입이나 API 키가 필요 없습니다.
AI 에이전트를 위한 금융 데이터. 주식, 펀더멘털, 경제, SEC 공시, 암호화폐 등 5가지 도구를 모든 MCP 클라이언트에서 사용할 수 있습니다. 호출당 $0.01를 지불하며, 별도의 가입 절차는 없습니다.
설치:
pip install findata-mcp지갑 키 설정 (Base 네트워크에 USDC가 있는 모든 EVM 지갑):
export EVM_PRIVATE_KEY=your_private_key_hereClaude Desktop에 추가 — ~/Library/Application Support/Claude/claude_desktop_config.json 파일을 수정하세요:
{
"mcpServers": {
"findata-mcp": {
"command": "findata-mcp",
"env": {
"EVM_PRIVATE_KEY": "your_private_key_here"
}
}
}
}Cursor에 추가 — 프로젝트 루트의 .cursor/mcp.json 파일을 수정하세요:
{
"mcpServers": {
"findata-mcp": {
"command": "findata-mcp",
"env": {
"EVM_PRIVATE_KEY": "your_private_key_here"
}
}
}
}클라이언트를 재시작하세요. 이제 5가지 금융 데이터 도구를 사용할 수 있습니다.
Related MCP server: MCP Financial Data Gateway
도구 | 반환 값 | 캐시 |
| 가격, 거래량, 변동률(%), 시가총액 | 1분 |
| 매출, P/E, 섹터, 베타, 배당 수익률, 설명 | 1시간 |
| 80만 개 이상의 FRED 시리즈 (GDP, CPI, 금리, 수익률 곡선) | 6시간 |
| SEC EDGAR의 10-K, 10-Q, 8-K 전문 | 24시간 |
| 가격, 시가총액, 24시간 거래량, 7일 스파크라인 | 1분 |
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"
}주요 FRED 시리즈: GDP, CPIAUCSL (인플레이션), UNRATE (실업률), DGS10 (10년물 국채), 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..."
}ticker의 별칭으로 ticker_or_cik (레거시) 또는 symbol도 사용할 수 있습니다.
호출당 $0.01. 가입, API 키, 월간 구독료가 없습니다.
결제는 오픈 마이크로페이먼트 프로토콜인 x402를 통해 자동으로 이루어집니다. MCP 클라이언트는 각 호출마다 Base 메인넷에서 USDC 전송에 서명합니다. 필요한 것:
EVM 지갑 개인 키 (EVM_PRIVATE_KEY로 설정)
Base 메인넷의 소액 USDC 잔액 (~$1로 100회 호출 가능)
이게 전부입니다. 계정 생성, 속도 제한, 결제 페이지가 없습니다.
pip install 패키지는 가벼운 MCP stdio 서버입니다. 이 서버는 도구 호출을 호스팅된 백엔드로 프록시하며, x402 결제 서명을 자동으로 처리합니다. 데이터는 Yahoo Finance, FRED, SEC EDGAR 및 CoinGecko에서 제공됩니다.
Your AI agent → findata-mcp (local stdio) → Backend (Railway) → Data providers
signs x402 payment verifies payment변수 | 필수 여부 | 기본값 | 설명 |
| 예 | — | Base 네트워크에 USDC가 있는 지갑 개인 키 |
| 아니오 | 프로덕션 URL | 자체 호스팅 백엔드 사용 시 재정의 |
uvx (설치 불필요):
uvx findata-mcpPyPI: findata-mcp
Glama: live
mcp.so: live
공식 MCP 레지스트리: 검토 대기 중
PyPI: 라이브
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.
v0.3.3company_fundamentalscrypto_priceeconomic_indicatorsec_filingstock_quoteScored across 5 tools
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.
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.
Real SEC, 13F, insider, congress & macro data your AI agent can cite. Hosted MCP, 24 tools.
Your agent needs markets — prices and fundamentals for listed companies, the filings behind them, crypto, and what the prediction markets put the odds at. **What you can ask for** • "Pull this company's income statement, cash flow and balance sheet for the last 8 quarters." • "What did insiders buy or sell, and when?" • "Snapshot prices for these 50 tickers, then the OHLC history for the three that moved." • "What are the current odds on this event across Kalshi and Polymarket?" • "Screen for companies matching these financial criteria." **How to use it** Point any MCP client at https://mcp.aisa.one/finance/mcp and sign in with OAuth — there is no key to create or paste. 49 tools: prices and snapshots, income statements, balance sheets and cash flows, metrics and ratios, earnings and analyst estimates, filings and line-item search, insider trades, macro interest rates, news, a screener; CoinGecko spot prices, market tables, OHLC, per-venue tickers and trending; Kalshi and Polymarket markets and trades; plus EDINET filings for Japan. **Why this rather than the source** Equities, crypto and event markets behind one account, so a cross-asset question is one conversation. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Read the number here, then ask the same agent what X is saying about the ticker today — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/marketpulse/mcp · /crypto-market-data/mcp · /prediction-market-data/mcp · /stock-pulse/mcp for one slice each.
Financial Datasets AI MCP — wraps financialdatasets.ai
Your agent needs company financials it can compute on — statements, ratios, earnings, estimates, filings and insider activity as structured data, not a PDF. **What you can ask for** • "Give me 8 quarters of income statement, balance sheet and cash flow for this ticker." • "What do analysts estimate for next quarter, and how did the last four surprise?" • "Find this exact line item across every filing." • "Who bought or sold as an insider in the last 90 days?" • "Screen for profitable companies under this valuation with growing revenue." **How to use it** Point any MCP client at https://mcp.aisa.one/marketpulse/mcp and sign in with OAuth — there is no key to create or paste. 21 tools: prices and snapshots, income statements, balance sheets, cash-flow statements, financial metrics and snapshots, earnings, analyst estimates, company facts, filings and filing items, line-item search, a screener, insider trades, macro interest rates, news, plus EDINET documents and filing digests for Japanese issuers. **Why this rather than the source** Statements as fields you can compute on, and a screener in the same place. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Read the fundamentals here, then ask the same agent what social is saying about the ticker — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/finance/mcp for equities, crypto and prediction markets in one place.
