startup-finance-metrics
Métricas Financieras para Startups (Servidor MCP)
Un servidor MCP (Model Context Protocol) para analizar la salud financiera de startups y generar informes de métricas localmente.
🔒 PRIVACIDAD Y SEGURIDAD ANTE TODO:
Cero riesgo en la nube: Esta herramienta se ejecuta al 100% localmente en tu máquina/servidor.
No se envían datos al exterior: Los datos financieros NUNCA se envían a ninguna API externa, proveedor de nube o servicio de terceros (incluyendo SlickBooks).
Sin almacenamiento de datos: El servidor procesa las entradas en memoria y devuelve las métricas directamente al cliente MCP. No se almacenan, almacenan en caché ni registran datos.
Estrictamente de solo lectura: Este servidor NO ejecuta cambios en el estado financiero. Es un motor matemático estrictamente de solo lectura.
Procesamiento estrictamente local: Se integra de forma segura con Claude Desktop, Cursor, Glama y otros clientes MCP mientras mantiene la soberanía total de los datos sobre tus entradas financieras confidenciales.
Por qué existe esto
Si eres el fundador de una startup que está recaudando fondos o preparándose para una reunión de la junta directiva, los inversores te pedirán métricas como MRR, tasa de consumo (burn rate), margen bruto, LTV:CAC y pista de aterrizaje (runway), a menudo con poca antelación. La mayoría de los fundadores no realizan un seguimiento constante de estos datos o pasan horas extrayendo números de extractos bancarios y hojas de cálculo antes de cada ronda de financiación.
Esta herramienta convierte tu extracto bancario sin procesar (o exportación de Stripe/QBO) en un informe de métricas financieras estructurado en minutos, completamente en tu propia máquina. No se requiere un contable para una primera revisión. Ningún dato confidencial sale de tu ordenador.
Related MCP server: plaid-mcp
Qué hace
Ingesta de datos: Acepta CSV bancarios, CSV de exportación de Stripe, CSV de exportación de QBO/Xero o valores pegados. (Para obtener mejores resultados, proporciona un extracto bancario de al menos 3 meses y estadísticas de usuarios activos. Los archivos de muestra están disponibles en la carpeta
test/).Categorización de transacciones por IA: La IA clasifica cada transacción bancaria en ingresos, COGS, S&M, nómina o G&A según la descripción. Este paso está impulsado por IA y puede cometer errores, por ejemplo, clasificar erróneamente un pago a un contratista como nómina en lugar de COGS, o pasar por alto una partida ambigua. Revisa siempre las categorizaciones antes de compartir los resultados con los inversores.
Calcula métricas clave: Calcula el consumo neto (Net Burn), la pista de aterrizaje (Runway), el margen bruto, el CAC, el LTV, la Regla del 40 y más, a lo largo de uno o varios meses en un único informe comparativo.
Validación estricta: Devuelve
insufficient_dataconmissing_inputsen lugar de alucinar valores. Si los datos faltan o son ambiguos, el motor te indica qué se necesita en lugar de adivinar.Genera informes: Crea informes limpios y formateados en Markdown y HTML: un informe unificado que cubre todos los meses proporcionados, con una comparación lado a lado de los periodos.
mcp-name: io.github.MayankTalwar0/startup-finance-metrics
Configuración e instalación
Opción 1: Claude Desktop (Instalación manual para no desarrolladores)
Dado que esta herramienta se ejecuta completamente en tu propia máquina para proteger tus datos financieros, requiere una configuración manual única.
Buenas noticias: ¡NO necesitas tener Python instalado! La herramienta que usamos a continuación (uv) descargará automáticamente todo lo que necesita de forma invisible en segundo plano.
Paso 1: Instalar uv
Este servidor utiliza uv (un gestor de Python rápido) para ejecutarse localmente. Si no lo tienes instalado:
Mac/Linux: Abre tu terminal y ejecuta:
curl -LsSf https://astral.sh/uv/install.sh | shWindows: Abre PowerShell y ejecuta:
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
Paso 2: Abrir la configuración de Claude
Abre la aplicación Claude Desktop.
En el menú superior izquierdo, haz clic en Claude -> Settings (o Preferences).
Haz clic en la pestaña Developer en la barra lateral izquierda.
Haz clic en el botón Edit Config. Esto abrirá un archivo llamado
claude_desktop_config.jsonen tu editor de texto predeterminado.
Paso 3: Añadir el servidor
Reemplaza el contenido de ese archivo con el siguiente código (si ya tienes otros servidores, simplemente añade el bloque startup-finance-metrics dentro de tus mcpServers existentes):
{
"mcpServers": {
"startup-finance-metrics": {
"command": "uvx",
"args": [
"startup-finance-mcp"
]
}
}
}Paso 4: Reiniciar Claude Guarda el archivo, ciérralo y reinicia completamente Claude Desktop. ¡Ahora verás un nuevo icono de "martillo" (Herramientas) en tus chats de Claude!
Opción 2: Configuración de Claude Code, Glama o Cursor personalizado
Para agentes de CLI como Claude Code, o si prefieres configurar manualmente Glama y Cursor, utiliza el comando uvx:
Para Claude Code:
claude mcp add startup-finance -- uvx startup-finance-mcpPara Glama / Cursor (configuración MCP personalizada):
uvx startup-finance-mcpOpción 3: Desarrollo local
git clone https://github.com/MayankTalwar0/startup-finance-metrics.git
cd startup-finance-metrics
pip install -e .
# Run the server directly
startup-finance-mcpHerramientas MCP disponibles
Este servidor proporciona las siguientes herramientas al cliente MCP:
computeFinancialMetrics(inputs_json: str): Calcula las métricas financieras de la startup (pista de aterrizaje, margen bruto, CAC, LTV, etc.) a partir de entradas estructuradas. Se llama una vez por mes al analizar datos de varios meses.generateFinancialReport(metrics_json: str, output_dir: str): Genera un informe unificado en HTML + Markdown. Acepta una carga útil de un solo mes o una carga útil de varios meses{"months": [...]}: produciendo un informe comparativo en todos los periodos suministrados.
Uso como habilidad de IA independiente
Si no quieres usar el servidor MCP completo y solo quieres un prompt simple para usar en herramientas como Claude Code u OpenClaw, puedes encontrar el prompt de habilidad sin procesar en skills/SKILL.md.
Referencia de métricas
# | Métrica | Fórmula | Entradas requeridas |
1 | Consumo neto (Net Burn) |
|
|
2 | Pista de aterrizaje (Runway) |
|
|
3 | Margen bruto |
|
|
4 | CAC |
|
|
5 | LTV |
|
|
6 | LTV:CAC |
|
|
7 | Crecimiento de ingresos |
|
|
8 | Tasa de abandono (Logo Churn) |
|
|
9 | Múltiplo de consumo (Burn Multiple) |
|
|
10 | NRR |
|
|
11 | Regla del 40 |
|
|
12 | Recuperación de CAC |
|
|
Licencia
MIT
Creado por SlickBooks
Creado por Mayank, fundador de SlickBooks. SlickBooks ofrece contabilidad gestionada, automatización de contabilidad, automatización de previsiones financieras y agentes financieros personalizados.
Available Tools
2 toolscomputeFinancialMetricsA
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
generateFinancialReportA
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 | . |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v1.1.2- First observed
computeFinancialMetrics - First observed
generateFinancialReport
TDQS
Scored 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.
Maintenance
Related MCP Connectors
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
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceAn MCP server that reads startup pitch drafts from Notion to provide comprehensive investor-style analysis and scoring. It evaluates key areas like market opportunity and team strength, delivering feedback through a visual dashboard.-
- AlicenseAqualityDmaintenanceA read-only MCP server that enables users to analyze their real bank, credit card, loan, and brokerage data through Plaid. It provides financial analysis tools for transactions, balances, investments, liabilities, and debt while keeping all access tokens and data locally stored.24MIT
- AlicenseNot gradedqualityBmaintenanceMCP server for analyzing SEC filings (10-K, 10-Q, 8-K) with industry-aware financial extraction and BERT-based NLP.1MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server that provides deterministic finance tools for SEC filing analysis, enabling LLMs to compute financial ratios, fetch filings, and perform equity research without hallucinated numbers.MIT