一个用于分析初创公司财务健康状况并本地生成指标报告的 MCP (Model Context Protocol) 服务器。
🔒 隐私与安全至上：
零云风险：此工具 100% 在您的机器/服务器上本地运行。
无外部数据传输：财务数据绝不会发送到任何外部 API、云服务提供商或第三方服务（包括 SlickBooks）。
无数据存储：服务器在内存中处理输入，并将指标直接返回给 MCP 客户端。不会存储、缓存或记录任何数据。
严格只读：此服务器不执行任何财务状态更改。它是一个严格的只读数学引擎。
严格本地处理：在与 Claude Desktop、Cursor、Glama 和其他 MCP 客户端安全集成的同时，保持对敏感财务输入数据的完全主权。
如果您是一位正在筹集资金或准备董事会会议的初创公司创始人，投资者通常会突然要求您提供 MRR（月经常性收入）、烧钱率、毛利率、LTV:CAC（客户终身价值与获客成本比）和跑道（Runway）等指标。大多数创始人要么没有持续跟踪这些数据，要么在每次融资前都要花费数小时从银行对账单和电子表格中提取数字。
此工具可以在几分钟内将您的原始银行对账单（或 Stripe/QBO 导出文件）转换为结构化的财务指标报告，且完全在您自己的机器上完成。无需会计师进行初步筛选。没有敏感数据离开您的计算机。
Related MCP server: plaid-mcp
摄取数据：接受银行 CSV、Stripe 导出 CSV、QBO/Xero 导出 CSV 或粘贴的值。(为获得最佳效果，请提供至少 3 个月的银行对账单和活跃用户统计数据。示例文件可在 test/ 文件夹中找到)。
AI 交易分类：AI 会根据描述将每笔银行交易分类为收入、COGS（销售成本）、S&M（销售与营销）、工资或 G&A（一般及行政费用）。此步骤由 AI 驱动，可能会出错 —— 例如，将承包商付款错误地归类为工资而非 COGS，或遗漏模糊的明细项。在与投资者分享结果之前，请务必审查分类。
计算关键指标：计算净烧钱率、跑道、毛利率、CAC、LTV、40 法则等 —— 在一份比较报告中涵盖一个月或多个月的数据。
严格验证：返回 insufficient_data 和 missing_inputs 而不是虚构数值。如果数据缺失或模糊，引擎会告诉您需要什么，而不是进行猜测。
生成报告：创建整洁、格式化的 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 步：添加服务器
将该文件的内容替换为以下代码（如果您已经有其他服务器，只需将 startup-finance-metrics 块添加到现有的 mcpServers 中即可）：
{
"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-mcp对于 Glama / 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 | 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
