How do I use finanzas-pyme?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@finanzas-pyme ¿Cuánto gasté en julio?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

finanzas-pyme

by JuanDsm04

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

finanzas-mcp — SME finance assistant (MCP server)

An MCP (Model Context Protocol) server that lets an LLM answer real finance questions for a small business owner with no accountant: what did I spend last month and on what, are my sales growing, and will I have enough money next month?

It runs locally over the stdio transport and speaks JSON-RPC 2.0, so any MCP host — Claude Desktop, VS Code, or a custom chatbot — can use it.

What it does

The server does not just run SELECTs. Each tool applies a documented method and returns a report that states its own assumptions:

Tool	Question it answers	Method
`desglose_gastos`	"How much did I spend in July, and on what?"	Category breakdown with shares, fixed/variable split, comparison against the previous month and the 3-month average
`tendencia_ingresos`	"Are my sales growing or falling?"	Month-over-month, year-over-year, and a least-squares trend reported with its R²
`proyeccion_flujo_caja`	"Will I have enough money next month?"	Income as a damped seasonal trend; fixed costs as level × seasonal index; variable costs as a median share of income
`estado_resultados`	"Did I make or lose money in May?"	Profit-and-loss statement with net margin
`detectar_gastos_atipicos`	"Was there any unusual expense?"	Per-category z-scores against each category's own history
`salud_financiera`	"How is my business doing overall?"	Trailing averages, fixed-cost coverage, payroll weight, loss-making months

Related MCP server: Finance MCP Server

The simulated business

"Panadería La Espiga", a small bakery. Covering 2025-01 to 2026-08 (20 months, 1,088 transactions).

Installation

Requires Python 3.10+. No database server and no API key: the SQLite file is built automatically on first run from the two bundled SQL scripts.

The dependency is pinned to mcp>=1.27,<2. The MCP Python SDK v2 renamed FastMCP to MCPServer and changed several public field names; an unpinned install picks up 2.x and fails at import.

Use it as a dependency

If you only want to use this server, one command is enough — no clone, no database setup, no API key:

pip install git+https://github.com/<your-user>/mcp-finanzas-pyme.git

That installs the package and creates a finanzas-mcp executable in your environment, which is what you point your MCP host at.

Develop on it

git clone https://github.com/<your-user>/mcp-finanzas-pyme.git
cd mcp-finanzas-pyme

python -m venv .venv
source .venv/bin/activate          # Windows: .venv\Scripts\activate

pip install -e .

Verify it starts:

python -m finanzas_mcp.server --help

Connecting it to a host

Any MCP host (generic stdio entry). After installing, either of these works — the console script, or the module, which is handy when you want to be explicit about which interpreter runs it:

{
  "command": "finanzas-mcp",
  "args": []
}

{
  "command": "python",
  "args": ["-m", "finanzas_mcp.server"]
}

No working directory or PYTHONPATH is needed in either case.

If your host does not inherit the active virtual environment — Claude Desktop does not, and some editors do not either — use absolute paths:

{
  "command": "C:\\path\\to\\your\\.venv\\Scripts\\finanzas-mcp.exe",
  "args": []
}

{
  "command": "/absolute/path/to/.venv/bin/python",
  "args": ["-m", "finanzas_mcp.server"]
}

chatbot-redes — install into the same virtual environment as the chatbot, then flip the registry entry to enabled:

pip install -e ../mcp-finanzas-pyme

"finanzas-pyme": {
  "enabled": true,
  "transport": "stdio",
  "description": "Servidor MCP propio: asistente financiero para PYMES",
  "command": "python",
  "args": ["-m", "finanzas_mcp.server"],
  "env": {}
}

Check the connection without spending API credits with python scripts/check_servers.py from the chatbot repo.

Claude Desktop — add to claude_desktop_config.json:

{
  "mcpServers": {
    "finanzas-pyme": {
      "command": "/absolute/path/to/.venv/bin/finanzas-mcp",
      "args": []
    }
  }
}

MCP Inspector — the quickest way to check the server before wiring it into a host:

npx @modelcontextprotocol/inspector finanzas-mcp

Where the database lives

With an editable install the database goes to data/finanzas.db inside the repository. With a regular install the package lives in site-packages, so it lands inside the virtual environment instead. Both work; to choose the location explicitly, pass the flag in args:

{
  "command": "finanzas-mcp",
  "args": ["--db-path", "C:\\Users\\you\\finanzas.db"]
}

