Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@YNAB MCP Server How much is left in my Groceries budget for this month?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for YNAB (You Need A Budget) — manage budgets, accounts, categories, and transactions through Claude.
Tool | Description |
| List all budgets |
| List accounts with balances |
| Category groups with budgeted/activity/balance |
| List payees (for resolving names to IDs) |
| Monthly overview with per-category breakdown |
| Search transactions by date/account/category/payee |
| Add a new transaction |
| Change budgeted amount for a category |
Tool | Description |
| Edit existing transaction fields |
| Delete a transaction |
| Create multiple transactions from JSON |
| View recurring/upcoming bills |
| Add a new account |
| Historical month list for trends |
| Change category name, note, or goal |
Related MCP server: YNAB Assistant
Go to YNAB Settings > Developer Settings and create a Personal Access Token.
cp .env.example .env
# Edit .env and set YNAB_ACCESS_TOKEN# stdio transport (Claude Desktop / Claude Code)
uv run server.py
# HTTP transport (Claude.ai connector / remote access)
uv run server.py --transport streamable-httpAdd to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"ynab": {
"command": "uv",
"args": ["run", "/path/to/ynab-mcp/server.py"],
"env": {
"YNAB_ACCESS_TOKEN": "your-token-here"
}
}
}
}Push this repo to GitHub
Create a new Railway project and connect the repo
Set environment variables in Railway:
YNAB_ACCESS_TOKEN — your YNAB Personal Access Token
YNAB_DEFAULT_BUDGET_ID — (optional) default budget UUID or "last-used"
MCP_BEARER_TOKEN — (optional) secure the MCP endpoint
Railway auto-deploys on push to main
The server reads the PORT environment variable (set automatically by Railway).
Set per-user tokens to give each person their own connector URL:
YNAB_TOKEN_ADAM=adams-token
YNAB_TOKEN_SARAH=sarahs-tokenURL routing:
/adam/mcp — uses YNAB_TOKEN_ADAM
/sarah/mcp — uses YNAB_TOKEN_SARAH
/mcp — uses YNAB_ACCESS_TOKEN (default)
YNAB uses milliunits (1/1000 of a currency unit):
$10.00 = 10000 milliunits
-$5.50 = -5500 milliunits
All tool responses include both raw milliunit values and formatted display strings (e.g., balance and balance_display).
YNAB allows 200 requests per hour per access token. The server returns friendly error messages when rate limited (HTTP 429).
Create a new account in a budget.
Args: name: Account name (e.g., "Chase Checking"). type: Account type. One of: checking, savings, cash, creditCard, lineOfCredit, otherAsset, otherLiability, mortgage, autoLoan, studentLoan, personalLoan, medicalDebt, otherDebt. balance: Starting balance in milliunits (e.g., 100000 = $100.00). budget_id: Budget ID (uses default if omitted).
Returns: Created account details with id, name, type, and balance.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| type | Yes | ||
| balance | Yes | ||
| budget_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this creates a new account but doesn't disclose behavioral traits like required permissions, whether this is idempotent, error conditions, or side effects. The Returns section describes output but not behavioral context. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (Args, Returns), front-loaded purpose statement, and zero wasted sentences. Every element serves a purpose: the first sentence states the tool's function, followed by parameter documentation and return value description.
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 this is a mutation tool with no annotations but with output schema (implied by Returns section), the description covers parameters thoroughly and states what's returned. However, it lacks behavioral context (permissions, errors, side effects) that would be important for a creation tool. The output schema reduces but doesn't eliminate the need for behavioral transparency.
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 0%, so the description must compensate fully. It provides clear semantic meaning for all 4 parameters: name with examples, type with complete enum values, balance with units and examples, and budget_id with default behavior. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a new account') and resource ('in a budget'), distinguishing it from sibling tools like get_accounts (read) or create_transaction (different resource). The verb+resource combination is precise and unambiguous.
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?
No guidance on when to use this tool versus alternatives is provided. While it's clear this creates accounts, there's no mention of prerequisites (e.g., budget must exist), constraints, or comparison to similar operations like updating existing accounts. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new transaction.
Args: account_id: The account UUID to create the transaction in. date: Transaction date in YYYY-MM-DD format. amount: Amount in milliunits (negative for outflows, positive for inflows). Example: -50000 = -$50.00 outflow, 150000 = $150.00 inflow. payee_name: Name of payee (creates new payee if doesn't exist). Use this OR payee_id. payee_id: UUID of existing payee. Use this OR payee_name. category_id: UUID of the budget category. Omit when using subtransactions (each sub has its own). memo: Transaction memo. cleared: Cleared status: "cleared", "uncleared", or "reconciled". Defaults to "cleared". approved: Whether the transaction is approved. Defaults to True. flag_color: Optional flag: red, orange, yellow, green, blue, purple. subtransactions: Array of subtransaction objects for split transactions. Each item: {"amount": int, "category_id": "uuid", "memo": "text", "payee_id": "uuid", "payee_name": "text"}. Only amount and category_id are required per sub. The sub amounts must sum to the parent amount. When using subtransactions, omit category_id on the parent (it becomes a split). budget_id: Budget ID (uses default if omitted).
Returns: Created transaction details with id, date, amount, payee, category, and subtransactions.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes | ||
| date | Yes | ||
| amount | Yes | ||
| payee_name | No | ||
| payee_id | No | ||
| category_id | No | ||
| memo | No | ||
| cleared | No | cleared | |
| approved | No | ||
| flag_color | No | ||
| subtransactions | No | ||
| budget_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 effectively describes key behaviors: it's a creation tool (implying mutation), specifies default values (e.g., cleared defaults to 'cleared', approved defaults to True), explains conditional logic (payee_name vs. payee_id, category_id omission with subtransactions), and details constraints (subtransactions amounts must sum to parent amount). It could improve by mentioning authentication needs or error handling, but it's quite comprehensive.
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 with clear sections (Args, Returns) and uses bullet-like formatting for readability. Most sentences earn their place by providing essential information, but it could be more front-loaded—the detailed parameter explanations are lengthy, though necessary given the 0% schema coverage. A brief summary upfront might enhance conciseness.
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 complexity (12 parameters, no annotations, 0% schema coverage) and the presence of an output schema (implied by 'Returns' section), the description is highly complete. It thoroughly explains all input parameters, their interactions, defaults, and constraints, and summarizes the return values. This provides enough context for an agent to use the tool effectively without relying on structured fields.
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 0%, so the description must fully compensate. It excels by providing detailed semantics for all 12 parameters: explains formats (e.g., date in YYYY-MM-DD, amount in milliunits with sign conventions), clarifies usage (e.g., payee_name creates new payee if missing, payee_id for existing), defines enums (e.g., cleared status options, flag colors), describes complex structures (subtransactions array with required fields and summation rule), and notes defaults and optionality. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear, specific verb ('Create') and resource ('a new transaction'), immediately stating what the tool does. It distinguishes from siblings like 'create_transactions_bulk' (single vs. bulk creation), 'delete_transaction' (creation vs. deletion), and 'update_transaction' (creation vs. modification), making the purpose unambiguous.
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 clear context for usage through parameter explanations (e.g., 'Use this OR payee_id' for payee_name, 'Omit when using subtransactions' for category_id, 'uses default if omitted' for budget_id). However, it lacks explicit guidance on when to choose this tool over alternatives like 'create_transactions_bulk' or 'update_transaction', which would be needed for a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create multiple transactions at once from a JSON string.
The JSON should contain a "transactions" array where each item has: account_id (required), date (required), amount (required in milliunits), and optionally: payee_name, payee_id, category_id, memo, cleared, approved, flag_color, subtransactions (array of {amount, category_id, memo, payee_id, payee_name}).
Args: transactions_json: JSON string with a "transactions" array. budget_id: Budget ID (uses default if omitted).
Returns: Summary of created and duplicate transactions.
| Name | Required | Description | Default |
|---|---|---|---|
| transactions_json | Yes | ||
| budget_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions returns a summary of created and duplicate transactions, which is helpful, but doesn't disclose critical behavioral traits like whether this is a write operation (implied by 'create'), authentication requirements, rate limits, error handling, or idempotency. The description adds some value but leaves significant gaps.
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 appropriately sized and front-loaded with the core purpose. The JSON details are necessary but could be slightly more streamlined. Most sentences earn their place, though the parameter explanations are integrated rather than separate sections.
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 no annotations, 0% schema coverage, but an output schema exists, the description does well by detailing parameters and return summary. It covers the essential what and how, though it could improve on behavioral aspects like permissions or errors. The output schema reduces need for return value 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?
Schema description coverage is 0%, so the description must compensate fully. It provides detailed semantics for both parameters: 'transactions_json' is explained with a comprehensive JSON structure including required/optional fields and nested arrays, and 'budget_id' is noted as optional with a default. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates multiple transactions from a JSON string, specifying it's a bulk operation. It distinguishes from the sibling 'create_transaction' by emphasizing multiple transactions at once, though it doesn't explicitly name that alternative.
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 implies usage for bulk creation of transactions, but doesn't explicitly state when to use this vs. the single 'create_transaction' tool or mention prerequisites like required permissions. It provides some context through the JSON structure but lacks explicit guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a transaction.
Args: transaction_id: The transaction UUID to delete. budget_id: Budget ID (uses default if omitted).
Returns: Confirmation of deletion.
| Name | Required | Description | Default |
|---|---|---|---|
| transaction_id | Yes | ||
| budget_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it correctly identifies this as a destructive operation ('Delete'), it doesn't mention permission requirements, whether deletion is permanent/reversible, rate limits, or what happens to associated data. The return statement is vague ('Confirmation of deletion').
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 a clear purpose statement followed by Args and Returns sections. Every sentence serves a purpose with zero wasted words, making it easy to parse 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?
For a destructive operation with no annotations, the description is minimally adequate but incomplete. It identifies the tool as a deletion operation and documents parameters, but lacks crucial behavioral context about permissions, permanence, and side effects. The existence of an output schema somewhat mitigates the need to detail return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining both parameters: 'transaction_id' as 'The transaction UUID to delete' and 'budget_id' as 'Budget ID (uses default if omitted)'. This adds meaningful context beyond the bare schema, though it could specify format expectations for UUIDs.
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 action ('Delete') and resource ('a transaction'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'update_transaction' or 'get_transactions' beyond the obvious verb difference.
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 no guidance on when to use this tool versus alternatives like 'update_transaction' or 'create_transaction'. It doesn't mention prerequisites, consequences, or scenarios where deletion is appropriate versus modification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all accounts in a budget with balances.
Args: budget_id: Budget ID (uses default if omitted).
Returns: List of accounts with name, type, balance, cleared_balance, on_budget, and closed status.
| Name | Required | Description | Default |
|---|---|---|---|
| budget_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that it's a read operation ('List') and mentions balance details, but does not cover behavioral aspects like error handling, pagination, rate limits, or authentication needs. The description is adequate but lacks depth for a tool with no annotation support.
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 a clear purpose statement, followed by structured 'Args' and 'Returns' sections. Every sentence adds value without redundancy, making it efficient and well-organized for quick understanding.
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 low complexity (1 parameter) and the presence of an output schema (which handles return values), the description is mostly complete. It covers the purpose, parameter semantics, and return structure, but could improve by addressing behavioral transparency gaps like error cases or usage constraints.
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 0%, so the description must compensate. It explains that 'budget_id' is optional and uses a default if omitted, adding meaningful context beyond the schema. However, it does not detail what the default is or provide examples, leaving some gaps.
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 verb ('List') and resource ('all accounts in a budget with balances'), making the purpose specific and actionable. It distinguishes itself from siblings like 'get_budgets' or 'get_transactions' by focusing exclusively on accounts with balance information.
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 implies usage by specifying 'in a budget' and noting that 'budget_id' uses a default if omitted, providing some context. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_budgets' or 'create_account', and does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all months in a budget with summary data.
Useful for trend analysis — see how income, spending, and budgeting have changed over time.
Args: budget_id: Budget ID (uses default if omitted).
Returns: List of months with income, budgeted, activity, to_be_budgeted, age_of_money.
| Name | Required | Description | Default |
|---|---|---|---|
| budget_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 describes the tool as a list operation with summary data, which implies it's read-only and non-destructive. However, it lacks details on permissions, rate limits, pagination, or error conditions. The description adds some context about trend analysis but doesn't fully compensate for the missing 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: the first sentence states the core purpose, followed by usage context, then parameter and return details. Every sentence adds value without redundancy. The bullet-point style for Args and Returns enhances readability without wasting space.
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 (1 parameter, no annotations, but with output schema), the description is reasonably complete. It covers purpose, usage, parameters, and return fields. The output schema exists, so the description doesn't need to explain return values in detail. However, it lacks behavioral details like error handling or data freshness, which would be helpful given the absence of annotations.
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 0%, so the description must compensate. It explains the single parameter (budget_id) by stating it's optional ('uses default if omitted'), which adds meaningful semantics beyond the schema's technical definition. However, it doesn't clarify what 'default' means or provide format examples, leaving some ambiguity.
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 a specific verb ('List') and resource ('all months in a budget with summary data'), distinguishing it from siblings like get_month (single month) or get_budgets (budget metadata). It explicitly mentions the data fields included (income, spending, budgeting), making the scope unambiguous.
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 clear context for when to use this tool ('Useful for trend analysis — see how income, spending, and budgeting have changed over time'), which implicitly differentiates it from tools like get_month (single month detail) or get_transactions (transaction-level data). However, it does not explicitly state when NOT to use it or name specific alternatives, keeping it from a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all budgets the user has access to.
Args: include_accounts: If True, include account summaries for each budget.
Returns: List of budgets with id, name, last_modified_on, and currency format.
| Name | Required | Description | Default |
|---|---|---|---|
| include_accounts | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 mentions the tool lists budgets 'the user has access to,' which implies permission-based filtering, but doesn't cover other behavioral aspects like pagination, rate limits, or error handling. The description adds some context but lacks comprehensive behavioral details.
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 appropriately sized and front-loaded, with the core purpose stated first, followed by parameter and return details. It avoids unnecessary fluff, though the 'Args:' and 'Returns:' sections could be integrated more seamlessly into the flow.
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 low complexity (1 parameter, no nested objects) and the presence of an output schema, the description is reasonably complete. It covers the purpose, parameter effect, and return structure, though it could benefit from more behavioral context or usage guidelines to fully compensate for the lack of annotations.
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 0%, so the description must compensate. It explains the single parameter 'include_accounts' by stating 'If True, include account summaries for each budget,' adding meaningful semantics beyond the schema's title. This clarifies the parameter's effect, though it doesn't detail the format of account summaries.
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 a specific verb ('List') and resource ('budgets'), and it distinguishes from siblings by specifying 'all budgets the user has access to' rather than filtered subsets. This is precise and differentiates it from other list tools like get_accounts or get_transactions.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, compare to sibling tools like get_budget_months, or specify scenarios where this tool is preferred over others. The usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all category groups and categories with budgeted/activity/balance for the current month.
Args: budget_id: Budget ID (uses default if omitted).
Returns: Category groups with nested categories showing budgeted, activity, balance, and goal info.
| Name | Required | Description | Default |
|---|---|---|---|
| budget_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It indicates this is a read operation ('List') and specifies temporal scope ('current month'), but doesn't mention permissions needed, rate limits, pagination, or error conditions. It provides basic behavioral context but lacks operational details.
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 with clear sections (purpose, args, returns) and uses minimal sentences. The first sentence efficiently conveys the core functionality, though the 'Args' and 'Returns' labels could be integrated more seamlessly.
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 (read operation with one optional parameter) and the presence of an output schema (which handles return value documentation), the description is reasonably complete. It covers purpose, parameter semantics, and return content at a high level, though could benefit from more behavioral 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?
The description adds meaningful context for the single parameter: it explains that budget_id is optional ('uses default if omitted') and clarifies its purpose ('Budget ID'). With 0% schema description coverage and only one parameter, this adequately compensates for the schema gap.
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 action ('List all category groups and categories') and specifies the exact data returned ('budgeted/activity/balance for the current month'). It distinguishes from siblings like get_accounts or get_transactions by focusing specifically on categories with financial metrics.
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 implies usage for retrieving category data with monthly financial info, but doesn't explicitly state when to use this vs alternatives like get_month (which might provide similar data) or update_category (for modifications). No explicit exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a monthly budget summary with category breakdowns.
Args: month: Month in YYYY-MM-DD format (first of month, e.g., "2026-02-01"). Defaults to current month. budget_id: Budget ID (uses default if omitted).
Returns: Month overview: income, budgeted, activity, to_be_budgeted, age_of_money, plus per-category details.
| Name | Required | Description | Default |
|---|---|---|---|
| month | No | ||
| budget_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool's read-only nature implicitly by using 'Get' and describes the return structure, but lacks details on permissions, rate limits, error handling, or data freshness. It adds some behavioral context but not comprehensively.
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 with the purpose, followed by clear sections for Args and Returns. Every sentence adds value: the purpose statement, parameter explanations with examples, and return details. 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?
Given the tool's moderate complexity (2 parameters, no annotations, but has an output schema), the description is fairly complete. It covers purpose, parameter semantics, and return values. However, it lacks usage guidelines and some behavioral details like error cases or dependencies, leaving minor gaps.
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 0%, so the description must compensate. It adds meaningful semantics: 'month' is explained as 'Month in YYYY-MM-DD format (first of month)' with an example and default, and 'budget_id' is clarified with 'uses default if omitted.' This provides essential context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a monthly budget summary with category breakdowns.' It specifies the verb ('Get') and resource ('monthly budget summary'), but doesn't explicitly differentiate from sibling tools like 'get_budget_months' or 'get_budgets' that might also retrieve budget-related data.
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?
No guidance is provided on when to use this tool versus alternatives. While it mentions defaults for parameters, it doesn't specify scenarios for usage, prerequisites, or exclusions compared to siblings like 'get_budget_months' or 'get_budgets'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all payees in a budget.
Args: budget_id: Budget ID (uses default if omitted).
Returns: List of payees with id and name.
| Name | Required | Description | Default |
|---|---|---|---|
| budget_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 states it's a list operation, implying read-only behavior, but doesn't disclose any behavioral traits such as permissions needed, rate limits, pagination, or what happens if the budget_id is invalid. This leaves significant gaps for a tool with no 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by structured Args and Returns sections. Every sentence adds value without redundancy, making it efficient and easy to parse.
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 low complexity (single optional parameter) and the presence of an output schema (which handles return values), the description is mostly complete. It covers the purpose and parameter semantics adequately, but lacks behavioral details like error handling or usage context, which are minor gaps.
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 description adds meaningful context for the single parameter: it explains that 'budget_id' is optional and defaults to a default budget if omitted, which is not covered in the schema (0% coverage). This compensates well for the low schema coverage, though it doesn't detail the format or constraints of the budget_id.
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 verb 'List' and resource 'all payees in a budget', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_accounts' or 'get_transactions' which also list resources, though the resource type (payees) is distinct.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or compare it to other tools like 'get_transactions' that might involve payees, leaving the agent to infer usage based on context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all scheduled (recurring) transactions.
Args: budget_id: Budget ID (uses default if omitted).
Returns: List of scheduled transactions with frequency, next date, amount, payee, category.
| Name | Required | Description | Default |
|---|---|---|---|
| budget_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 states this is a list operation, implying read-only behavior, but doesn't address permissions, rate limits, pagination, or error handling. The description adds minimal context beyond the basic action.
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 sentence, followed by structured Args and Returns sections. Every sentence earns its place, with no wasted words, making it highly efficient and easy to scan.
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 low complexity (1 parameter, no nested objects) and the presence of an output schema, the description is reasonably complete. It covers the purpose, parameter semantics, and return value structure, though it lacks behavioral details like error cases or performance considerations.
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 description adds meaningful semantics for the single parameter 'budget_id', explaining it's optional and defaults to a budget if omitted. Since schema description coverage is 0%, this compensates well, though it could specify what 'default' means (e.g., active budget).
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 verb ('List') and resource ('all scheduled (recurring) transactions'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_transactions', which might also retrieve transaction data but not specifically scheduled ones.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_transactions' or clarify scenarios where scheduled transactions are needed over regular ones, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and list transactions with optional filters.
Args: budget_id: Budget ID (uses default if omitted). since_date: Only return transactions on or after this date (YYYY-MM-DD). before_date: Only return transactions before this date (YYYY-MM-DD). Server-side filter. Use with since_date for a date range, e.g. since_date="2024-02-01", before_date="2024-03-01" for all February 2024 transactions. type: Filter by "uncategorized" or "unapproved". account_id: Filter to a specific account. category_id: Filter to a specific category. payee_id: Filter to a specific payee. max_results: Maximum transactions to return (default 200).
Returns: List of transactions with date, amount, payee, category, memo, cleared status. Includes truncated flag and total_available count when results are capped.
| Name | Required | Description | Default |
|---|---|---|---|
| budget_id | No | ||
| since_date | No | ||
| before_date | No | ||
| type | No | ||
| account_id | No | ||
| category_id | No | ||
| payee_id | No | ||
| max_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 does add some useful context: it mentions server-side filtering for 'before_date,' provides a date range example, notes a default for 'max_results,' and describes the return structure including truncated flags. However, it lacks information about permissions, rate limits, or error conditions.
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 with clear sections (Args, Returns) and uses bullet points effectively. Every sentence adds value, though the date range example could be slightly more concise. Overall, it's appropriately sized for an 8-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no annotations, but with output schema), the description is quite complete. It thoroughly documents all parameters and their semantics, and while it doesn't need to explain return values (output schema exists), it usefully summarizes what's returned. The main gap is lack of behavioral context like permissions or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing clear explanations for all 8 parameters. It explains defaults (budget_id, max_results), date format examples, filtering logic (type options, server-side filtering), and practical usage examples like date ranges.
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 as 'Search and list transactions with optional filters,' which is a specific verb+resource combination. However, it doesn't explicitly differentiate this from sibling tools like 'get_scheduled_transactions' or 'get_accounts,' which prevents a perfect score.
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 no guidance on when to use this tool versus alternatives like 'get_scheduled_transactions' or 'get_accounts.' It mentions that 'budget_id' uses a default if omitted, but this is parameter-specific and doesn't constitute overall usage guidance for the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a category's name, note, or goal target.
Args: category_id: The category UUID. name: New category name. note: New category note. goal_target: New goal target in milliunits (e.g., 500000 = $500.00). budget_id: Budget ID (uses default if omitted).
Returns: Updated category details.
| Name | Required | Description | Default |
|---|---|---|---|
| category_id | Yes | ||
| name | No | ||
| note | No | ||
| goal_target | No | ||
| budget_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation (implying mutation) and shows the return format, but doesn't address important behavioral aspects like: what permissions are required, whether updates are atomic, what happens with partial updates, error conditions, or rate limits. The description adds minimal behavioral context beyond the basic operation.
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 with a clear purpose statement followed by Args and Returns sections. Each sentence earns its place, though the 'Returns' statement could be slightly more specific. The formatting with sections makes it easy to parse, though it's not perfectly front-loaded (the key purpose comes first, but details follow in sections).
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 this is a mutation tool with no annotations but with an output schema (implied by 'Returns' statement), the description covers the basic operation and parameters well. However, for a tool that modifies financial data, it lacks important context about permissions, validation rules, error handling, and transactional behavior. The presence of an output schema reduces the need to describe return values, but behavioral context remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, and it does so effectively. It explains all 5 parameters: category_id (UUID), name (new name), note (new note), goal_target (milliunits with example), and budget_id (default behavior). The goal_target example (500000 = $500.00) is particularly valuable. However, it doesn't explain null handling for optional parameters.
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 updates specific attributes of a category (name, note, goal target) with a specific verb+resource combination. It distinguishes itself from sibling tools like 'update_month_category' by focusing on category-level updates rather than month-specific category updates. However, it doesn't explicitly contrast with 'get_categories' or other update tools beyond the title difference.
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 no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer 'update_category' over 'update_month_category' or when category updates are appropriate versus other operations. The only contextual hint is the budget_id parameter default behavior, but this isn't framed as usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the budgeted amount for a category in a specific month.
Use this to move money between categories or adjust budget allocations.
Args: category_id: The category UUID to update. budgeted: New budgeted amount in milliunits (e.g., 50000 = $50.00). month: Month in YYYY-MM-DD format (first of month). Defaults to current month. budget_id: Budget ID (uses default if omitted).
Returns: Updated category with new budgeted amount, activity, and balance.
| Name | Required | Description | Default |
|---|---|---|---|
| category_id | Yes | ||
| budgeted | Yes | ||
| month | No | ||
| budget_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 correctly identifies this as a mutation operation ('Update'), describes the return format, and mentions default behaviors (month defaults to current month, budget_id uses default if omitted). However, it doesn't disclose important behavioral traits like whether this requires specific permissions, if changes are reversible, rate limits, or error conditions—significant gaps for a mutation tool.
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 with purpose statement, usage guidance, parameter explanations, and return description—all in appropriate sections. It's front-loaded with the core purpose. While efficient, the 'Args:' and 'Returns:' sections could be slightly more concise, but overall there's minimal waste.
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 this is a mutation tool with no annotations but with an output schema (which handles return values), the description provides good coverage. It explains the tool's purpose, usage, all parameters, and mentions what's returned. The main gap is lack of behavioral context around permissions, side effects, or error handling, which would be valuable for a budget update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing clear semantic explanations for all 4 parameters. It explains what each parameter represents (category UUID, budgeted amount in milliunits with example, month format with default, budget ID behavior), adding substantial value beyond the bare schema. The parameter documentation is comprehensive and helpful.
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 specific action ('Update the budgeted amount'), target resource ('for a category in a specific month'), and distinguishes it from sibling tools like 'update_category' (which likely updates category metadata rather than monthly budget allocations). The verb+resource combination is precise and unambiguous.
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 clear context for when to use this tool ('Use this to move money between categories or adjust budget allocations'), which gives practical guidance. However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the sibling tools (like whether 'update_category' serves a different purpose).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing transaction.
Args: transaction_id: The transaction UUID to update. account_id: Move to a different account. date: New date (YYYY-MM-DD). amount: New amount in milliunits. payee_name: New payee name. payee_id: New payee UUID. category_id: New category UUID. memo: New memo. cleared: New cleared status: "cleared", "uncleared", or "reconciled". approved: New approved status. flag_color: New flag color: red, orange, yellow, green, blue, purple. subtransactions: Array of subtransaction objects to convert this into a split transaction. Each item: {"amount": int, "category_id": "uuid", "memo": "text", "payee_id": "uuid", "payee_name": "text"}. Only amount and category_id are required per sub. The sub amounts must sum to the parent amount. When adding subtransactions, also provide the new parent amount if changing it. budget_id: Budget ID (uses default if omitted).
Returns: Updated transaction details.
| Name | Required | Description | Default |
|---|---|---|---|
| transaction_id | Yes | ||
| account_id | No | ||
| date | No | ||
| amount | No | ||
| payee_name | No | ||
| payee_id | No | ||
| category_id | No | ||
| memo | No | ||
| cleared | No | ||
| approved | No | ||
| flag_color | No | ||
| subtransactions | No | ||
| budget_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 mutation ('Update') but doesn't specify permission requirements, whether changes are reversible, or any rate limits. The description does add some context about split transactions and parameter defaults, but lacks comprehensive behavioral details for a mutation tool.
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 with clear sections (Args, Returns) and uses bullet-like formatting for parameters. While comprehensive, some sentences could be more concise (e.g., the subtransactions explanation is verbose). Overall, it's efficiently organized with minimal waste.
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 complexity (13 parameters, mutation operation, no annotations) and the presence of an output schema, the description is reasonably complete. It thoroughly documents parameters and mentions return values. However, it lacks behavioral context like error conditions or side effects that would be helpful for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing detailed semantic explanations for all 13 parameters. It clarifies data formats (YYYY-MM-DD, milliunits), enumerated values for 'cleared' and 'flag_color', complex requirements for 'subtransactions', and default behavior for 'budget_id'. This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('an existing transaction'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'update_category' or 'update_month_category' beyond the resource type, which prevents a perfect score.
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 no guidance on when to use this tool versus alternatives like 'create_transaction' or 'delete_transaction'. It mentions no prerequisites, constraints, or typical use cases, leaving the agent to infer usage 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0create_accountcreate_transactioncreate_transactions_bulkdelete_transactionget_accountsget_budget_monthsget_budgetsget_categoriesget_monthget_payeesget_scheduled_transactionsget_transactionsupdate_categoryupdate_month_categoryupdate_transactionScored across 15 tools
Each tool has a distinct purpose targeting specific resources and actions, such as create_account for accounts, get_transactions for listing, and update_month_category for budget adjustments. No significant overlap exists; even create_transaction and create_transactions_bulk are clearly differentiated by single vs. bulk operations.
All tool names follow a consistent verb_noun pattern, using verbs like create, get, update, and delete paired with specific nouns like account, transaction, or category. This uniformity makes the tool set predictable and easy to navigate.
With 15 tools, the server covers core budgeting operations comprehensively without being overwhelming. This count is well-suited for the domain, providing essential CRUD and query functions for accounts, transactions, budgets, categories, and payees.
The tool set offers complete coverage for personal finance management, including CRUD for accounts and transactions, budget and category management, payee handling, and month-level operations. No obvious gaps exist; agents can perform end-to-end budgeting workflows seamlessly.
Log, query, and edit expenses, budgets, and accounts in Manilo (formerly Ledgy) from any MCP-compatible AI assistant.
Personal finance, bank account, and shared memory connector for Claude, ChatGPT, Gemini Spark & more
Read your accounts, budgets and net worth, and draft changes you confirm.
Personal finance for AI agents: accounts, budgets, goals, 9-strategy debt payoff, reports. OAuth 2.1
