TreePod Financial MCP Agent

by janetsep

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: analyze finances, calculate tariffs, check occupancy, compare competition, generate reports, get business status, optimize pricing, and predict revenue. The descriptions reinforce distinct domains like analysis, calculation, verification, comparison, reporting, status checking, optimization, and prediction, making misselection unlikely.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., analyze_finances, calculate_tariff, check_occupancy). There are no deviations in style or convention, making the naming predictable and easy to parse for agents.
Tool Count5/5
With 8 tools, the count is well-scoped for a financial management agent covering key areas like analysis, pricing, occupancy, competition, reporting, status, optimization, and prediction. Each tool earns its place without feeling excessive or insufficient for the domain.
Completeness4/5
The toolset provides comprehensive coverage for financial and business management, including analysis, pricing, occupancy, competition, reporting, status, optimization, and prediction. Minor gaps might exist, such as direct data update or booking management tools, but agents can likely work around these for core workflows.
Average 2.9/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
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 of behavioral disclosure. It mentions using 'configuración real' (real configuration), implying it relies on current settings, but doesn't detail aspects like rate limits, error handling, authentication needs, or whether it's a read-only operation. This leaves significant gaps in understanding how the tool behaves in practice.
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 a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose, making it easy to grasp quickly. However, it could be slightly more structured by separating key factors for clarity, but overall, it's concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It lacks details on parameter usage, behavioral traits, output format, and differentiation from siblings. For a tariff calculation tool that likely involves business logic and configuration, this minimal description doesn't provide enough context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions season, people, and channel, which map to 'checkin_date/checkout_date', 'guests', and 'channel', adding some semantic context. However, it doesn't explain parameter formats (e.g., date format for 'checkin_date'), the meaning of 'channel' values, or constraints like the 'guests' range, leaving key details unclear.
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 the tool's purpose: calculating tariffs for reservations based on season, number of people, and channel using real configuration. It specifies the verb 'calcula' (calculates) and the resource 'tarifas' (tariffs), making the function evident. However, it doesn't explicitly differentiate from sibling tools like 'optimize_pricing' or 'compare_competition', which might have overlapping purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the factors (season, people, channel) but doesn't specify scenarios, prerequisites, or exclusions. For example, it doesn't clarify if this is for real-time bookings, planning, or comparison with other tools like 'optimize_pricing' or 'predict_revenue', leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It mentions that reports are 'basado en datos reales' (based on real data), which adds some context about data sources, but fails to disclose critical behavioral traits such as whether this is a read-only operation, if it requires specific permissions, what the output format might be (beyond the format parameter), or any rate limits. For a tool with no annotation coverage, this is inadequate.
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 concise and front-loaded in a single sentence: 'Genera reportes ejecutivos del negocio basado en datos reales'. It efficiently conveys the core purpose without unnecessary words. However, it could be slightly improved by structuring to highlight key aspects like parameters or usage context, but it earns high marks for brevity and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a report generation tool with 2 parameters), lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain what the tool returns, how parameters affect the output, or behavioral aspects like permissions or data sources. The description alone is insufficient for an agent to use the tool effectively without additional context or trial-and-error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning neither parameter (report_type, format) has descriptions in the schema. The tool description does not mention these parameters at all, providing no additional meaning beyond what the bare schema offers. With 2 parameters and no schema descriptions, the description fails to compensate, leaving users guessing about what values are valid (e.g., what report_types or formats are supported).
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 the tool's purpose: 'Genera reportes ejecutivos del negocio basado en datos reales' (Generates executive business reports based on real data). It specifies the verb 'genera' (generates) and resource 'reportes ejecutivos del negocio' (executive business reports), and distinguishes from siblings like analyze_finances or predict_revenue by focusing on report generation rather than analysis or prediction. However, it doesn't explicitly differentiate from all siblings (e.g., compare_competition might also generate reports).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate, when other tools should be used instead, or what prerequisites might be needed. Given the sibling tools include analyze_finances, predict_revenue, and others that might overlap with report generation, this lack of differentiation is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It states the tool analyzes finances with key metrics based on real data, but doesn't describe what the analysis entails (e.g., returns metrics like revenue, expenses), whether it's read-only or has side effects, or any constraints like data freshness or permissions required. For a tool with zero annotation coverage, this is a significant gap in transparency.
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 a single, efficient sentence in Spanish that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every part contributing to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (financial analysis tool), no annotations, no output schema, and low schema description coverage, the description is incomplete. It doesn't explain what metrics are returned, how the analysis is performed, or any behavioral traits. For a tool that likely provides detailed financial insights, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'period' with 0% description coverage, and the tool description doesn't mention any parameters. Since schema_description_coverage is low (<50%), the description should compensate but doesn't add any parameter information. However, with only one parameter and a default value provided in the schema, the baseline is adjusted to 3 as the minimal viable documentation, though it lacks semantic details like what 'period' values are acceptable.
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 the tool's purpose: 'Analiza las finanzas actuales de TreePod Glamping con métricas clave basado en datos reales' (Analyzes current finances of TreePod Glamping with key metrics based on real data). It specifies the verb 'analiza' (analyzes), the resource 'finanzas' (finances), and the scope 'TreePod Glamping'. However, it doesn't explicitly differentiate from sibling tools like 'get_business_status' or 'predict_revenue', which might overlap in financial analysis contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or compare it to siblings such as 'predict_revenue' for forecasting or 'get_business_status' for overall status checks. The context is implied (analyzing current finances), but explicit usage guidelines are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It states the tool checks occupancy status based on real data, but doesn't describe what 'real data' entails, whether it's read-only or has side effects, response format, error conditions, or rate limits. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 a single, efficient sentence in Spanish that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every part contributing to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (checking current and future occupancy), lack of annotations, no output schema, and incomplete parameter documentation (0% schema coverage), the description is insufficient. It doesn't explain what 'occupancy status' includes, how 'future' is defined, what 'real data' means, or what the return values look like. For a forecasting/status tool with no structured support, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention any parameters, while the input schema has one parameter ('date_range') with 0% schema description coverage. Since there's only one parameter and the description doesn't add any semantic information about it, the baseline score is 3. The description doesn't compensate for the lack of schema documentation, but the low parameter count keeps it from being lower.
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 the tool's purpose: 'Verifica estado de ocupación actual y futura de los domos basado en datos reales' (Checks current and future occupancy status of domes based on real data). It specifies the verb ('verifica'), resource ('domos'), and scope ('actual y futura'), but doesn't explicitly differentiate from sibling tools like 'get_business_status' or 'predict_revenue' which might overlap in domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or compare it to sibling tools like 'get_business_status' (which might include occupancy) or 'predict_revenue' (which could involve occupancy forecasting). Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It mentions the tool compares based on 'datos reales' (real data), implying it accesses external or live data sources, but does not specify behavioral traits like data sources, update frequency, rate limits, authentication needs, or output format. For a tool with no annotations, this leaves significant gaps in understanding how it operates and what to expect.
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 a single, concise sentence: 'Compara precios y servicios con la competencia basado en datos reales'. It is front-loaded with the core purpose and efficiently conveys the tool's function without unnecessary words. Every part of the sentence contributes to understanding, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (involving competitive analysis with real data), lack of annotations, no output schema, and minimal parameter documentation, the description is incomplete. It does not cover key aspects like data sources, result format, or usage constraints, leaving users with insufficient information to effectively invoke the tool. The description should provide more context to compensate for the missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'analysis_type' with 0% description coverage, and the tool description does not mention any parameters or their semantics. Since there is only one parameter, the baseline is 4, but the description adds no value beyond the schema, not explaining what 'analysis_type' means or its possible values. This results in a score of 3, as the schema provides structure but the description fails to enhance understanding.
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 the tool's purpose: 'Compara precios y servicios con la competencia basado en datos reales' (Compares prices and services with the competition based on real data). It specifies the verb 'compara' (compares) and resources 'precios y servicios' (prices and services), but does not explicitly differentiate it from sibling tools like 'optimize_pricing' or 'analyze_finances', which might involve similar competitive analysis. This makes it clear but not fully distinguished from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, such as when to choose 'compare_competition' over 'optimize_pricing' or 'analyze_finances' from the sibling list. Without such information, users must infer usage based on the tool name alone, which is insufficient for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It states the tool 'suggests' optimizations based on data, implying it's a read-only or analytical operation, but doesn't clarify if it performs calculations, requires specific permissions, has rate limits, or what the output format might be. For a tool with no annotations, this is insufficient to understand its behavior beyond a vague high-level purpose.
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 a single, efficient sentence in Spanish that directly states the tool's function. It's front-loaded with the core purpose and includes key factors (competition and occupancy) without unnecessary details. Every word contributes to understanding the tool's intent, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a pricing optimization tool with no annotations, no output schema, and minimal parameter documentation, the description is incomplete. It lacks details on how optimizations are generated, what data inputs are needed beyond implied factors, and what the output entails. For a tool that likely involves analytical processing, this leaves significant gaps for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter ('strategy') with 0% description coverage, and the tool description adds no information about parameters. Since there's only one parameter, the baseline is higher, but the description doesn't compensate for the lack of schema details. It implies the tool uses competition and occupancy data, but doesn't explain how these relate to the 'strategy' parameter or other inputs.
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 the tool's purpose: 'Sugiere optimizaciones de precios' (suggests price optimizations) based on competition and occupancy using real data. It specifies the verb 'sugiere' (suggests) and the resource 'optimizaciones de precios' (price optimizations), but doesn't explicitly differentiate it from sibling tools like 'calculate_tariff' or 'predict_revenue', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the factors used (competition and occupancy) but doesn't specify scenarios where it's preferred over siblings like 'compare_competition' or 'check_occupancy', nor does it mention prerequisites or exclusions. This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It mentions the tool predicts future revenue based on historical data and trends, but it doesn't describe the prediction model's accuracy, time horizon, output format, or any limitations (e.g., assumptions, data requirements). This is a significant gap for a predictive tool with zero annotation coverage.
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 a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence ('Predice ingresos futuros basado en datos históricos y tendencias reales') contributes to understanding the tool's function, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a predictive tool with no annotations, no output schema, and incomplete parameter documentation (0% coverage), the description is inadequate. It doesn't explain what the prediction returns, how it's formatted, any confidence intervals, or behavioral traits like rate limits or data requirements, leaving the agent with insufficient information for reliable use.
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 input schema has one parameter ('period') with 0% description coverage, and the description doesn't explicitly mention parameters. However, since there's only one parameter and the description implies temporal forecasting ('ingresos futuros'), it provides some contextual meaning. The baseline for 0 parameters would be 4, but with one undocumented parameter, the description adds marginal value by hinting at the temporal aspect, though it doesn't fully compensate for the coverage gap.
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 the tool's purpose with a specific verb ('Predice') and resource ('ingresos futuros'), and it provides context about the data sources ('basado en datos históricos y tendencias reales'). However, it doesn't explicitly distinguish this tool from sibling tools like 'analyze_finances' or 'generate_report', which might also involve financial forecasting or analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or specific scenarios where 'predict_revenue' is preferred over siblings like 'analyze_finances' or 'optimize_pricing', leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation by describing retrieval of status, but doesn't specify authentication needs, rate limits, data freshness, or error conditions. For a tool with zero annotation coverage, this is a significant gap in transparency.
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 a single, efficient sentence that front-loads the core purpose without unnecessary details. It wastes no words and is appropriately sized for a simple status retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks context on behavioral traits, usage guidelines, or output format. For a tool with 'business status' scope, more detail on what 'alerts and KPIs' entail would improve completeness.
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 input schema has one parameter ('format') with 0% description coverage, and the tool description doesn't mention parameters at all. However, with only one optional parameter and a default value provided in the schema, the baseline is high. The description doesn't add semantic value, but the minimal parameter burden justifies a score of 4.
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 the tool's purpose: to retrieve the 'current general business status with alerts and KPIs based on real data.' It specifies the verb ('Estado general actual' implies retrieval) and resource ('negocio'), though it doesn't explicitly differentiate from siblings like 'analyze_finances' or 'predict_revenue.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or comparisons to sibling tools like 'check_occupancy' or 'generate_report,' leaving the agent to infer usage context from the tool name alone.
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

Copy to your README.md:

[![treepod-financial-mcp MCP server](https://glama.ai/mcp/servers/janetsep/treepod-financial-mcp/badges/card.svg)](https://glama.ai/mcp/servers/janetsep/treepod-financial-mcp)

Score Badge

Copy to your README.md:

[![treepod-financial-mcp MCP server](https://glama.ai/mcp/servers/janetsep/treepod-financial-mcp/badges/score.svg)](https://glama.ai/mcp/servers/janetsep/treepod-financial-mcp)

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/janetsep/treepod-financial-mcp'

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