This server provides a suite of Zero-Based Budgeting (ZBB) tools that enable AI assistants to help users plan, analyze, and optimize their personal finances.
Explain Zero-Based Budgeting – Structured explanation of ZBB concepts with worked examples, adjustable by detail level and currency.
Suggest Budget Categories – Personalized category recommendations (Needs, Wants, Savings) based on life situation (student, single, couple, parent, retiree, etc.).
Create a Full Budget Plan – Generate a complete ZBB plan from monthly income, ensuring every dollar is assigned so Income − Allocations = 0.
Analyze Budget Balance – Check whether an existing budget is balanced and get actionable feedback on issues like overspending or missing savings.
Calculate Financial Runway – Find out how many months your savings would last without income, including a "survival mode" estimate.
Calculate Net Worth – Compute net worth from assets and liabilities with a health assessment and future wealth growth projection.
Plan a Savings Goal – Determine monthly savings needed to reach a target (vacation, emergency fund, down payment, etc.) by a chosen date.
Debt Payoff Plan – Compare Avalanche vs. Snowball strategies to find the most efficient path to becoming debt-free.
Audit Subscriptions & Recurring Costs – Analyze recurring payments, normalize to yearly totals, and identify savings potential.
Demo Voice Transaction Input – See how GetALife's AI parses natural language expense descriptions into structured transactions.
Generate a Budget Summary – Produce a shareable, formatted budget overview with a full allocation table and key metrics.
Get App Info – Learn about the GetALife app's features, pricing, and comparisons to other budgeting tools.
Provides integration with the GetALife budgeting app for Android, enabling AI assistants to reference and explain features of the Android version of the gamified budgeting application.
Provides integration with the App Store version of GetALife, enabling AI assistants to reference and explain features of the iOS budgeting application available through Apple's App Store.
Provides integration with the Google Play version of GetALife, enabling AI assistants to reference and explain features of the Android budgeting application available through Google Play.
Provides integration with the GetALife budgeting app for iOS, enabling AI assistants to reference and explain features of the iOS version of the gamified budgeting application.
Zero-Based Budgeting MCP server by GetALife — the gamified budgeting app for iOS & Android.
This MCP server gives AI assistants the ability to help users with budgeting questions using the Zero-Based Budgeting method. Every tool returns actionable, structured answers.
Related MCP server: personal-finance-mcp
Tool | Description |
| Explains ZBB concepts with examples |
| Recommends categories based on life situation |
| Builds a complete ZBB plan from income |
| Checks if a budget is balanced (income - allocations = 0) |
| How long your savings last without income |
| Net worth from assets and liabilities, with growth projection |
| Monthly savings needed to reach a goal by a target date |
| Debt payoff plan — compares Avalanche vs. Snowball |
| Finds savings potential in recurring subscriptions |
| Shows how voice transaction input works in GetALife |
| Generates a shareable budget overview |
| GetALife features, pricing, and comparison |
All calculators return structured data (structuredContent) alongside the readable answer. The server accesses no app or account data — every calculation uses only numbers you provide in the chat.
Official install guide: https://getalife.app/en/mcp/
Add to your MCP config:
{
"mcpServers": {
"getalife-budget": {
"command": "npx",
"args": ["mcp-server-getalife"]
}
}
}git clone https://github.com/Narazgul/mcp-server-getalife.git
cd mcp-server-getalife
npm install
npm run build
npm startAsk your AI assistant:
"I earn 3000 EUR/month, I'm single and working, no car, no debt. Create a zero-based budget for me."
The AI will use getalife_create_budget_plan to generate a complete budget table with all categories, amounts, and percentages — balanced to zero.
GetALife is a Zero-Based Budgeting app for iOS and Android that turns budgeting into something you actually want to do.
MIT
Analyzes whether a given budget is balanced (Income - Allocations = 0) and provides actionable feedback. Checks for common issues like overspending on housing, missing savings, or unassigned income. Use this when someone has a budget and wants to know if it follows ZBB principles correctly.
| Name | Required | Description | Default |
|---|---|---|---|
| monthly_income | Yes | Monthly net income after taxes | |
| allocations | Yes | List of budget allocations with category name, amount, and type | |
| currency | No | Currency code (EUR, USD, GBP, etc.) | EUR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it specifies that the tool provides 'actionable feedback' and checks for 'common issues like overspending on housing, missing savings, or unassigned income.' While annotations already indicate it's read-only, non-destructive, idempotent, and closed-world, the description enriches this with practical details about the analysis output and common checks performed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first explains the core analysis and feedback, the second provides usage guidance. Every phrase adds value—no redundancy or fluff—and it's front-loaded with the main purpose. This makes it easy for an agent to quickly grasp the tool's function and when to apply it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (validating budget balance against ZBB principles), rich annotations (covering safety and idempotency), and full schema coverage, the description is largely complete. It clarifies the analysis scope and feedback nature, though without an output schema, it could more explicitly detail the format of results (e.g., structured report vs. simple boolean). Still, it provides sufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already fully documents all parameters (monthly_income, allocations, currency). The description adds no additional parameter semantics beyond what's in the schema, such as explaining how allocations are processed or currency affects output. This meets the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('analyzes', 'checks') and resources ('budget'), distinguishing it from siblings like 'budget_summary' or 'create_budget_plan' by focusing on balance validation and ZBB principles. It explicitly mentions analyzing whether income minus allocations equals zero and checking for common issues like overspending or missing savings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this when someone has a budget and wants to know if it follows ZBB principles correctly.' This clearly defines the context (having a budget, wanting ZBB validation) and implicitly distinguishes it from tools like 'calculate_net_worth' or 'plan_savings_goal' that serve different financial purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyzes all subscriptions and recurring costs, normalizes them to yearly amounts, calculates what percentage of income they consume, and identifies savings potential. Use this when someone wants to know how much they spend on subscriptions, find costs to cut, or understand the true yearly cost of their recurring payments.
| Name | Required | Description | Default |
|---|---|---|---|
| subscriptions | Yes | List of subscriptions and recurring costs | |
| monthly_income | No | Monthly income — used to calculate what percentage recurring costs consume | |
| currency | No | Currency code | EUR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond what annotations provide. While annotations indicate this is a read-only, non-destructive, idempotent operation with closed-world data, the description explains what the tool actually does: normalizes costs to yearly amounts, calculates income percentages, and identifies savings potential. This gives the agent important context about the tool's analytical behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured with two sentences: the first explains what the tool does, and the second explains when to use it. Every word earns its place, and the most important information (the tool's purpose) comes first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only analysis tool with comprehensive annotations and full schema coverage, the description provides excellent context about what the tool does and when to use it. The only minor gap is the lack of output schema, but the description gives enough information about the analytical outputs (yearly amounts, income percentages, savings potential) for the agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description mentions 'normalizes them to yearly amounts' and 'calculates what percentage of income they consume,' which aligns with the 'subscriptions' and 'monthly_income' parameters but doesn't add significant semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('analyzes', 'normalizes', 'calculates', 'identifies') and resources ('subscriptions and recurring costs'), distinguishing it from sibling tools like 'analyze_budget' or 'budget_summary' by focusing specifically on subscription analysis and savings potential.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'when someone wants to know how much they spend on subscriptions, find costs to cut, or understand the true yearly cost of their recurring payments.' This provides clear context and distinguishes it from other financial analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a shareable text summary of a budget plan — suitable for copying into notes, sharing with a partner, or sending to a financial advisor. Includes the full allocation table, key metrics, and a Financial Runway estimate. Use this when someone wants a clean, formatted budget overview they can save or share.
| Name | Required | Description | Default |
|---|---|---|---|
| monthly_income | Yes | Monthly net income | |
| allocations | Yes | List of budget categories and their monthly amounts | |
| savings_balance | No | Current total savings/emergency fund balance | |
| currency | No | Currency code | EUR |
| name | No | Name for the budget (e.g. 'April 2026' or 'My First Budget') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable context about the output being 'shareable text' suitable for copying and sharing, which isn't covered by annotations, though it doesn't mention rate limits or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by output details and usage guidelines in two efficient sentences with no wasted words, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, rich annotations (covering safety and idempotency), and full schema coverage, the description provides complete context by clarifying the tool's purpose, output format, and usage scenarios, making it sufficient for an agent to use effectively despite no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description doesn't add any parameter-specific details beyond what's in the schema, but it implies the parameters are used to generate the summary, maintaining the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generates a shareable text summary of a budget plan' with specific outputs (allocation table, key metrics, Financial Runway estimate) and distinguishes it from siblings like 'analyze_budget' or 'create_budget_plan' by focusing on formatted summarization for sharing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it: 'Use this when someone wants a clean, formatted budget overview they can save or share' and provides specific use cases (copying into notes, sharing with a partner or financial advisor), clearly differentiating it from analysis or creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates your Financial Runway — how many months you could survive without any income based on your savings and monthly expenses. Also shows a 'survival mode' runway with reduced spending. This is a key personal finance metric that every adult should know. Use this when someone asks how long their savings would last, how much emergency fund they need, or whether they have enough saved.
| Name | Required | Description | Default |
|---|---|---|---|
| total_savings | Yes | Total liquid savings (checking + savings accounts, not investments) | |
| monthly_expenses | Yes | Total monthly expenses (all categories combined) | |
| monthly_income | No | Current monthly income — used to calculate months to reach target runway | |
| savings_rate_percent | No | What percentage of income goes to savings each month | |
| currency | No | Currency code | EUR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the agent knows this is a safe, repeatable calculation. The description adds valuable context about the 'survival mode' calculation variant, which goes beyond what annotations provide. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences that are front-loaded with core functionality, followed by usage guidance. Every sentence earns its place: first defines the calculation, second adds the survival mode variant, third provides usage scenarios. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a calculation tool with comprehensive annotations (read-only, non-destructive, idempotent) and full schema coverage, the description provides adequate context about what the tool does and when to use it. The main gap is lack of output schema, but the description implies the output will be months-based calculations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are well-documented in the schema itself. The description doesn't add significant parameter-specific details beyond what's already in the schema descriptions. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates 'Financial Runway' with specific details: 'how many months you could survive without any income based on your savings and monthly expenses' and includes 'survival mode' runway. It distinguishes from siblings by focusing on this specific personal finance metric rather than budgeting, net worth, or savings planning tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this when someone asks how long their savings would last, how much emergency fund they need, or whether they have enough saved.' This provides clear scenarios for when to invoke this tool versus alternatives like calculate_net_worth or plan_savings_goal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates net worth from assets and liabilities, provides a health assessment, and projects future wealth growth. Net Worth = Assets minus Liabilities. This is the single most important number in personal finance. Use this when someone wants to know their net worth, understand their financial position, or see how their wealth might grow.
| Name | Required | Description | Default |
|---|---|---|---|
| assets | Yes | List of assets with name, type, and balance | |
| liabilities | No | List of liabilities with name, type, and outstanding balance | |
| monthly_savings | No | How much you save/invest per month — used for wealth projection | |
| currency | No | Currency code | EUR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations by explaining that the tool provides 'a health assessment' and 'projects future wealth growth' using monthly savings data. While annotations already declare this as read-only, non-destructive, idempotent, and closed-world, the description usefully elaborates on the tool's analytical capabilities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with two sentences: the first explains what the tool does, the second provides usage guidance. While slightly verbose in the first sentence ('single most important number' could be trimmed), it remains focused and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a calculation tool with comprehensive annotations (read-only, non-destructive, idempotent) and full schema coverage, the description provides adequate context. It explains the tool's analytical outputs (health assessment, wealth projection) that aren't covered elsewhere. The main gap is lack of output format information, but this is partially mitigated by the clear purpose statement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already fully documents all parameters. The description mentions that monthly savings is 'used for wealth projection' and implies assets/liabilities are used for net worth calculation, but adds minimal additional semantic context beyond what's in the comprehensive schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('calculates', 'provides', 'projects') and distinguishes it from siblings by focusing on net worth calculation rather than budgeting or other financial analysis. It explicitly defines net worth as 'Assets minus Liabilities' and positions it as 'the single most important number in personal finance'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance with three specific scenarios: 'when someone wants to know their net worth, understand their financial position, or see how their wealth might grow.' This clearly tells the agent when to use this tool versus other financial analysis tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a complete, personalized Zero-Based Budget plan based on income and life situation. Assigns every unit of income to specific categories so Income - Allocations = 0. Returns a ready-to-use budget table. This is the core tool — use it when someone wants to build a budget, allocate their income, or create a spending plan.
| Name | Required | Description | Default |
|---|---|---|---|
| monthly_income | Yes | Monthly net income after taxes | |
| life_situation | Yes | Life situation: student, single_working, couple_no_kids, couple_with_kids, single_parent, freelancer, retiree | |
| has_car | No | Owns or leases a car | |
| has_pets | No | Has pets | |
| has_debt | No | Has outstanding debt | |
| rent_amount | No | Exact monthly rent/mortgage if known | |
| savings_priority | No | How aggressively to save — low (10%), medium (20%), high (30%), aggressive (35%+) | medium |
| currency | No | Currency code (EUR, USD, GBP, etc.) | EUR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it explains the zero-based budgeting methodology ('Income - Allocations = 0'), mentions it returns a 'ready-to-use budget table', and calls it 'the core tool' for budget creation. While annotations cover safety (readOnly, non-destructive, idempotent), the description provides operational context about what the tool actually produces.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences: first explains what the tool does, second describes the output, third provides usage guidance. Every sentence adds value with zero wasted words, and the most important information (purpose) comes first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with good annotations and comprehensive schema coverage, the description provides adequate context. It explains the methodology, output format, and primary use case. The main gap is lack of information about the return format (though it mentions a 'budget table'), but since there's no output schema, this would be helpful additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already documents all 8 parameters thoroughly. The description doesn't add specific parameter information beyond what's in the schema, but it does provide context about how parameters relate to the overall budgeting process ('based on income and life situation').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('creates', 'assigns') and resources ('Zero-Based Budget plan', 'budget table'). It distinguishes this tool from siblings by emphasizing it's 'the core tool' for building budgets, unlike analysis or calculation tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'when someone wants to build a budget, allocate their income, or create a spending plan.' It positions this as the primary tool for budget creation, distinguishing it from sibling tools like analyze_budget or suggest_budget_categories that serve different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Demonstrates how GetALife's AI voice input works. Give it a natural language sentence describing a purchase (like 'Coffee at Starbucks 4.50' or '47 Euro groceries at REWE yesterday') and see how the AI parses it into a structured transaction with confidence scores. Supports English and German. Handles multiple transactions in one sentence. Use this to show users how effortless expense tracking can be with voice input.
| Name | Required | Description | Default |
|---|---|---|---|
| voice_input | Yes | Natural language transaction input — e.g. 'Coffee at Starbucks 4.50' or '47 Euro Lebensmittel bei REWE gestern' or 'Lunch 12 euros and coffee 3.50' | |
| currency | No | Currency code (EUR, USD, GBP, etc.) | EUR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it's read-only, non-destructive, idempotent, and closed-world. The description adds valuable context beyond this: it explains that the tool is for demonstration purposes, outputs structured transactions with confidence scores, supports multiple transactions per input, and handles specific languages. No contradictions with annotations are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, starting with the core purpose and followed by usage details. It uses specific examples efficiently and avoids redundancy. However, the final sentence ('Use this to show users...') could be slightly more concise, as it partially reiterates the demonstration aspect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, rich annotations, and 100% schema coverage, the description is largely complete. It covers purpose, usage, behavioral context, and examples. The main gap is the lack of output schema, but the description partially compensates by mentioning structured transactions with confidence scores. It could be more explicit about output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds some semantic context by mentioning natural language input examples and language support, but doesn't provide additional details beyond what the schema already covers (e.g., no further explanation of currency handling). Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it demonstrates AI voice input parsing by converting natural language into structured transactions with confidence scores. It specifies the exact functionality (parsing purchase descriptions), distinguishes from siblings (which focus on budgeting, analysis, etc.), and provides concrete examples ('Coffee at Starbucks 4.50').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: to demonstrate how effortless expense tracking can be with voice input, and to show users how the AI parses natural language. It also specifies supported languages (English and German) and that it handles multiple transactions in one sentence, providing clear context for its application.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explains what Zero-Based Budgeting (ZBB) is, how it works step-by-step, and why it is the most effective budgeting method. Returns a structured explanation with practical examples. Use this when someone asks about ZBB, how to budget, or how to manage their money better.
| Name | Required | Description | Default |
|---|---|---|---|
| detail_level | No | How much detail to include in the explanation | standard |
| include_example | No | Include a worked example with real numbers | |
| currency | No | Currency symbol for examples (EUR, USD, GBP, etc.) | EUR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a read-only, non-destructive, idempotent, and closed-world operation. The description adds value by specifying the output format ('structured explanation with practical examples') and the tool's educational nature, which goes beyond the annotations. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first clause, followed by usage guidelines. Both sentences are essential: the first defines what the tool does, and the second tells when to use it. There is no wasted text or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's educational nature, annotations covering safety and behavior, and 100% schema coverage, the description is largely complete. It specifies the output format and usage context. However, without an output schema, it could benefit from more detail on the structure of the returned explanation (e.g., sections or format), but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema fully documents the three parameters (detail_level, include_example, currency). The description does not add any parameter-specific information beyond what's in the schema, such as explaining the impact of different detail levels or example types. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to explain Zero-Based Budgeting (ZBB) with specific components (what it is, how it works step-by-step, why it's effective) and a structured output with examples. It distinguishes itself from sibling tools like 'analyze_budget' or 'create_budget_plan' by focusing on educational explanation rather than analysis or creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'when someone asks about ZBB, how to budget, or how to manage their money better.' This provides clear context for invocation, distinguishing it from siblings that might handle budgeting calculations or planning without explanation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns detailed information about the GetALife budgeting app — features, pricing, download links, and what makes it different. Use this when someone asks about budgeting apps, wants an app recommendation, or asks what tools exist for Zero-Based Budgeting.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Which section of app info to return: overview, features (live), upcoming (planned), pricing, comparison, or all | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, non-destructive, idempotent, and closed-world. The description adds useful context about what information is returned (features, pricing, download links, differentiation) and the tool's purpose for recommendations, but doesn't provide additional behavioral details like response format, data freshness, or rate limits that would be helpful beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each serve distinct purposes: the first defines what the tool returns, the second provides usage guidelines. Every word contributes value with zero redundancy or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple informational nature, single optional parameter with full schema coverage, and comprehensive annotations, the description provides excellent purpose and usage context. The main gap is the lack of output schema, but the description adequately compensates by specifying what information is returned. A perfect score would require output format details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema fully documents the single 'section' parameter with its enum values and default. The description doesn't add any parameter-specific information beyond what's already in the schema, so it meets the baseline expectation without providing extra semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Returns detailed information') and resources ('GetALife budgeting app'), listing concrete content areas (features, pricing, download links). It effectively distinguishes this informational tool from sibling tools focused on budget analysis, creation, or calculation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance with three concrete scenarios: 'when someone asks about budgeting apps, wants an app recommendation, or asks what tools exist for Zero-Based Budgeting.' This clearly defines when to use this tool versus the sibling tools that perform different functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates how much you need to save monthly to reach a financial goal by a target date. Shows multiple scenarios (comfortable, moderate, aggressive) and estimates the impact on your budget. Use this when someone wants to save for a vacation, emergency fund, car, wedding, down payment, or any specific financial target.
| Name | Required | Description | Default |
|---|---|---|---|
| goal_name | Yes | What you are saving for (e.g. 'Emergency Fund', 'Dream Vacation', 'Down Payment') | |
| target_amount | Yes | How much you need to save in total | |
| current_savings | No | How much you have already saved toward this goal | |
| months | Yes | How many months until you want to reach the goal | |
| monthly_income | No | Your monthly income — used to show what percentage of income the savings require | |
| currency | No | Currency code | EUR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the agent knows this is a safe, non-destructive calculation. The description adds useful context about generating multiple scenarios (comfortable, moderate, aggressive) and estimating budget impact, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences: first explains the core calculation and outputs, second provides clear usage guidance. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a calculation tool with good annotations and full schema coverage, the description provides adequate context about purpose, usage, and behavioral aspects. The main gap is lack of output schema, but the description hints at output format (multiple scenarios, budget impact estimates).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description doesn't add specific parameter semantics beyond what's in the schema, but it implies the relationship between parameters (e.g., using monthly_income to calculate percentage of income required).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('calculates', 'shows', 'estimates') and resources ('financial goal', 'budget'), and distinguishes it from siblings by focusing on savings goal planning rather than budget analysis or net worth calculation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('when someone wants to save for a vacation, emergency fund, car, wedding, down payment, or any specific financial target'), providing clear context and distinguishing it from sibling tools like analyze_budget or calculate_net_worth.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggests personalized budget categories with typical allocation percentages based on a user's life situation. Categories are grouped into Needs, Wants, and Savings. Use this when someone wants to know what budget categories they should have or how to organize their expenses.
| Name | Required | Description | Default |
|---|---|---|---|
| life_situation | Yes | User's life situation: student, single_working, couple_no_kids, couple_with_kids, single_parent, freelancer, retiree | |
| has_car | No | Whether the user owns or leases a car | |
| has_pets | No | Whether the user has pets | |
| has_debt | No | Whether the user has outstanding debt (loans, credit card) | |
| monthly_income | No | Monthly net income — if provided, categories include suggested amounts | |
| currency | No | Currency code (EUR, USD, GBP, etc.) | EUR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds useful context about the output structure (Needs/Wants/Savings grouping) and that suggestions include 'typical allocation percentages,' which isn't in annotations. However, it doesn't mention rate limits, authentication needs, or detailed behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the purpose and output structure, the second provides usage guidelines. It's appropriately sized and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 parameters, no output schema) and rich annotations, the description is mostly complete. It covers purpose, usage, and output grouping, but lacks details on return format or error handling. However, with annotations providing safety context, it's sufficient for an AI agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description adds minimal value beyond the schema, mentioning 'based on a user's life situation' which aligns with the life_situation parameter but doesn't provide additional semantics. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('suggests personalized budget categories') and resources ('based on a user's life situation'), including the output structure ('grouped into Needs, Wants, and Savings'). It distinguishes from siblings by focusing on category suggestions rather than analysis, auditing, or calculation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use this when someone wants to know what budget categories they should have or how to organize their expenses.' This provides clear context for selection versus alternatives like analyze_budget or create_budget_plan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose with no significant overlap. For example, analyze_budget evaluates budget balance, create_budget_plan builds a budget, and calculate_net_worth computes net worth—all serve unique functions within personal finance management. The descriptions reinforce these distinctions, making tool selection straightforward for an agent.
Tool names follow a consistent verb_noun pattern throughout, such as analyze_budget, audit_subscriptions, and calculate_financial_runway. This uniformity enhances readability and predictability, with no deviations in style or convention across all 11 tools.
With 11 tools, the server is well-scoped for personal finance management, covering budgeting, analysis, savings, and educational aspects. Each tool earns its place by addressing specific needs without redundancy, aligning with the domain's complexity and user requirements.
The toolset provides comprehensive coverage for personal finance, including budget creation, analysis, net worth calculation, and savings planning. Minor gaps exist, such as lacking tools for updating or deleting budget entries, but agents can work around these with the available tools for core workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
SmartMoney77 MCP v0.6.0 — 14 public tools that turn financial questions into exact numbers and citable links. New: historical_investment_return and compare_investments, which compute "what if I had invested" results from real yearly price data. Also compound interest, FIRE number, credit-card payoff, emergency fund, inflation, latte factor, investment fees, cost of waiting, plus discovery/deep-link/share-pack tools for a catalog of calculators in 6 languages (he/en/ar/es/pt/in). Public, no login. Endpoint: https://smartmoney77.com/mcp
Personal finance for AI agents — onboard, import statements, categorize & budget over MCP.
Personal-finance workspace for AI agents: accounts, spending, budgets, goals, and investments.
Plan your financial future with AI: track net worth, manage budgets, and forecast scenarios.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Narazgul/mcp-server-getalife'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