Running finanzas-mcp by hand just blocks: it is waiting for JSON-RPC messages on stdin. That is expected — the host is what launches it. Ctrl+C exits.

Usage

Questions a user can ask in plain language, and the tool that answers them:

You ask	The model calls
"¿Cuánto gasté en agosto?"	`desglose_gastos(mes="2026-08")`
"¿En qué se me fue el dinero el mes pasado?"	`desglose_gastos()`
"¿Mis ventas están subiendo o bajando?"	`tendencia_ingresos()`
"¿Gané dinero en marzo?"	`estado_resultados(mes="2026-03")`
"¿Me va a alcanzar el próximo mes? Tengo Q45,000"	`proyeccion_flujo_caja(meses=1, saldo_inicial=45000)`
"¿Hubo algún gasto raro este año?"	`detectar_gastos_atipicos()`
"¿Cómo va mi negocio?"	`salud_financiera()`

Configuration

Variable / flag	Default	Purpose
`FINANZAS_DB_PATH`	`data/finanzas.db`	Where the SQLite file lives
`--db-path PATH`	—	Same, as a flag (takes precedence)
`--rebuild`	off	Delete and rebuild the database before starting

Server specification

Identity and transport

Field	Value
Server name	`finanzas-pyme`
Implementation	`finanzas-mcp` 0.1.0
Protocol	Model Context Protocol over JSON-RPC 2.0
Transport	stdio (the host launches the server as a subprocess)
Launch command	`python -m finanzas_mcp.server`
SDK	MCP Python SDK v1 (`mcp>=1.27,<2`), `FastMCP`

Capabilities advertised at initialize:

{
  "tools":     { "listChanged": false },
  "resources": { "subscribe": false, "listChanged": false },
  "prompts":   { "listChanged": false }
}

The server also returns an instructions string telling the host that amounts are in GTQ, that months use YYYY-MM, and that omitting the month selects the latest month with data. It writes nothing to stdout, since on the stdio transport stdout is the protocol channel; diagnostics go to stderr.

Tools

desglose_gastos — breaks one month's expenses down by category.

Parameter	Type	Default	Description
`mes`	`string \| null`	`null`	Month, `YYYY-MM`. Null = latest month with data.
`incluir_comparacion`	`boolean`	`true`	Add comparison vs previous month and 3-month average.

Returns the total and movement count; the fixed/variable split; a table per category with amount, share, movements and a bar; optionally the comparison block; the top 5 suppliers; the top 5 individual movements. Errors on a malformed month or a month outside the available period.

tendencia_ingresos — analyses whether income is growing or shrinking.

Parameter	Type	Default	Description
`mes`	`string \| null`	`null`	Last month of the window, `YYYY-MM`.
`meses`	`integer`	`6`	Window size, 3 to 24.

Returns the month-over-month change; the year-over-year comparison when 12 months of history exist; the least-squares trend with slope per month, slope as a percentage of the window average, and R² with a reliability label (alta ≥ 0.7, media ≥ 0.4, baja below). When R² < 0.4 it explicitly warns that the slope is indicative, not predictive. Errors when meses is outside 3..24 or there are fewer than 3 months of history.

proyeccion_flujo_caja — projects income, expenses and cash balance.

Parameter	Type	Default	Description
`meses`	`integer`	`1`	Months to project, 1 to 6.
`saldo_inicial`	`number \| null`	`null`	Cash on hand in GTQ. Null = use the accumulated result of the last 6 months as a proxy (stated in the output).
`ventana`	`integer`	`6`	Trailing months used to fit, 3 to 18.

Method, printed in the output so it is auditable:

Income — least squares over the last ventana months, extrapolated, then multiplied by the seasonal index of the target calendar month, damped by 0.5 because the history is short.
Fixed costs — per category as level × seasonal_index, where the level is the mean of the trailing window over a zero-filled series and the index is not damped.
Variable costs — the median share of income they absorbed over the window, applied to projected income.

Returns a table per projected month (income, fixed, variable, net flow, running balance); the composition of the first month's fixed costs; a verdict — SI (covers everything), AJUSTADO (covers fixed but not variable), or NO; the coverage ratio, runway in months, lowest projected balance; and a warning that the projection ignores commitments not present in the data. Errors on meses outside 1..6, ventana outside 3..18, or a negative saldo_inicial.

