An MCP (Model Context Protocol) server for analyzing startup financial health and generating metrics reports locally.
🔒 PRIVACY & SECURITY FIRST:
Zero Cloud Risk: This tool runs 100% locally on your machine/server.
No Data Sent Externally: Financial data is NEVER sent to any external API, cloud provider, or third-party service (including SlickBooks).
No Data Storage: The server processes inputs in-memory and returns the metrics directly to the MCP client. No data is stored, cached, or logged.
Strictly Read-Only: This server executes NO financial state changes. It is a strictly read-only mathematical engine.
Strictly Local Processing: Safely integrates with Claude Desktop, Cursor, Glama, and other MCP clients while maintaining full data sovereignty over your sensitive financial inputs.
If you're a startup founder raising funds or preparing for a board meeting, investors will ask you for metrics like MRR, burn rate, gross margin, LTV:CAC, and runway — often on short notice. Most founders either don't track these consistently, or spend hours pulling numbers from bank statements and spreadsheets before every fundraise.
This tool turns your raw bank statement (or Stripe/QBO export) into a structured financial metrics report in minutes, entirely on your own machine. No accountant required for a first pass. No sensitive data leaving your computer.
Related MCP server: plaid-mcp
Ingests Data: Accepts bank CSVs, Stripe export CSVs, QBO/Xero export CSVs, or pasted values. (For best results, provide a minimum 3-month bank statement and active user stats. Sample files are available in the test/ folder).
AI Transaction Categorization: The AI classifies each bank transaction into revenue, COGS, S&M, payroll, or G&A based on the description. This step is AI-driven and can make mistakes — e.g. misclassifying a contractor payment as payroll vs. COGS, or missing an ambiguous line item. Always review the categorizations before sharing results with investors.
Computes Key Metrics: Calculates Net Burn, Runway, Gross Margin, CAC, LTV, Rule of 40, and more — across one or multiple months in a single comparative report.
Strict Validation: Returns insufficient_data with missing_inputs instead of hallucinating values. If data is missing or ambiguous, the engine tells you what's needed rather than guessing.
Generates Reports: Creates clean, formatted Markdown and HTML reports — one unified report covering all months supplied, with side-by-side period comparison.
mcp-name: io.github.MayankTalwar0/startup-finance-metrics
Since this tool runs entirely on your own machine to protect your financial data, it requires a one-time manual setup.
Good News: You do NOT need to have Python installed! The tool we use below (uv) will automatically download everything it needs invisibly in the background.
Step 1: Install uv
This server uses uv (a fast Python manager) to run locally. If you don't have it installed:
Mac/Linux: Open your Terminal and run: curl -LsSf https://astral.sh/uv/install.sh | sh
Windows: Open PowerShell and run: powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
Step 2: Open Claude's Configuration
Open the Claude Desktop App.
In the top left menu, click Claude -> Settings (or Preferences).
Click on the Developer tab in the left sidebar.
Click the Edit Config button. This will open a file named claude_desktop_config.json in your default text editor.
Step 3: Add the Server
Replace the contents of that file with the following code (if you already have other servers, just add the startup-finance-metrics block inside your existing mcpServers):
{
"mcpServers": {
"startup-finance-metrics": {
"command": "uvx",
"args": [
"startup-finance-mcp"
]
}
}
}Step 4: Restart Claude Save the file, close it, and completely restart Claude Desktop. You will now see a new "hammer" (Tools) icon in your Claude chats!
For CLI agents like Claude Code, or if you prefer to manually configure Glama and Cursor, use the uvx command:
For Claude Code:
claude mcp add startup-finance -- uvx startup-finance-mcpFor Glama / Cursor (Custom MCP config):
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-mcpThis server provides the following tools to the MCP client:
computeFinancialMetrics(inputs_json: str): Computes startup financial metrics (runway, gross margin, CAC, LTV, etc.) from structured inputs. Called once per month when analyzing multi-month data.
generateFinancialReport(metrics_json: str, output_dir: str): Renders a unified HTML + Markdown report. Accepts either a single-month payload or a multi-month {"months": [...]} payload — producing one comparative report across all periods supplied.
If you don't want to use the full MCP server and just want a simple prompt to use in tools like Claude Code or OpenClaw, you can find the raw skill prompt in skills/SKILL.md.
# | Metric | Formula | Required inputs |
1 | Net Burn |
|
|
2 | Runway |
|
|
3 | Gross Margin |
|
|
4 | CAC |
|
|
5 | LTV |
|
|
6 | LTV:CAC |
| Computable |
7 | Revenue Growth |
|
|
8 | Logo Churn |
|
|
9 | Burn Multiple |
|
|
10 | NRR |
|
|
11 | Rule of 40 |
|
|
12 | CAC Payback |
| Computable |
MIT
Built by Mayank, founder of SlickBooks. SlickBooks provides managed bookkeeping, bookkeeping automation, financial forecast automation, and custom finance agents.
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 querying and analyzing data from ad platforms, analytics tools, and spreadsheets
