Ein MCP-Server (Model Context Protocol) zur Analyse der finanziellen Gesundheit von Startups und zur lokalen Erstellung von Kennzahlenberichten.
🔒 DATENSCHUTZ & SICHERHEIT AN ERSTER STELLE:
Kein Cloud-Risiko: Dieses Tool läuft zu 100 % lokal auf Ihrem Rechner/Server.
Keine externen Datenübertragungen: Finanzdaten werden NIEMALS an externe APIs, Cloud-Anbieter oder Drittanbieter (einschließlich SlickBooks) gesendet.
Keine Datenspeicherung: Der Server verarbeitet Eingaben im Arbeitsspeicher und gibt die Kennzahlen direkt an den MCP-Client zurück. Es werden keine Daten gespeichert, zwischengespeichert oder protokolliert.
Streng schreibgeschützt: Dieser Server führt KEINE Änderungen am Finanzstatus durch. Es handelt sich um eine rein lesende mathematische Engine.
Streng lokale Verarbeitung: Lässt sich sicher in Claude Desktop, Cursor, Glama und andere MCP-Clients integrieren, während die volle Datenhoheit über Ihre sensiblen Finanzdaten gewahrt bleibt.
Wenn Sie als Startup-Gründer Kapital aufnehmen oder sich auf eine Vorstandssitzung vorbereiten, werden Investoren Sie oft kurzfristig nach Kennzahlen wie MRR, Burn Rate, Bruttomarge, LTV:CAC und Runway fragen. Die meisten Gründer verfolgen diese entweder nicht konsistent oder verbringen Stunden damit, Zahlen aus Kontoauszügen und Tabellenkalkulationen zusammenzusuchen, bevor sie eine Finanzierungsrunde starten.
Dieses Tool verwandelt Ihren rohen Kontoauszug (oder Stripe/QBO-Export) in wenigen Minuten in einen strukturierten Finanzbericht – komplett auf Ihrem eigenen Rechner. Kein Buchhalter für einen ersten Entwurf erforderlich. Keine sensiblen Daten verlassen Ihren Computer.
Related MCP server: plaid-mcp
Datenaufnahme: Akzeptiert Bank-CSVs, Stripe-Export-CSVs, QBO/Xero-Export-CSVs oder eingefügte Werte. (Für beste Ergebnisse stellen Sie mindestens einen 3-monatigen Kontoauszug und aktive Nutzerstatistiken bereit. Beispieldateien finden Sie im Ordner test/).
KI-Transaktionskategorisierung: Die KI klassifiziert jede Banktransaktion basierend auf der Beschreibung in Umsatz, COGS, S&M, Gehaltsabrechnung oder G&A. Dieser Schritt ist KI-gesteuert und kann Fehler machen – z. B. eine Auftragnehmerzahlung fälschlicherweise als Gehaltsabrechnung statt als COGS klassifizieren oder einen mehrdeutigen Posten übersehen. Überprüfen Sie die Kategorisierungen immer, bevor Sie Ergebnisse mit Investoren teilen.
Berechnung der wichtigsten Kennzahlen: Berechnet Net Burn, Runway, Bruttomarge, CAC, LTV, Rule of 40 und mehr – über einen oder mehrere Monate in einem einzigen Vergleichsbericht.
Strenge Validierung: Gibt insufficient_data mit missing_inputs zurück, anstatt Werte zu halluzinieren. Wenn Daten fehlen oder mehrdeutig sind, sagt Ihnen die Engine, was benötigt wird, anstatt zu raten.
Berichterstellung: Erstellt saubere, formatierte Markdown- und HTML-Berichte – einen einheitlichen Bericht, der alle bereitgestellten Monate abdeckt, mit einem direkten Periodenvergleich.
mcp-name: io.github.MayankTalwar0/startup-finance-metrics
Da dieses Tool vollständig auf Ihrem eigenen Rechner läuft, um Ihre Finanzdaten zu schützen, ist eine einmalige manuelle Einrichtung erforderlich.
Gute Nachricht: Sie müssen NICHT Python installiert haben! Das Tool, das wir unten verwenden (uv), lädt automatisch alles, was es benötigt, unsichtbar im Hintergrund herunter.
Schritt 1: uv installieren
Dieser Server verwendet uv (einen schnellen Python-Manager), um lokal zu laufen. Falls Sie es noch nicht installiert haben:
Mac/Linux: Öffnen Sie Ihr Terminal und führen Sie aus: curl -LsSf https://astral.sh/uv/install.sh | sh
Windows: Öffnen Sie PowerShell und führen Sie aus: powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
Schritt 2: Claude-Konfiguration öffnen
Öffnen Sie die Claude Desktop App.
Klicken Sie im Menü oben links auf Claude -> Settings (oder Preferences).
Klicken Sie in der linken Seitenleiste auf den Tab Developer.
Klicken Sie auf die Schaltfläche Edit Config. Dies öffnet eine Datei namens claude_desktop_config.json in Ihrem Standard-Texteditor.
Schritt 3: Server hinzufügen
Ersetzen Sie den Inhalt dieser Datei durch den folgenden Code (wenn Sie bereits andere Server haben, fügen Sie einfach den startup-finance-metrics-Block in Ihre bestehenden mcpServers ein):
{
"mcpServers": {
"startup-finance-metrics": {
"command": "uvx",
"args": [
"startup-finance-mcp"
]
}
}
}Schritt 4: Claude neu starten Speichern Sie die Datei, schließen Sie sie und starten Sie Claude Desktop vollständig neu. Sie werden nun ein neues "Hammer"-Symbol (Tools) in Ihren Claude-Chats sehen!
Für CLI-Agenten wie Claude Code oder wenn Sie Glama und Cursor manuell konfigurieren möchten, verwenden Sie den uvx-Befehl:
Für Claude Code:
claude mcp add startup-finance -- uvx startup-finance-mcpFür Glama / Cursor (benutzerdefinierte MCP-Konfiguration):
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-mcpDieser Server stellt dem MCP-Client die folgenden Tools zur Verfügung:
computeFinancialMetrics(inputs_json: str): Berechnet Startup-Finanzkennzahlen (Runway, Bruttomarge, CAC, LTV usw.) aus strukturierten Eingaben. Wird einmal pro Monat aufgerufen, wenn Daten über mehrere Monate analysiert werden.
generateFinancialReport(metrics_json: str, output_dir: str): Erstellt einen einheitlichen HTML- + Markdown-Bericht. Akzeptiert entweder eine Ein-Monats-Payload oder eine Mehr-Monats-Payload {"months": [...]} – und erstellt einen Vergleichsbericht über alle bereitgestellten Zeiträume.
Wenn Sie nicht den vollständigen MCP-Server verwenden möchten und nur einen einfachen Prompt für Tools wie Claude Code oder OpenClaw suchen, finden Sie den rohen Skill-Prompt in skills/SKILL.md.
# | Kennzahl | Formel | Erforderliche Eingaben |
1 | Net Burn |
|
|
2 | Runway |
|
|
3 | Bruttomarge |
|
|
4 | CAC |
|
|
5 | LTV |
|
|
6 | LTV:CAC |
| Berechenbar |
7 | Umsatzwachstum |
|
|
8 | Logo Churn |
|
|
9 | Burn Multiple |
|
|
10 | NRR |
|
|
11 | Rule of 40 |
|
|
12 | CAC Payback |
| Berechenbar |
MIT
Erstellt von Mayank, Gründer von SlickBooks. SlickBooks bietet verwaltete Buchhaltung, Buchhaltungsautomatisierung, Automatisierung von Finanzprognosen und maßgeschneiderte Finanzagenten.
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
