Toolstem MCP Server
Toolstem MCP 서버
에이전트 준비 완료형 금융 인텔리전스 도구 — 가공되지 않은 데이터가 아닌, 엄선된 데이터입니다.
Toolstem은 원시 금융 시장 데이터를 AI 에이전트를 위한 엄선된 합성 인텔리전스로 변환하는 MCP(Model Context Protocol) 서버입니다. 단순히 공급업체의 REST API를 노출하는 패스스루 래퍼와 달리, 모든 Toolstem 도구는 여러 데이터 소스를 결합하고, 신호를 도출하며, 에이전트가 직접 수행해야 할 수학적 계산을 미리 수행합니다.
한 번의 호출. 에이전트 친화적인 JSON 응답 하나. 파싱할 중첩 배열도, 엔드포인트 간 연결도, null 체크를 위한 상용구 코드도 필요 없습니다.
왜 Toolstem인가?
대부분의 금융 MCP 서버는 API 엔드포인트당 하나의 도구를 노출하므로, 에이전트가 4~5번의 순차적 호출을 수행하고, 접착제 코드를 작성하며, 원시 데이터 형태를 추론해야 합니다. Toolstem은 다르게 구축되었습니다:
병렬 데이터 가져오기 — 모든 도구가 여러 소스로 동시에 데이터를 요청합니다.
도출된 신호 — 원시 숫자에서 계산된
UNDERVALUED,STRONG,ACCELERATING과 같은 사람이 읽을 수 있는 권장 사항입니다.미리 계산된 수학 — CAGR, YoY 성장률, 마진 추세, 52주 최고/최저가 대비 거리, FCF 수익률 등이 이미 응답에 포함되어 있습니다.
평탄하고 예측 가능한 스키마 — 에이전트 프롬프트에 깊게 중첩된 공급업체 특이 사항이 노출되지 않습니다.
우아한 성능 저하 — 상위 엔드포인트 중 하나가 실패하더라도 나머지 응답은 null 값을 포함하여 정상적으로 전달됩니다.
Related MCP server: TickerAPI
도구
get_stock_snapshot
시세, 프로필, DCF 가치 평가 및 등급을 단일 응답으로 결합한 포괄적인 주식 개요입니다.
입력:
{
"symbol": "AAPL"
}예시 출력 (생략됨):
{
"symbol": "AAPL",
"company_name": "Apple Inc.",
"sector": "Technology",
"industry": "Consumer Electronics",
"exchange": "NASDAQ",
"price": {
"current": 178.52,
"change": 2.34,
"change_percent": 1.33,
"day_high": 179.80,
"day_low": 175.10,
"year_high": 199.62,
"year_low": 130.20,
"distance_from_52w_high_percent": -10.57,
"distance_from_52w_low_percent": 37.11
},
"valuation": {
"market_cap": 2780000000000,
"market_cap_readable": "$2.78T",
"pe_ratio": 29.5,
"dcf_value": 195.20,
"dcf_upside_percent": 9.35,
"dcf_signal": "FAIRLY VALUED"
},
"rating": {
"score": 4,
"recommendation": "Buy",
"dcf_score": 5,
"roe_score": 4,
"roa_score": 4,
"de_score": 5,
"pe_score": 3
},
"fundamentals_summary": {
"beta": 1.28,
"avg_volume": 55000000,
"employees": 164000,
"ipo_date": "1980-12-12",
"description": "Apple Inc. designs, manufactures..."
},
"meta": {
"source": "Toolstem via Financial Modeling Prep",
"timestamp": "2026-04-17T18:30:00Z",
"data_delay": "End of day"
}
}도출된 필드 (원시 API에는 없음):
dcf_signal— DCF 상승 여력이 10% 초과 시UNDERVALUED, -10% 미만 시OVERVALUED, 그 외에는FAIRLY VALUED.market_cap_readable—$2.78T,$450.2B,$12.5M과 같은 사람이 읽기 쉬운 형식.distance_from_52w_high_percent/distance_from_52w_low_percent— 미리 계산된 범위 위치.
get_company_metrics
수익성, 재무 건전성, 현금 흐름, 성장 및 주당 지표 등 5개의 재무제표 엔드포인트에서 합성된 심층 기본 분석입니다.
입력:
{
"symbol": "AAPL",
"period": "annual"
}period는 annual(기본값) 또는 quarter를 허용합니다.
예시 출력 (생략됨):
{
"symbol": "AAPL",
"period": "annual",
"latest_period_date": "2025-09-30",
"profitability": {
"revenue": 394328000000,
"revenue_readable": "$394.3B",
"revenue_growth_yoy": 7.8,
"net_income": 96995000000,
"net_income_readable": "$97.0B",
"gross_margin": 46.2,
"operating_margin": 31.5,
"net_margin": 24.6,
"roe": 160.5,
"roa": 28.3,
"roic": 56.2,
"margin_trend": "EXPANDING"
},
"financial_health": {
"total_debt": 111000000000,
"total_cash": 65000000000,
"net_debt": 46000000000,
"debt_to_equity": 1.87,
"current_ratio": 1.07,
"interest_coverage": 41.2,
"health_signal": "STRONG"
},
"cash_flow": {
"operating_cash_flow": 118000000000,
"free_cash_flow": 104000000000,
"free_cash_flow_readable": "$104.0B",
"fcf_margin": 26.4,
"capex": 14000000000,
"dividends_paid": 15000000000,
"buybacks": 89000000000,
"fcf_yield": 3.7
},
"growth_3yr": {
"revenue_cagr": 8.2,
"net_income_cagr": 10.1,
"fcf_cagr": 9.5,
"growth_signal": "ACCELERATING"
},
"per_share": {
"eps": 6.42,
"book_value_per_share": 3.99,
"fcf_per_share": 6.89,
"dividend_per_share": 0.96,
"payout_ratio": 14.9
},
"meta": {
"source": "Toolstem via Financial Modeling Prep",
"timestamp": "2026-04-17T18:30:00Z",
"periods_analyzed": 3,
"data_delay": "End of day"
}
}도출된 필드:
margin_trend— 순이익률 추세 방향에 따라EXPANDING,STABLE또는CONTRACTING으로 표시.health_signal— 부채비율, 유동비율, 이자보상배율을 기반으로STRONG,ADEQUATE또는WEAK로 표시.growth_signal— YoY 성장 궤적에 따라ACCELERATING,STEADY또는DECELERATING으로 표시.revenue_cagr,net_income_cagr,fcf_cagr— 분석 기간 동안의 연평균 성장률.fcf_margin,fcf_yield— 현금 흐름 + 매출 + 시가총액에서 미리 계산됨.
설치
npm
npm install -g toolstem-mcp-serverstdio 서버로 실행:
FMP_API_KEY=your_key_here toolstem-mcp-serverHTTP(Streamable HTTP transport) 서버로 실행:
FMP_API_KEY=your_key_here PORT=3000 toolstem-mcp-server --httpClaude Desktop
claude_desktop_config.json에 추가:
{
"mcpServers": {
"toolstem": {
"command": "npx",
"args": ["-y", "toolstem-mcp-server"],
"env": {
"FMP_API_KEY": "your_fmp_api_key"
}
}
}
}Smithery
Toolstem은 지원되는 MCP 클라이언트에 클릭 한 번으로 설치할 수 있도록 Smithery에 배포되어 있습니다.
Apify
Apify Store에서 toolstem-financial-data Actor로 제공됩니다. Apify 워크플로우에서 다음 입력으로 호출하세요:
{
"tool": "get_stock_snapshot",
"symbol": "AAPL"
}또는
{
"tool": "get_company_metrics",
"symbol": "AAPL",
"period": "annual"
}결과는 기본 데이터 세트로 푸시됩니다. 이 액터는 Apify의 Pay-Per-Event 모델을 통해 도구 호출당 수익을 창출합니다.
자체 호스팅 (Cloudflare Workers / 모든 Node 런타임)
HTTP 전송을 빌드하고 실행:
npm install
npm run build
FMP_API_KEY=your_key npm run start:httpMCP 클라이언트는 POST http://your-host:3000/mcp에 연결할 수 있습니다.
환경 변수
변수 | 필수 | 설명 |
| 예 | Financial Modeling Prep API 키. financialmodelingprep.com에서 발급받으세요. |
| 아니오 | HTTP 전송을 위한 포트. 기본값은 |
개발
npm install
npm run dev # stdio, hot reload via tsx
npm run build # TypeScript -> dist/
npm start # run built stdio server
npm run start:http # run built HTTP server아키텍처
src/
├── index.ts # MCP server entry (stdio + Streamable HTTP)
├── actor.ts # Apify Actor entry
├── services/
│ └── fmp.ts # Financial Modeling Prep API client
├── tools/
│ ├── get-stock-snapshot.ts
│ └── get-company-metrics.ts
└── utils/
└── formatting.ts # Market cap formatting, CAGR, trend signals모든 FMP 엔드포인트는 단일 FmpClient 클래스로 래핑됩니다. 도구 구현은 Promise.all을 통해 여러 클라이언트 메서드로 병렬로 팬아웃(fan-out)한 다음, 병합된 결과를 합성합니다.
라이선스
MIT — LICENSE를 참조하세요.
Toolstem — 에이전트 네이티브 경제를 위한 엄선된 금융 인텔리전스.
Available Tools
3 toolscompare_companiesCompany ComparisonARead-onlyIdempotent
Side-by-side comparison of 2-5 companies across price, valuation (P/E, P/B, P/S, EV/EBITDA, DCF), profitability (margins, ROE, ROA, ROIC), financial health (D/E, current ratio, interest coverage), growth (revenue and earnings YoY), dividends, and analyst ratings. Returns derived rankings showing which company leads each dimension — lowest_pe, highest_margin, strongest_balance_sheet, best_growth, most_undervalued, highest_rated. Use this for investment comparisons, competitive analysis, or evaluating alternatives in the same sector.
| Name | Required | Description | Default |
|---|---|---|---|
| symbols | Yes | 2-5 stock ticker symbols to compare (e.g., ["AAPL", "MSFT", "GOOGL"]) |
Output Schema
| Name | Required | Description |
|---|---|---|
| symbols_compared | Yes | |
| comparison_date | Yes | |
| companies | Yes | |
| rankings | Yes | |
| meta | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description aligns fully, detailing the read-only operation and output format (derived rankings). No contradictions, and the description adds significant behavioral context (categories of metrics, derived rankings) beyond annotations.
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?
Three sentences: first states core purpose, second lists all metric categories, third gives use cases. Front-loaded, no filler, every sentence adds value.
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 (many metrics and derived rankings) and the presence of an output schema, the description is complete. It covers input constraints (2-5 symbols), output nature (derived rankings), and typical use cases. No gaps for an agent to misuse.
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 100% (the symbols parameter has a detailed description including example). The tool description restates '2-5 companies' but adds no new semantics beyond the schema. Baseline 3 applies.
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 explicitly states the tool performs side-by-side comparison of 2-5 companies across price, valuation, profitability, financial health, growth, dividends, and analyst ratings. It also lists derived rankings (lowest_pe, etc.). This clearly distinguishes from siblings get_company_metrics (likely single company) and get_stock_snapshot (likely a quick overview).
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 explicit use cases: 'Use this for investment comparisons, competitive analysis, or evaluating alternatives in the same sector.' It does not explicitly state when not to use or name alternatives, but the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_company_metricsCompany MetricsARead-onlyIdempotent
Deep financial analysis including profitability, financial health, cash flow, growth (3-year CAGR), and per-share metrics. Synthesizes key metrics, financial ratios, income statement, balance sheet, and cash flow statement into one agent-ready response with derived signals: margin_trend (EXPANDING/STABLE/CONTRACTING), health_signal (STRONG/ADEQUATE/WEAK), and growth_signal (ACCELERATING/STEADY/DECELERATING). Use this for fundamental analysis, financial health checks, or when you need to understand a company's trajectory.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock ticker symbol (e.g., AAPL, MSFT, TSLA) | |
| period | No | Reporting period. Defaults to annual. | annual |
Output Schema
| Name | Required | Description |
|---|---|---|
| symbol | Yes | |
| period | Yes | |
| latest_period_date | Yes | |
| profitability | Yes | |
| financial_health | Yes | |
| cash_flow | Yes | |
| growth_3yr | Yes | |
| per_share | Yes | |
| meta | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering safety. The description adds value by explaining derived signals and output structure, but doesn't disclose additional behavioral traits beyond what annotations provide.
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?
Two sentences, front-loaded with key content. Each sentence contributes: first lists included metrics, second explains output and use cases. No unnecessary words.
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 presence of an output schema (handling return values), complete schema coverage, and annotations covering safety, the description provides sufficient context about purpose, usage, and derived signals. It is thorough for a tool of this complexity.
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 100%, so the schema already documents both parameters adequately. The description does not add extra parameter detail beyond what is in the schema, aligning with the baseline of 3.
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 it provides deep financial analysis and synthesizes key metrics, ratios, and statements into an agent-ready response. It distinguishes from siblings (compare_companies and get_stock_snapshot) by emphasizing depth and derived signals.
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?
Explicitly recommends use for fundamental analysis, financial health checks, or understanding a company's trajectory. While it doesn't directly mention alternatives, sibling tool names and the focus on depth imply when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_stock_snapshotStock SnapshotARead-onlyIdempotent
Get a comprehensive stock snapshot including real-time price, valuation metrics, DCF analysis, and analyst ratings for any publicly traded company. Returns curated, agent-ready data synthesized from multiple sources in a single call — includes derived signals like dcf_signal (UNDERVALUED/FAIRLY VALUED/OVERVALUED), human-readable market cap, and 52-week range distance. Use this when you need a quick overview of a stock before digging into financials.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock ticker symbol (e.g., AAPL, MSFT, TSLA) |
Output Schema
| Name | Required | Description |
|---|---|---|
| symbol | Yes | |
| company_name | Yes | |
| sector | Yes | |
| industry | Yes | |
| exchange | Yes | |
| price | Yes | |
| valuation | Yes | |
| rating | Yes | |
| fundamentals_summary | Yes | |
| meta | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds behavioral context by explaining the tool synthesizes data from multiple sources, returns derived signals (dcf_signal), and provides curated agent-ready data. This adds value beyond the annotations.
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 concise, consisting of three focused sentences. The first sentence states the main purpose, the second lists key output components, and the third provides usage guidance. No redundant or irrelevant information.
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 simplicity (one parameter), presence of output schema, and rich annotations, the description sufficiently covers the tool's functionality, output highlights, and usage context. It explains derived signals and the nature of the data, making it complete for an agent to understand and invoke correctly.
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 input schema has 100% description coverage for the single required parameter 'symbol' (ticker). The description does not add additional semantic information about the parameter beyond what the schema already provides. With full schema coverage, a baseline score of 3 is appropriate.
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 a comprehensive stock snapshot including real-time price, valuation metrics, DCF analysis, and analyst ratings. It distinguishes from siblings by noting it is a quick overview before diving into financials, differentiating from get_company_metrics and compare_companies.
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 explicitly says 'Use this when you need a quick overview of a stock before digging into financials,' providing clear context for when to use the tool. It implies but does not explicitly state when not to use it or mention alternatives beyond the sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.2.9- Removed
screen_stocks
2 tool updates
v1.1.0- Added
compare_companies - Added
screen_stocks
2 tool updates
v1.0.0- First observed
get_company_metrics - First observed
get_stock_snapshot
TDQS
Scored across 3 tools
The three tools are largely distinct: snapshot gives a quick overview, company_metrics provides deep financials, and compare_companies does side-by-side analysis. However, get_stock_snapshot and get_company_metrics both include valuation and financial data, so an agent could occasionally hesitate on which to call first.
All tool names follow a clear verb_noun pattern: get_stock_snapshot, get_company_metrics, compare_companies. The verb changes appropriately for the action, and there is no mixing of styles or vague naming.
Three tools is on the lean side but fits a focused stock-analysis server: overview, deep dive, and comparison. Each tool earns its place and the count feels sufficient rather than bloated.
The surface covers the core workflow: quick overview, fundamental analysis, and comparative screening. Minor gaps exist (e.g., no historical price data or explicit ticker search), but agents can accomplish most typical investment-analysis tasks without dead ends.
Maintenance
Related MCP Connectors
SEC filings and financial data for AI agents: 59 tools for statements, valuation and supply chains.
Real SEC, 13F, insider, congress & macro data your AI agent can cite. Hosted MCP, 24 tools.
13-model stock valuation engine for AI agents - fair values for 5,900+ US stocks, updated daily.
Realtime financial context for AI agents: what changed, who is affected, and what to watch next. One suite covering news, events, guidance, filing changes, sentiment, stakeholders, and alerts. Information-efficient responses with evidence for every result. First-class point-in-time safety for backtests. Pairs well with web search and a market-data API. All data is our own.
Related MCP Servers
- AlicenseAqualityCmaintenanceFinancial intelligence for AI agents. 31 tools across 8 data sources — regime, derivatives, stablecoin flows, momentum, volatility, macro, DeFi, weather patterns, political cycles, seasonality. The context layer between your agent and a bad trade.315 npm9MIT
- AlicenseAqualityAmaintenancePre-computed financial market intelligence for AI agents. Stocks, crypto, and ETFs.9138 npm5MIT
- AlicenseAqualityDmaintenanceProvides actionable financial intelligence tools for AI agents including insider buying signals, earnings IV plays, market pulse, stock analysis, and options strategies via free public data sources.6MIT
- FlicenseAqualityDmaintenanceProvides AI assistants with real-time stock prices, financial statements, SEC filings, and analytical tools like DCF valuation and ratio analysis.14-