estado_resultados — profit-and-loss statement for one month.

Parameter	Type	Default	Description
`mes`	`string \| null`	`null`	Month, `YYYY-MM`.

Returns income by category with shares; expenses by category tagged fixed or variable, each as a percentage of income; subtotals; net profit or loss and net margin; the previous month for reference.

detectar_gastos_atipicos — flags months where a category deviates from its own norm.

Parameter	Type	Default	Description
`meses`	`integer`	`12`	Trailing months to inspect, minimum 3.
`umbral_z`	`number`	`2.0`	Minimum absolute z-score to report.

For each expense category with at least four observations in the window, monthly totals are converted to standard scores against that category's own mean and population standard deviation. Returns a table sorted by |z| plus the individual transactions explaining the three largest deviations. When nothing exceeds the threshold it says so and suggests a lower one. Errors on meses < 3 or umbral_z ≤ 0.

salud_financiera — one-screen snapshot. No parameters. Returns the latest closed month and available history; 6-month averages for income, expenses and result; average net margin; average fixed costs and coverage ratio; payroll cost and its weight over income; loss-making months in the last year; the active roster.

Resources

URI	MIME type	Content
`finanzas://esquema`	`text/plain`	The complete DDL (5 tables and the monthly view)
`finanzas://catalogo/categorias`	`text/plain`	`nombre\|tipo\|es_fijo\|descripcion`
`finanzas://meses`	`text/plain`	Months with data, one per line

Prompts

revision_mensual (mes: string, default "" = latest month) renders a reusable instruction that walks the model through a full monthly review: income statement, expense breakdown, income trend, anomaly detection, then three conclusions and one actionable recommendation in plain language.

Data model

categorias(id, nombre, tipo, es_fijo, descripcion)
proveedores(id, nombre, categoria_id -> categorias, dias_credito, activo)
clientes(id, nombre, segmento, fecha_alta, activo)
empleados(id, nombre, puesto, salario_mensual, fecha_ingreso, fecha_salida, activo)
transacciones(id, fecha, tipo, monto, categoria_id -> categorias,
              proveedor_id -> proveedores, cliente_id -> clientes,
              metodo_pago, descripcion)

v_resumen_mensual: monthly totals per category

categorias.tipo and transacciones.tipo are both constrained to 'ingreso' | 'gasto'; categorias.es_fijo is the flag the projection depends on; transacciones.monto must be positive, with direction carried by tipo. Indexes exist on fecha, (tipo, fecha) and (categoria_id, fecha), the three access patterns every tool uses.

The database is built on first use into data/finanzas.db via a temporary file that is renamed on success, so a crash mid-import cannot leave a half-populated database.

Security notes

Every SQL statement is parameterised; no tool interpolates model-provided strings into SQL. The server is read-only — no tool writes to the ledger. The database is local and synthetic: no network access, no credentials, no personal data.

Regenerating the dataset

seed.sql is generated, not hand-written. The generator is deterministic, so re-running it reproduces the same file:

python scripts/generate_seed.py
rm -f data/finanzas.db          # rebuilt automatically on the next run

To change the simulated business, edit the constants at the top of scripts/generate_seed.py: period, categories, suppliers, customers, payroll, seasonality, growth rate and planted anomalies.

Project structure

mcp-finanzas-pyme/
├── src/finanzas_mcp/
│   ├── schema.sql          DDL: 5 tables + 1 view
│   ├── seed.sql            DML: generated, 1,088 transactions
│   ├── db.py               SQLite access; builds the database on first use
│   ├── analytics.py        Trend, seasonality, projection, z-scores
│   ├── formatting.py       Text rendering helpers
│   ├── errors.py           ToolInputError
│   ├── tools/
│   │   ├── gastos_por_categoria.py   desglose_gastos, detectar_gastos_atipicos
│   │   ├── tendencia_ingresos.py     tendencia_ingresos, estado_resultados
│   │   └── proyeccion_flujo.py       proyeccion_flujo_caja, salud_financiera
│   └── server.py           MCP registration + stdio entry point
├── scripts/generate_seed.py
└── docs/ejemplos.md        Worked examples with real output

The layering is deliberate: analytics.py knows nothing about SQL, the tools know nothing about MCP, and server.py is a thin registration wrapper.

References

Available Tools

6 tools

desglose_gastosA

Desglosa los gastos de un mes por categoria (proveedores, nomina, servicios, etc.).

