エージェント対応型金融インテリジェンスツール — 生データではなく、厳選されたデータを提供。
Toolstemは、生の金融市場データをAIエージェント向けの厳選・統合されたインテリジェンスに変換するMCP（Model Context Protocol）サーバーです。単にベンダーのREST APIを公開するだけのパススルーラッパーとは異なり、Toolstemの各ツールは複数のデータソースを統合し、シグナルを導出し、エージェントが本来自分で行うべき計算を事前に行います。
1回の呼び出し。エージェントにとって扱いやすい1つのJSONレスポンス。解析すべきネストされた配列や、エンドポイント間の複雑な連携、nullチェックのボイラープレートコードは不要です。
ほとんどの金融MCPサーバーはAPIエンドポイントごとに1つのツールを公開しているため、エージェントは4〜5回の逐次呼び出しを行い、グルーコードを書き、生のデータ構造を解釈する必要があります。Toolstemは異なるアプローチで構築されています：
並列データ取得 — すべてのツールが複数のソースに対して同時にリクエストを送信します。
導出シグナル — 生の数値から計算された UNDERVALUED、STRONG、ACCELERATING といった人間が読み取れる推奨事項を提供します。
事前計算された数学的指標 — CAGR、YoY成長率、利益率の傾向、52週高値/安値からの乖離、FCF利回りなどがレスポンスに既に含まれています。
フラットで予測可能なスキーマ — ベンダー特有の深いネスト構造がエージェントのプロンプトに漏れ出すことはありません。
グレースフル・デグラデーション — 上流のエンドポイントのいずれかが失敗しても、残りのレスポンスはnullを埋めた状態で正常に返されます。
Related MCP server: TickerAPI
get_stock_snapshot株価、プロファイル、DCF評価、格付けを1つのレスポンスにまとめた包括的な株式概要。
入力:
{
"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収益性、財務健全性、キャッシュフロー、成長性、および1株あたりの指標など、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 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_config.json に追加:
{
"mcpServers": {
"toolstem": {
"command": "npx",
"args": ["-y", "toolstem-mcp-server"],
"env": {
"FMP_API_KEY": "your_fmp_api_key"
}
}
}
}ToolstemはSmitheryで配布されており、サポートされているMCPクライアントにワンクリックでインストールできます。
Apifyストアで toolstem-financial-data アクターとして利用可能です。Apifyワークフローから以下の入力で呼び出してください:
{
"tool": "get_stock_snapshot",
"symbol": "AAPL"
}or
{
"tool": "get_company_metrics",
"symbol": "AAPL",
"period": "annual"
}結果はデフォルトのデータセットにプッシュされます。このアクターは、ApifyのPay-Per-Eventモデルを通じてツール呼び出しごとに課金されます。
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 serversrc/
├── 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 を介して複数のクライアントメソッドを並列に呼び出し、統合された結果を合成します。
MIT — LICENSE を参照してください。
Toolstem — エージェントネイティブ経済のための厳選された金融インテリジェンス。
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"]) |
| Name | Required | Description |
|---|---|---|
| symbols_compared | Yes | |
| comparison_date | Yes | |
| companies | Yes | |
| rankings | Yes | |
| meta | Yes |
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.
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 |
| 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 |
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 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) |
| 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 |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.2.9screen_stocksv1.1.0compare_companiesscreen_stocksv1.0.0get_company_metricsget_stock_snapshotThe two tools have clearly distinct purposes: get_company_metrics focuses on deep financial analysis and fundamental metrics, while get_stock_snapshot provides a comprehensive stock overview including real-time price and valuation. There is no overlap in functionality, making it easy for an agent to choose the right tool based on the task.
Both tools follow a consistent verb_noun naming pattern (get_company_metrics and get_stock_snapshot), using the same verb 'get' and descriptive nouns. This uniformity makes the tool set predictable and easy to understand.
With only two tools, the server feels under-scoped for financial analysis, as it lacks essential operations like searching for companies, comparing metrics, or updating data. While the tools are well-defined, the count is too low to cover a comprehensive financial domain effectively.
The tool set is severely incomplete for financial analysis, missing critical operations such as listing companies, retrieving historical data, or performing comparisons. Agents will face dead ends when trying to conduct thorough analysis beyond the two provided snapshots.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
SEC filings and financial data for AI agents: 55 tools for financials, valuation and supply chains.
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.
13-model stock valuation engine for AI agents - fair values for 5,900+ US stocks, updated daily.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/toolstem/toolstem-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
