MCP-сервер (Model Context Protocol) для анализа финансового состояния стартапа и локального создания отчетов с метриками.
🔒 ПРИОРИТЕТ: КОНФИДЕНЦИАЛЬНОСТЬ И БЕЗОПАСНОСТЬ:
Нулевой риск облачных решений: Этот инструмент работает на 100% локально на вашем компьютере или сервере.
Данные не передаются извне: Финансовые данные НИКОГДА не отправляются сторонним API, облачным провайдерам или сторонним сервисам (включая SlickBooks).
Данные не хранятся: Сервер обрабатывает входные данные в оперативной памяти и возвращает метрики напрямую MCP-клиенту. Данные не сохраняются, не кэшируются и не логируются.
Строго «только для чтения»: Этот сервер НЕ выполняет никаких изменений в финансовом состоянии. Это строго математический движок «только для чтения».
Строго локальная обработка: Безопасная интеграция с Claude Desktop, Cursor, Glama и другими MCP-клиентами при сохранении полного суверенитета над вашими конфиденциальными финансовыми данными.
Если вы основатель стартапа, который привлекает инвестиции или готовится к совету директоров, инвесторы будут запрашивать у вас такие метрики, как MRR, burn rate (скорость сжигания денег), валовая маржа, LTV:CAC и runway (запас хода) — часто в сжатые сроки. Большинство основателей либо не отслеживают их последовательно, либо тратят часы на сбор цифр из банковских выписок и таблиц перед каждым раундом финансирования.
Этот инструмент превращает вашу необработанную банковскую выписку (или экспорт из Stripe/QBO) в структурированный отчет о финансовых метриках за считанные минуты, полностью на вашем компьютере. Для первого анализа бухгалтер не требуется. Никакие конфиденциальные данные не покидают ваш компьютер.
Related MCP server: plaid-mcp
Принимает данные: Поддерживает банковские CSV, экспорт из Stripe, экспорт из QBO/Xero или вставленные значения. (Для достижения наилучших результатов предоставьте банковскую выписку минимум за 3 месяца и статистику активных пользователей. Примеры файлов доступны в папке test/).
ИИ-категоризация транзакций: ИИ классифицирует каждую банковскую транзакцию как выручку, себестоимость (COGS), продажи и маркетинг (S&M), зарплату или общие и административные расходы (G&A) на основе описания. Этот шаг выполняется ИИ и может содержать ошибки — например, неверная классификация оплаты подрядчику как зарплаты вместо себестоимости или пропуск неоднозначной позиции. Всегда проверяйте категории перед тем, как делиться результатами с инвесторами.
Вычисляет ключевые метрики: Рассчитывает чистый burn rate, запас хода (runway), валовую маржу, 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 появится новый значок «молотка» (Tools)!
Для CLI-агентов, таких как Claude Code, или если вы предпочитаете вручную настроить 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 | Чистый Burn |
|
|
2 | Запас хода (Runway) |
|
|
3 | Валовая маржа |
|
|
4 | CAC |
|
|
5 | LTV |
|
|
6 | LTV:CAC |
| Вычисляемые |
7 | Рост выручки |
|
|
8 | Отток клиентов (Logo Churn) |
|
|
9 | Burn Multiple |
|
|
10 | NRR |
|
|
11 | Правило 40 |
|
|
12 | Окупаемость CAC |
| Вычисляемые |
MIT
Создано Маянком, основателем SlickBooks. 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