Responde preguntas como "cuanto gaste en julio" o "en que se me fue el dinero el mes pasado". Devuelve el total, el reparto por categoria con porcentajes, la separacion entre gastos fijos y variables, los principales proveedores y los movimientos individuales mas grandes.

Args: mes: Mes a analizar en formato 'YYYY-MM' (ej. '2026-08'). Si se omite, se usa el ultimo mes con datos registrados. incluir_comparacion: Si es True, agrega la comparacion contra el mes anterior y contra el promedio de los tres meses previos.

ParametersJSON Schema

Name	Required	Description	Default
`mes`	No
`incluir_comparacion`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It transparently explains the output (total, categories, fixed/variable, top vendors, largest transactions) and parameter behavior (default for 'mes', effect of 'incluir_comparacion'). It does not mention side effects, but as a read-only analysis tool, none are expected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured: a one-sentence summary, example questions, a list of output components, and parameter explanations. Every sentence adds value, and there is no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema (not shown in detail), the description provides a high-level list of return elements, making it clear what the user will get. It also covers parameter defaults and example use cases, making it complete for a two-parameter read-only tool. No critical information is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides zero descriptions for the two parameters. The description fully compensates by explaining the format and default behavior of 'mes' (YYYY-MM, defaults to last month with data) and the meaning of 'incluir_comparacion' (adds comparison to previous month and 3-month average), covering all parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb ('Desglosa') and resource (expenses by month), and includes example questions that illustrate its use. It is contextually distinct from siblings which focus on anomalies, income trends, and projections.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context by giving example queries ('cuanto gaste en julio') and outlining what the tool returns. However, it does not explicitly mention when to prefer this tool over the sibling tools or state exclusions, so it stops short of a perfect score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

detectar_gastos_atipicosA

Detecta gastos inusuales comparando cada categoria contra su propio historial.

Util para responder "hubo algun gasto raro?" o para explicar por que un mes salio mal. Calcula el z-score de cada categoria por mes y reporta las desviaciones que superan el umbral, junto con el movimiento que las explica.

Args: meses: Cuantos meses hacia atras inspeccionar (minimo 3). umbral_z: Desviaciones estandar minimas para reportar un gasto como atipico. 2.0 es estricto; 1.5 muestra mas casos.

ParametersJSON Schema

Name	Required	Description	Default
`meses`	No
`umbral_z`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of outlining side effects. It implies a read-only analysis (calculates z-scores, reports deviations) but never explicitly states that it does not modify data or access sensitive information. This lack of explicit safety disclosure leaves room for uncertainty.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured, with a brief narrative followed by an 'Args' section that clearly maps parameters to their meanings. It is front-loaded with the core purpose and avoids extraneous details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an analysis tool with two parameters and a clear methodology, the description provides sufficient context to use it correctly. It explains the input (months back, threshold) and the expected behavior (calculate z-scores, report deviations with explanations), even without detailing the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Both parameters are fully explained in the description: 'meses' is defined as how many months to look back (with a minimum of 3) and 'umbral_z' as the standard deviation threshold with practical guidance (2.0 strict, 1.5 more cases). This goes well beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: detecting unusual expenses by comparing each category against its own historical data. It explicitly mentions the z-score method and reporting deviations, which distinguishes it from sibling tools like simple breakdowns or income trends.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides concrete use cases: answering 'hubo algún gasto raro?' and explaining why a month went badly. However, it does not explicitly contrast with alternatives or state when not to use this tool, so some inference is needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

estado_resultadosA

Genera el estado de resultados de un mes: ingresos, gastos, utilidad y margen.

Responde "gane o perdi dinero en mayo?". Muestra los ingresos y gastos desglosados por categoria, separa gastos fijos de variables y calcula la utilidad neta y el margen, con el mes anterior como referencia.

Args: mes: Mes en formato 'YYYY-MM'. Si se omite, se usa el ultimo mes con datos.

ParametersJSON Schema

