This MCP server connects an AI assistant to a Dough personal finance instance, enabling read queries and optional write operations on budgets, transactions, accounts, and more.
Read tools (any API key):
dough_summary: Compact snapshot of total balance, monthly income/spending, budgeted amount, and Ready to Assign funds.
dough_accounts: List accounts with balances (optionally include closed accounts).
dough_transactions: Browse transactions (newest first, up to 500) with filters for month, account, category, and keyword search.
dough_budget: Full monthly budget — income, total budgeted, Ready to Assign, age of money, and per-category budgeted/activity/available.
dough_net_worth: Current net worth by account type (checking, savings, investments, debts) plus historical snapshots.
dough_bills: Recurring bills with amounts and due days.
dough_subscriptions: Subscriptions with amounts and due days.
dough_savings_goals: Active savings goals with targets and saved amounts.
Write tools (require write-scoped API key):
dough_auto_assign_preview: Preview auto-assign funding for a given month.
dough_auto_assign_apply: Apply auto-assign using a strategy (underfunded, last assigned, or last spent).
dough_budget_assign: Set a category's budgeted amount for a specific month.
dough_update_transaction: Edit an existing transaction's fields.
dough_delete_transaction: Delete a transaction and reverse its balance effect.
Security: The API key stays on the user's machine. A read-only key is safe for query-only use; write tools return a 403 error without write scope.
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., "@dough-mcp show my current balance and recent transactions"
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.
Dough MCP server
Read and write your Dough finances from Claude.ai and Claude Code. Covers every part of Dough: accounts, transactions, budget, bills, subscriptions, savings goals, debts, investments and income, all read and write. It runs over stdio for Claude Code, or behind an OAuth 2.1 login so it can be added to Claude.ai as a custom connector.
Dough is a standalone self-hosted budget app with its own ledger (bank-synced or manual). It is not a YNAB frontend: Dough's data is corrected through these tools or Dough's own UI, never in YNAB.
dough (web app) ── /api/v1/* (API-key auth)
▲ HTTPS + Bearer key
dough-mcp ── stdio (Claude Code) ──or── HTTP + OAuth 2.1 (Claude.ai connector)The server never sees your database. It calls the Dough HTTP API with an API key you supply through the environment, so the key stays on your machine and nothing about your ledger is exposed on the internet.
Related MCP server: LunchMoney MCP Server
43 tools across every part of Dough. Read tools work with any key; write tools need a key minted with --scopes write and return 403 otherwise.
Read — dough_summary, dough_accounts, dough_transactions, dough_budget, dough_net_worth, dough_bills, dough_subscriptions, dough_savings_goals, dough_debts, dough_investments, dough_income
Transactions — create, update and delete, including pending card holds and per-transaction budget exclusion
Budget — auto-assign preview and apply, assign a category, move money, snooze / unsnooze, set targets
Manage — create / update / delete for bills, subscriptions, savings goals, accounts, categories and income, plus update and reorder for debts and investments
Settings, Connectors, Add custom connector, and paste the MCP URL of your deployment, for example:
https://dough-mcp.example.com/mcpLeave client ID and secret blank. The OAuth 2.1 login in front (auth-server.cjs) handles registration and sign-in, and issues the token.
Over HTTP, with the fixed token the login also accepts:
claude mcp add --transport http dough https://dough-mcp.example.com/mcp \
--header "Authorization: Bearer $(cat ~/.config/dough-mcp/token)" --scope userOr over stdio, with DOUGH_API_URL and DOUGH_API_KEY set in the environment.
git clone git@github.com:rollecode/dough-mcp.git
cd dough-mcp
npm install && npm run build # dist/ is committed; rebuild only when changing src/Configure via environment:
DOUGH_API_URL — base URL of the Dough instance, e.g. https://dough.example.com
DOUGH_API_KEY — an API key minted in the Dough repo (see below)
In the Dough repo, on the host that owns the database:
npx tsx scripts/create-api-key.ts --name "dough-mcp" --scopes writeThe key is printed once. Use --scopes read for a query-only key. See Dough's docs/public-api.md for details.
All accounts with balances. Set include_closed to also return closed accounts.
| Name | Required | Description | Default |
|---|---|---|---|
| include_closed | No | Include closed accounts (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility. It does not disclose whether the operation is read-only, requires authentication, or has side effects. The behavior is implied as a list, but not explicitly stated.
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 composed of two concise sentences. The first sentence provides the main purpose, and the second adds the parameter detail. No unnecessary 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 simple list tool with one optional parameter and no output schema, the description is adequate. It explains the result and the parameter, but could be more precise about what 'accounts with balances' means (e.g., fields returned, default filter).
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 single parameter include_closed is described in the schema with equal clarity. The description adds minimal extra value ('also return closed accounts'), but since schema coverage is 100%, baseline is 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 it returns all accounts with balances, which distinguishes it from sibling tools like dough_bills or dough_transactions. However, it does not explicitly state the action (e.g., 'list'), but it is still clear.
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 guidance for the include_closed parameter but does not specify when to use this tool versus alternatives like dough_summary. No contextual usage advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recurring bills with amount and due day of month.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states the data contained (amount, due day) but does not disclose whether the operation is read-only, requires authentication, or has side effects. This is insufficient for an agent to understand the tool's impact.
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, highly concise, and front-loaded with the core concept. Every word is necessary and informative, achieving maximum efficiency.
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 parameters, no output schema, and no annotations, the description is moderately complete for a simple listing tool. It identifies the core subject and key fields, but lacks behavioral context (e.g., is it a list or a form?) and any usage instructions. Sibling tools provide some context but the description itself is minimal.
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, and schema description coverage is 100%. The description adds no parameter info because none exist. With no parameters, a baseline of 4 is appropriate; the description is adequate for this case.
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 identifies the tool as related to recurring bills with amount and due day of month. It effectively distinguishes from siblings like dough_transactions (one-time) and dough_subscriptions (recurring payments with different semantics). However, it lacks a verb to specify the action (list, create, etc.), leaving some ambiguity.
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 explicit guidance on when to use this tool versus alternatives. While the description implies it's for viewing recurring bills, it does not mention when to prefer it over dough_subscriptions or dough_transactions. Missing context on prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The month's budget: income, total budgeted, Ready to Assign, age of money and every active category's budgeted / activity / available.
| Name | Required | Description | Default |
|---|---|---|---|
| month | No | Month as YYYY-MM; defaults to the current month |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only describes returned data, not behavioral traits like read-only nature, authentication needs, or side effects. For a tool returning sensitive budget data, 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?
A single sentence that front-loads the key information. While concise, it could be improved by starting with an action verb (e.g., 'Retrieve the month's budget...'). No unnecessary 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 no output schema, the description lists included fields but lacks details on data structure (array vs object), pagination, or limits. For a tool likely returning nested category data, this is moderately complete but has 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 coverage is 100% with clear parameter description ('Month as YYYY-MM; defaults to the current month'). The description adds no additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.
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 resource (budget for a month) and specific fields (income, total budgeted, Ready to Assign, age of money, etc.). It distinguishes from sibling tools like dough_transactions or dough_summary by specifying budget-specific 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?
The description implies usage for viewing monthly budget details but does not provide explicit guidance on when to use this tool versus alternatives like dough_summary or dough_accounts. No 'when not to use' 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.
Current net worth by kind (checking, savings, investments, debts) plus the snapshot history.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the data returned but does not state that the tool is read-only or any other behavioral traits. It could be more explicit about safety.
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 key information, no superfluous words. Every word earns its place.
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 tool with no parameters and no output schema, the description sufficiently conveys the main value. It could mention that data is aggregated from accounts, but it's reasonably complete.
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?
There are zero parameters, so baseline is 4. The description adds meaningful context about what the output contains (by kind and history), which is useful beyond the empty 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 retrieves current net worth broken down by kind (checking, savings, investments, debts) and also provides snapshot history, making it distinct from sibling tools like dough_accounts or dough_summary.
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 the tool is for net worth queries but gives no explicit guidance on when to use it versus alternatives (e.g., dough_summary) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Active savings goals with target and derived saved amount.
| Name | Required | Description | Default |
|---|---|---|---|
| month | No | Month as YYYY-MM; defaults to the current month |
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 fails to state that the tool is read-only, whether it returns a list or a single item, or any side effects. The minimal info ('target and derived saved amount') does not cover key behaviors like authentication, pagination, 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 very short (one sentence), but it lacks essential information. Conciseness should not come at the expense of clarity; here, the tool is under-specified to the point of being unhelpful.
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 absence of output schema and annotations, the description must provide more context. It fails to explain what the output format is, what 'derived saved amount' means, or any limitations. This is inadequate for an agent to correctly use the 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?
Schema coverage is 100%, so the single parameter 'month' is well-documented in the schema itself (format, default). The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
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 is a noun phrase ('Active savings goals with target and derived saved amount') rather than a verb phrase stating the tool's action. It does not explicitly say what the tool does (e.g., list, retrieve, or fetch). This vagueness makes it hard for an AI agent to understand the tool's purpose.
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 its siblings (e.g., dough_accounts, dough_transactions). Agents cannot distinguish the context for using savings goals over other financial data tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Subscriptions with amount and due day of month.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions the data fields. It does not disclose read-only nature, access requirements, or any side effects.
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 short phrase, concise and front-loaded. While efficient, it could include more context without being verbose.
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, no output schema, and no parameters, the description should clarify the operation (e.g., list or retrieve). It is 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?
No parameters exist, so schema coverage is 100% trivially. Baseline 3 applies; description adds no extra meaning for 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?
Description uses a noun phrase 'Subscriptions with amount and due day of month' rather than a verb, so it does not explicitly state the action (e.g., list, get). It is somewhat clearer than a tautology but lacks a specific verb-resource combination.
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 siblings like dough_bills or dough_transactions. No alternatives or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compact financial snapshot: total balance and this month's income, spending, budgeted and Ready to Assign.
| Name | Required | Description | Default |
|---|---|---|---|
| month | No | Month as YYYY-MM; defaults to the current month |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses output content but lacks details on scope (e.g., whether it aggregates all accounts), caching, or error behavior. It adequately indicates a read 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 a single, efficient sentence with no fluff. It effectively communicates the tool's purpose, though it could be slightly more structured (e.g., listing fields explicitly).
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 output schema, the description lists key output items (total balance, income, spending, budgeted, RTA) but does not specify the structure (e.g., if it's a flat object or nested). It is adequate but not fully detailed.
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 already describes the month parameter. The description adds minor context ('this month's') but no additional semantic value 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 it provides a 'compact financial snapshot' with specific elements (total balance, income, spending, budgeted, Ready to Assign), distinguishing it from sibling tools that target individual areas like accounts, bills, or budget.
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 the tool is for a quick overview but does not explicitly mention when to use it versus alternatives like dough_accounts or dough_budget. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transactions newest first, with optional filters.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search payee and memo | |
| limit | No | Max rows, 1-500 (default 50) | |
| month | No | Month as YYYY-MM; defaults to the current month | |
| category | No | Only this category name | |
| account_id | No | Only this account's transactions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions sort order ('newest first') but does not specify read-only nature, pagination, rate limits, or other key behaviors. It adds minimal context beyond what the parameter schema already implies.
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 concise sentence that front-loads the key information (sort order). It is efficient with no wasted words, though it could be slightly expanded for completeness without losing 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 5 parameters with full schema descriptions and no output schema, the description should provide more context about the return format or behavior. It only covers sort order and filter optionality, leaving the agent to infer other aspects like available fields or response structure.
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 baseline is 3. The description states 'optional filters' which is already clear from no required parameters in schema. It does not add new semantic meaning for any parameter beyond the schema's own 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 that the tool retrieves transactions, sorted newest first, with optional filters. While it lacks an explicit verb like 'list' or 'get', the phrase 'transactions newest first' implies a retrieval operation. The purpose is easily understood and distinguishes from sibling tools which cover other resources.
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?
There is no guidance on when to use this tool versus alternatives. Sibling tools like dough_accounts or dough_budget cover different resources, so usage is implied by domain, but no explicit when/when-not or alternatives are provided.
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.0dough_accountsdough_billsdough_budgetdough_net_worthdough_savings_goalsdough_subscriptionsdough_summarydough_transactionsEach tool targets a distinct financial data domain (accounts, bills, budget, net worth, savings goals, subscriptions, transactions) with no overlapping purposes. Descriptions clearly differentiate them.
All tools follow a consistent 'dough_' prefix with a plural noun representing the resource (e.g., dough_accounts, dough_bills). This pattern makes it predictable for an agent.
With 8 tools covering core personal finance areas, the count feels well-scoped for a finance data provider. Each tool serves a distinct purpose without redundancy.
The tool set covers major financial categories: accounts, bills, budget, net worth, savings, subscriptions, and transactions. For a read-only data access server, it offers a comprehensive snapshot without obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Query your real net worth, spending, transactions, budgets and portfolio from any MCP client.
Personal finance for AI agents — onboard, import statements, categorize & budget over MCP.
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rollecode/dough-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
