Provides tools for listing accounts, retrieving transactions, adding new transactions, and viewing budget balances on an Actual Budget server.
Click on "Install 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., "@actual-mcp show me my budget balances"
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.
An MCP (Model Context Protocol) server that bridges AI/LLM applications to Actual Budget. Exposes your budget data as MCP tools for use with any MCP-compatible client.
Tool | Description |
| List all accounts (name, type, balance, off-budget/closed flags) |
| Get recent transactions for an account (sorted newest-first) |
| Create a new transaction and commit it to the server |
| List budget categories with group and income flag |
Related MCP server: YNAB MCP Server
Python 3.12+
An Actual Budget server (self-hosted)
uv (recommended) or pip
# Clone the repo
git clone https://github.com/slushpupie/actual-mcp
cd actual-mcp
# Install dependencies
uv sync
# Configure your Actual server credentials
cp .env.example .env
# Edit .env with your server URL, password, and budget IDSet these environment variables (or add them to a .env file):
Variable | Required | Description |
| Yes | URL of your Actual Budget server (e.g. |
| Yes | Your Actual server password |
| Yes | The budget ID or unique budget name to operate on |
uv run python mcp_server.pyThis starts an MCP server over stdio, ready to connect to an MCP client.
make build
make runOr manually:
docker run -i --rm \
-e ACTUAL_SERVER_URL=http://host.docker.internal:5006 \
-e ACTUAL_PASSWORD=your_password \
-e ACTUAL_BUDGET_ID=your_budget_id \
actual-mcp# Run tests
uv run python test_mcp_mock.py
# Run with uv
uv run python mcp_server.pyAdds a new transaction to an account.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| notes | No | ||
| amount | Yes | ||
| account_id | Yes | ||
| payee_name | Yes | ||
| category_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description only says 'adds a new transaction'. Lacks details on side effects, permissions, or constraints (e.g., date format, amount units).
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?
Single sentence with no wasted words, but missing essential context for a tool with 6 parameters and no other documentation.
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 6 parameters with no schema descriptions and no annotations, description is too sparse to be complete. Output schema exists but not mentioned.
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%, and description adds no meaning to parameters. Agent must infer from names and types only.
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?
Description clearly states verb 'Adds' and resource 'transaction', distinguishing it from sibling tools that list, get, or retrieve balances.
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 vs alternatives. Siblings are read tools, but no explicit when-not or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns budget category balances.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states 'returns balances' without indicating that the operation is read-only or safe. This is minimal transparency.
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 a single sentence, which is concise. However, it could be more informative without sacrificing brevity.
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 there are no parameters and an output schema exists, the description is adequate but lacking context for when to use the tool. It does not explain the scope of balances returned.
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 input schema has zero parameters, so the description does not need to elaborate on parameters. The baseline is 4, and the description does not detract, though it could clarify what 'balances' refers to.
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 states it returns budget category balances, which clearly indicates the resource and action. However, it does not specify whether balances are current or for a specific period, and it could more explicitly differentiate from sibling 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?
No guidance on when to use this tool versus sibling tools like list_accounts or get_transactions. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets recent transactions for a specific account.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| account_id | Yes |
| 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 must carry the full burden. It lacks details on what 'recent' means (e.g., time range), ordering, pagination, or any behavioral traits. The description is vague.
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 a single sentence, which is concise but lacks structure. It could be expanded without becoming verbose to include key details.
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?
Despite having an output schema (which covers return values), the description omits critical contextual details like time range and pagination. With 0% schema coverage and no annotations, the description is insufficient for a tool with 2 parameters.
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%, yet the description only implies account_id ('for a specific account') and does not mention the limit parameter. It adds minimal meaning beyond the 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 ('gets') and resource ('recent transactions') and includes the constraint 'for a specific account.' It distinguishes from siblings like list_accounts (accounts) and add_transaction (adding) effectively.
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. It does not mention when not to use it or provide context about filtering by account versus using list_accounts or get_budget_balances.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all accounts in the budget.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 indicates a read operation but does not disclose pagination, limits, or other behavioral traits beyond 'lists all accounts'.
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?
Single sentence, front-loaded with verb and resource, no extraneous words. Highly efficient.
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 simple, parameterless list tool with an output schema, the description is complete. It clearly states the purpose and scope, and sibling tools are distinct.
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 zero parameters and 100% schema coverage, the description needs to add no parameter details. The phrase 'all accounts' already implies no filtering, which is sufficient.
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), the resource (accounts), and the scope (all in budget). It distinguishes from siblings which deal with transactions and balances.
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 when a list of all accounts is needed. Sibling tools are clearly different, but no explicit when-not or alternative guidance is given. Context is clear but not comprehensive.
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. Dates show when Glama detected each change.
v0.1.0add_transactionget_budget_balancesget_transactionslist_accountsEach tool targets a distinct resource and action: listing accounts, getting transactions, adding transactions, and retrieving budget balances. There is no overlap.
All tool names follow a consistent verb_noun snake_case pattern (e.g., list_accounts, get_transactions), making it easy to predict and remember.
With 4 tools, the set is well-scoped for a budgeting MCP server, covering the core operations without being too sparse or overwhelming.
The tools cover listing accounts, viewing transactions, adding transactions, and checking budget balances. However, update and delete operations for transactions are missing, which is a minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Log, query, and edit expenses, budgets, and accounts in Manilo from any MCP-compatible AI assistant.
Personal finance for AI agents — onboard, import statements, categorize & budget over MCP.
Log, query, and edit expenses, budgets, and accounts in Ledgy from any MCP-compatible AI assistant.
Log, query, and edit expenses, budgets, and accounts in Manilo (formerly Ledgy) from any MCP-compatible AI assistant.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/slushpupie/actual-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