Name	Required	Description	Default
`mes`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description explains the tool computes and displays various financial metrics, compares with previous month, and suggests it is a read-only reporting tool. No side effects or contradictions are mentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description repeats information about ingresos, gastos, utilidad, and margen across sentences, making it slightly redundant, though it remains understandable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description provides a complete picture of what the tool does, including the input parameter and expected output contents. It lacks explicit output structure, but that is likely defined elsewhere, so it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description fully explains the 'mes' parameter, including its format ('YYYY-MM') and the behavior when omitted (uses last month with data), adding meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates a monthly income statement including revenues, expenses, net profit, and margin, and shows a breakdown by category and fixed vs variable expenses. It also provides an example query, distinguishing it from sibling tools like desglose_gastos or tendencia_ingresos.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an example question ('gane o perdi dinero en mayo?') and explains the tool's functionality, giving an agent a clear scenario for when to use it. It lacks explicit alternative comparisons, but the example and details are sufficient guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

proyeccion_flujo_cajaA

Proyecta si alcanzara el dinero para cubrir los gastos del proximo mes.

Responde "me va a alcanzar el mes que viene?". Proyecta los ingresos con una tendencia corregida por estacionalidad, los gastos fijos categoria por categoria (lo que hace que julio con Bono 14 y diciembre con aguinaldo salgan correctos) y los gastos variables como proporcion de los ingresos. Devuelve el flujo neto, el saldo proyectado y una respuesta directa.

Args: meses: Cuantos meses proyectar hacia adelante, entre 1 y 6. saldo_inicial: Saldo en caja al inicio de la proyeccion, en quetzales. Si se omite se usa el resultado acumulado de los ultimos 6 meses como aproximacion, y se advierte en la respuesta. ventana: Cuantos meses de historial usar para ajustar la tendencia (3 a 18).

ParametersJSON Schema

Name	Required	Description	Default
`meses`	No
`ventana`	No
`saldo_inicial`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, but the description carries the full burden by explaining the methodology: income trend with seasonality correction, fixed expenses category-by-category (including Bono 14 and aguinaldo), variable expenses as a proportion of income, and the fallback behavior for omitted saldo_inicial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is information-dense and well organized: it opens with the purpose, then explains methodology and output, and finishes with a compact parameter list. No redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists and annotations are absent, the description covers the essential context: what the tool calculates, how it calculates it, what it returns, and the meaning and defaults of every parameter. Nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides only names and defaults; the description adds meaningful detail for all three parameters, including units (quetzales), valid ranges (1-6 months for meses, 3-18 for ventana), and the exact fallback behavior when saldo_inicial is omitted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action: projecting whether available cash will cover next month's expenses, and describes the output (net flow, projected balance, direct answer). This clearly distinguishes it from sibling tools like expense breakdown or income trend.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context by framing the tool as answering 'will I have enough next month?', and describes the projection approach. It does not explicitly name sibling alternatives or state when not to use it, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

salud_financieraA

Resumen general del negocio en una sola pantalla.

Util como primera llamada cuando el usuario pregunta algo amplio como "como va mi negocio?". Devuelve promedios de los ultimos 6 meses, margen neto, cobertura de gastos fijos, peso de la nomina, meses con perdida en el ultimo ano y la planilla activa.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It describes what the tool returns but does not explicitly state it is read-only or that it has no side effects. The nature of a summary tool suggests it is safe, but the lack of explicit transparency prevents a higher score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, concise and directly to the point. It front-loads the purpose and gives a clear example of when to use it, with no redundant or extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lists all key outputs the tool provides (averages, net margin, fixed cost coverage, payroll weight, months with loss, active payroll), making it clear what the agent can expect. Given it's a summary tool with no inputs, this is sufficient for an agent to decide to call it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline of 4 applies. There's no additional parameter context needed, and the description doesn't confuse any parameter usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides a general business summary, listing specific metrics (averages, net margin, fixed cost coverage, etc.), and distinguishes it from more detailed sibling tools like expense breakdown or revenue trends.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly mentions being useful as a first call when the user asks a broad question like 'how is my business going?', which gives clear guidance. It doesn't explicitly state when not to use it, but the context of sibling tools implies that for specific breakdowns other tools are appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tendencia_ingresosB

Analiza si los ingresos estan creciendo o bajando, con numeros concretos.

Responde "mis ventas van subiendo o bajando?". Entrega tres niveles de evidencia: la variacion contra el mes anterior, la comparacion interanual (que elimina el efecto de la estacionalidad) y una tendencia ajustada por minimos cuadrados con su R2 para indicar que tan confiable es.

Args: mes: Ultimo mes de la ventana de analisis en formato 'YYYY-MM'. Si se omite, se usa el ultimo mes con datos. meses: Tamano de la ventana de analisis, entre 3 y 24 meses.

