finanzas-pyme

by JuanDsm04

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.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.
Average 4.3/5 across 6 of 6 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

finanzas-pyme MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![finanzas-pyme MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/JuanDsm04/mcp-finanzas-pyme/badges/card.svg)](https://glama.ai/mcp/servers/JuanDsm04/mcp-finanzas-pyme)

Score Badge

Copy to your README.md:

[![finanzas-pyme MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/JuanDsm04/mcp-finanzas-pyme/badges/score.svg)](https://glama.ai/mcp/servers/JuanDsm04/mcp-finanzas-pyme)

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