スタートアップの財務健全性を分析し、指標レポートをローカルで生成するためのMCP (Model Context Protocol) サーバーです。
🔒 プライバシーとセキュリティを最優先:
クラウドリスクゼロ: このツールは、お使いのPCやサーバー上で100%ローカルに動作します。
外部へのデータ送信なし: 財務データは、いかなる外部API、クラウドプロバイダー、サードパーティサービス（SlickBooksを含む）にも一切送信されません。
データ保存なし: サーバーは入力をメモリ内で処理し、指標をMCPクライアントに直接返します。データが保存、キャッシュ、ログ記録されることはありません。
厳格な読み取り専用: このサーバーは財務状態を変更する操作を一切行いません。厳格な読み取り専用の数学的エンジンです。
完全ローカル処理: Claude Desktop、Cursor、Glama、その他のMCPクライアントと安全に統合し、機密性の高い財務入力データに対する完全なデータ主権を維持します。
スタートアップの創業者が資金調達や取締役会に向けて準備をする際、投資家からMRR、バーンレート、粗利益、LTV:CAC、ランウェイなどの指標を急に求められることがよくあります。多くの創業者は、これらを一貫して追跡できていないか、資金調達のたびに銀行明細やスプレッドシートから数値を抽出するのに何時間も費やしています。
このツールを使えば、生の銀行明細（またはStripe/QBOのエクスポートデータ）を、数分で構造化された財務指標レポートに変換できます。すべて自分のPC上で完結し、最初の分析に会計士は不要です。機密データがPCから流出することもありません。
Related MCP server: plaid-mcp
データの取り込み: 銀行のCSV、StripeのエクスポートCSV、QBO/XeroのエクスポートCSV、または貼り付けられた値を受け入れます。(最良の結果を得るには、最低3ヶ月分の銀行明細とアクティブユーザー統計を提供してください。サンプルファイルは test/ フォルダにあります)。
AIによる取引分類: AIが説明文に基づいて各銀行取引を収益、売上原価 (COGS)、販売費・一般管理費 (S&M)、給与、または一般管理費 (G&A) に分類します。このステップはAI駆動であり、誤りが発生する可能性があります — 例えば、請負業者への支払いを給与とCOGSのどちらに分類するかを間違えたり、曖昧な項目を見落としたりすることがあります。投資家と結果を共有する前に、必ず分類を確認してください。
主要指標の計算: ネットバーン、ランウェイ、粗利益、CAC、LTV、Rule of 40などを計算し、単一または複数の月を比較レポートとして出力します。
厳格な検証: 値を捏造する代わりに、missing_inputs を含む insufficient_data を返します。データが不足している、または曖昧な場合、エンジンは推測するのではなく、何が必要かを伝えます。
レポート生成: クリーンでフォーマットされたMarkdownおよびHTMLレポートを作成します。提供されたすべての月を網羅した統合レポートを、期間ごとの比較付きで生成します。
mcp-name: io.github.MayankTalwar0/startup-finance-metrics
このツールは財務データを保護するために完全にローカルで動作するため、一度だけ手動セットアップが必要です。
朗報: Pythonをインストールする必要はありません！以下で使用するツール (uv) が、必要なものをすべてバックグラウンドで自動的にダウンロードします。
ステップ1: uv のインストール
このサーバーはローカルで実行するために uv (高速なPythonマネージャー) を使用します。インストールされていない場合:
Mac/Linux: ターミナルを開き、以下を実行してください: curl -LsSf https://astral.sh/uv/install.sh | sh
Windows: PowerShellを開き、以下を実行してください: powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
ステップ2: Claudeの設定を開く
Claude Desktopアプリを開きます。
左上のメニューで Claude -> Settings (またはPreferences) をクリックします。
左側のサイドバーにある Developer タブをクリックします。
Edit Config ボタンをクリックします。デフォルトのテキストエディタで claude_desktop_config.json というファイルが開きます。
ステップ3: サーバーの追加
そのファイルの内容を以下のコードに置き換えてください（すでに他のサーバーがある場合は、既存の mcpServers ブロック内に startup-finance-metrics ブロックを追加してください）:
{
"mcpServers": {
"startup-finance-metrics": {
"command": "uvx",
"args": [
"startup-finance-mcp"
]
}
}
}ステップ4: Claudeの再起動 ファイルを保存して閉じ、Claude Desktopを完全に再起動します。Claudeのチャット画面に新しい「ハンマー」(ツール) アイコンが表示されます！
Claude CodeのようなCLIエージェントや、GlamaやCursorを手動で設定したい場合は、uvx コマンドを使用してください:
Claude Codeの場合:
claude mcp add startup-finance -- uvx startup-finance-mcpGlama / Cursor (カスタムMCP設定) の場合:
uvx startup-finance-mcpgit clone https://github.com/MayankTalwar0/startup-finance-metrics.git
cd startup-finance-metrics
pip install -e .
# Run the server directly
startup-finance-mcpこのサーバーは、MCPクライアントに対して以下のツールを提供します:
computeFinancialMetrics(inputs_json: str): 構造化された入力からスタートアップの財務指標（ランウェイ、粗利益、CAC、LTVなど）を計算します。複数月のデータを分析する場合、月ごとに呼び出されます。
generateFinancialReport(metrics_json: str, output_dir: str): 統合されたHTML + Markdownレポートをレンダリングします。単月のペイロードまたは複数月の {"months": [...]} ペイロードを受け入れ、提供されたすべての期間にわたる比較レポートを生成します。
フルMCPサーバーを使用せず、Claude CodeやOpenClawなどのツールで単純なプロンプトとして使用したい場合は、skills/SKILL.md にある生のスキルプロンプトを参照してください。
# | 指標 | 計算式 | 必要な入力 |
1 | ネットバーン |
|
|
2 | ランウェイ |
|
|
3 | 粗利益 |
|
|
4 | CAC |
|
|
5 | LTV |
|
|
6 | LTV:CAC |
| 計算可能な |
7 | 収益成長率 |
|
|
8 | ロゴチャーン率 |
|
|
9 | バーンマルチプル |
|
|
10 | NRR |
|
|
11 | Rule of 40 |
|
|
12 | CAC回収期間 |
| 計算可能な |
MIT
SlickBooks の創業者であるMayankによって開発されました。 SlickBooksは、管理会計、会計自動化、財務予測自動化、およびカスタム財務エージェントを提供しています。
Computes startup financial metrics from structured data.
Args: inputs_json: A JSON string containing financial inputs. Preferred: pre-categorized values like 'monthly_revenue', 'monthly_opex', 'cogs', 'sales_marketing_spend', 'business_type', etc. Also accepts a raw 'bank_csv' blob as fallback (basic totals only). Returns: JSON string containing computed metrics and missing inputs diagnostics.
| Name | Required | Description | Default |
|---|---|---|---|
| inputs_json | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return format and fallback behavior. No annotations, so description covers safety. Lacks details on side effects, but tool is purely computational.
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?
Concise with clear Args/Returns sections. 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?
Covers inputs, outputs (including diagnostics), and usage patterns. Output schema exists, so return values are described appropriately.
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?
Adds extensive meaning beyond schema: explains JSON structure, lists sample keys, and distinguishes preferred vs fallback formats. Compensates for 0% schema coverage.
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?
Clearly states it computes startup financial metrics from structured data. Distinct from sibling generateFinancialReport which likely generates reports.
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?
Provides guidance on preferred input formats (pre-categorized vs bank_csv fallback) but does not explicitly contrast with sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a single unified HTML + Markdown financial report and saves them to disk.
Args:
metrics_json: JSON string. Two accepted shapes:
1. Single-month: the direct output from computeFinancialMetrics.
2. Multi-month (preferred when user supplies multiple months of data):
{
"source": "...",
"business_type": "saas",
"industry_confidence": "high|medium|low",
"industry_reasoning": "Why this industry was chosen, or why uncertain.",
"period_label": "March 2026 – May 2026",
"months": [
{"period": "March 2026", ...computeFinancialMetrics output for March},
{"period": "April 2026", ...computeFinancialMetrics output for April},
{"period": "May 2026", ...computeFinancialMetrics output for May}
]
}
Always produce ONE unified report covering all months the user supplied.
Do NOT generate one report per month.
output_dir: Directory to save reports to. Default is current directory.
Returns:
JSON with paths to both report files and the markdown content inline.
| Name | Required | Description | Default |
|---|---|---|---|
| metrics_json | Yes | ||
| output_dir | No | . |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that reports are saved to disk and returns paths with inline content. However, it doesn't mention what happens if the output directory doesn't exist or if overwrite behavior, slightly reducing completeness.
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?
Well-structured with clear sections (main action, args, returns). However, the description is somewhat lengthy and could be more concise by moving some parameter details into the schema description. Still, the front-loaded summary of the main purpose is effective.
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 and the presence of an output schema (signaled), the description covers all necessary aspects: what it does, input format, output format, and usage constraints. No critical information is missing for an AI agent to use it 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?
With 0% schema description coverage, the description fully compensates by explaining the `metrics_json` parameter in great detail, including two accepted shapes and references to `computeFinancialMetrics`. It also clarifies the `output_dir` default. Adds significant meaning beyond the schema.
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 generates a unified HTML + Markdown financial report and saves to disk. It distinguishes itself from the sibling tool 'computeFinancialMetrics' by describing the input as its output, and emphasizes producing one report covering all months.
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?
Provides explicit guidance on when to use: after `computeFinancialMetrics`. It explains the two accepted input shapes (single-month vs multi-month) and explicitly warns against generating one report per month, which gives clear usage 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.
v1.1.2computeFinancialMetricsgenerateFinancialReportScored across 2 tools
The two tools have clearly distinct purposes: one computes financial metrics from input data, the other generates a report from those metrics. No overlap or ambiguity.
Both tool names follow a consistent verb_noun pattern using camelCase: computeFinancialMetrics and generateFinancialReport. No mixing of conventions.
With only 2 tools, the server is minimally scoped. While the tools cover the core workflow, the count is at the lower boundary of what is reasonable for a finance metrics domain.
The tools cover computing metrics and generating reports, but lack operations for data input management, historical tracking, or comparisons. Some notable gaps exist.
MCP server for VC pitch-deck scoring, thesis-fit matching, and deal-flow management.
Hosted MCP server for AWS cloud spend: service breakdowns, anomalies, savings and forecasts.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
MCP server for the Seline Analytics API