ParametersJSON Schema

Name	Required	Description	Default
`mes`	No
`meses`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It does disclose that the tool returns three levels of evidence (month-over-month, year-over-year, and trend with R^2), but it does not state side effects, permissions, read-only nature, or any potential limitations or errors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is reasonably concise and well-structured, starting with the main purpose, then the response content, followed by parameter details. No unnecessary fluff, though it could be slightly tighter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the output content in terms of three evidence levels, which is sufficient given that an output schema exists. It does not describe the exact output format, but that is not required when an output schema is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Both parameters are well explained in the description: 'mes' includes format 'YYYY-MM' and default behavior, and 'meses' includes a range (3-24) and default value. This covers all relevant aspects beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool analyzes whether income is rising or falling with concrete numbers, and specifies that it responds to a common user question. It does not explicitly name sibling tools, but the purpose is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives. The description does not mention conditions, use cases, or comparisons with sibling tools like desglose_gastos or salud_financiera, leaving the agent without explicit selection criteria.

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. Dates show when Glama detected each change.

6 tool updatesv0.1.0Sep 8, 2026
- First observeddesglose_gastos
- First observeddetectar_gastos_atipicos
- First observedestado_resultados
- First observedproyeccion_flujo_caja
- First observedsalud_financiera
- First observedtendencia_ingresos

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool targets a distinct financial aspect: expense breakdown, anomaly detection, income statement, revenue trend, cash flow projection, and overall health. While some overlap in scope (e.g., estado_resultados and salud_financiera both provide summaries), their purposes and outputs are clearly differentiated, making misselection unlikely.

Naming Consistency4/5

All tool names are in Spanish snake_case, following a descriptive noun or verb-noun pattern. They are consistent in style and clarity, though not all adhere to a strict verb_noun convention. The naming is predictable and readable.

Tool Count5/5

Six tools is well-scoped for a financial analysis server. Each tool covers a meaningful analytical function without redundancy, and the count is appropriate for the domain, allowing agents to choose the right tool without overwhelming options.

Completeness4/5

The tool surface covers core financial analysis needs: expense breakdown, anomaly detection, income statement, revenue trend, cash flow projection, and a health summary. Minor gaps include lack of a dedicated budget comparison or year-over-year P&L tool, but the existing set handles most common queries without dead ends.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Era ContextOAuth
app.era
Personal finance, bank account, and shared memory connector for Claude, ChatGPT, Gemini Spark & more
Finance Knowledge & Memory
1
cashflowOAuth
io.github.adam-messinger
Personal finance ledger for AI agents — query spending, track bills, forecast cash flow.
Finance Databases
2
Cayra Decision IntelligenceOAuth
io.cayra
Ask questions in plain language, get answers from your business database. No SQL required.
Databases Search
1
Candor Finance AOAuth
money.candor
Personal-finance workspace for AI agents: accounts, spending, budgets, goals, and investments.
Agent Orchestration Finance
111

Related MCP Servers

sales-agent-mcp
Databases Data Visualization Finance
smantiv
F
license
Not graded
quality
D
maintenance
Enables natural language sales analysis by connecting to a SQLite database, generating charts, and exporting results to CSV/Excel.
Updated 3 months ago (2026-06-19 20:29 UTC)
-
Finance MCP Server
Finance Databases
PavelKosik
A
license
Not graded
quality
C
maintenance
Turns a personal-finance SQLite database into typed, schema-validated tools that an AI assistant can call directly, letting you manage accounts, transactions, budgets, debts, investments, tax estimates, and goals through natural language.
Updated 3 months ago (2026-06-21 09:28 UTC)
25
MIT
Expense Tracker MCP Server
Finance Databases
arjunnavadiya8
F
license
A
quality
B
maintenance
Enables AI assistants to track, query, summarize, and delete personal expenses stored in a local SQLite database via natural language.
Updated a month ago (2026-08-12 17:48 UTC)
4
-
Expense Manager MCP Server
sonali1103
F
license
A
quality
C
maintenance
Enables natural language management of personal expenses, including adding, updating, deleting, searching, and summarizing expenses stored in a local SQLite database.
Updated 20 days ago (2026-08-19 20:59 UTC)
6
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/JuanDsm04/mcp-finanzas-pyme'

If you have feedback or need assistance with the MCP directory API, please join our Discord server