Integrates with RiseUp to read a month's cashflow budget and transactions, list categories, move transactions between variable, excluded, and tracking categories, and set transaction comments.
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., "@riseup-mcp what did I spend on eating out 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.
Use your own RiseUp (רייזאפ) cashflow from an AI assistant over MCP: read a month's budget and transactions, and move transactions between categories (variable, excluded, your tracking categories), as RiseUp's app does.
Unofficial. Not affiliated with RiseUp. It uses the same API as RiseUp's web app, which can change without notice. For read-only access, RiseUp publishes an official MCP server,
@riseup-oss/mcp, which uses a personal access token instead of a sign-in; this one exists because that API cannot change anything.
Everything runs on your machine. You sign in on a page this server serves, the session is saved only on your computer, and this project has no hosted backend and collects nothing. Whatever your AI client requests is passed to that client and handled under its provider's privacy terms.
Own account only.
Changes are the app's own. Every change this server makes is a request RiseUp's web app makes for the same action. It never touches bank or card connections, payments or the subscription.
The session file is secret. It holds RiseUp's session cookies, is saved with mode 0600 under ~/.config/riseup-mcp/, and must never be committed or pasted.
Related MCP server: YNAB Assistant
git clone https://github.com/tadnir/riseup-mcp.git
cd riseup-mcp
npm install
npx playwright install chromium
npm test{
"mcpServers": {
"riseup": {
"command": "npx",
"args": ["tsx", "src/main.ts"],
"cwd": "/absolute/path/to/riseup-mcp"
}
}
}For Claude Desktop, use absolute paths: "command": "/absolute/path/to/node" with "args": ["/absolute/path/to/riseup-mcp/node_modules/.bin/tsx", "/absolute/path/to/riseup-mcp/src/main.ts"].
Ask your assistant something, for example "what did I spend on eating out this month?".
While nobody is signed in, the tools answer with a link to a sign-in page this server serves on http://localhost:8768/. riseup_login returns the same link.
Open it, enter the account's mobile number, pick SMS or WhatsApp and how long to stay signed in (1 hour to 30 days), and enter the code RiseUp sends.
If your account has two-step sign-in, RiseUp sends the browser on to its sign-in provider. The page then shows that provider's page live: tap its fields and buttons, type in the box below the picture, and the page moves on by itself once RiseUp says you are signed in.
Ask again.
Your phone number, the codes and anything you type for two-step sign-in are only ever typed on that page and sent to RiseUp and its provider. The assistant only ever sees the link.
The sign-in runs in a Chromium browser on RiseUp's own site, so the second step works whatever the provider asks, without this server knowing its pages. The browser keeps its profile in RISEUP_CONFIG_DIR/browser, so a provider that remembers devices asks less next time.
RiseUp has no refresh token. While the MCP server runs it checks in with RiseUp every 5 minutes, saves the session's cookies, and signs out at the end of the length you picked. A restart picks the saved session back up if it hasn't ended in between.
Tool | What it does |
| One cashflow month as RiseUp's app reads it: envelopes (fixed, variable, tracking categories, income) with their transactions, and the excluded ones |
| One month's transactions, each with the category it is in; filter by merchant or category |
| Where a transaction can move: variable, excluded, and your tracking categories |
| Moves one transaction, or every one from its merchant, to variable, out of the cashflow, or into a tracking category; reports where it landed |
| Sets a transaction's note |
| The sign-in link, whether a session is live and until when, and sign-out |
move_transaction makes the request RiseUp's app makes for that move, picked the way the app picks it from where the transaction is and where it goes:
From | To | Request |
anywhere | a tracking category |
|
fixed | variable |
|
a tracking category | variable |
|
excluded, or any income | variable |
|
anywhere | excluded |
|
anything else | variable |
|
Moving into fixed expenses is not supported: the app asks follow-up questions for it.
Variable | Default | Meaning |
|
| Where the session and the sign-in browser's profile are saved |
|
| Address the sign-in page listens on |
|
| Its port; a free one is used if another copy holds it |
|
| The link handed out, when the page sits behind a reverse proxy. When set, the page starts with the server. |
|
|
|
| Playwright's Chromium | Another Chromium to sign in with |
| none | Also write the log here, for example |
To share one session between several clients, run a single copy on an always-on machine at home and put a stdio-to-HTTP MCP proxy in front of it, such as TBXark/mcp-proxy, with a bearer token per client. Keep it on your own network or a private VPN, never on the internet. Put the sign-in page behind your own authentication and set RISEUP_LOGIN_URL to its address (and RISEUP_LOGIN_HOST=0.0.0.0 inside a container). Its links and forms are relative, so it can sit at the root of a host or under a path whose prefix the reverse proxy strips (RISEUP_LOGIN_URL=https://mcp.example.com/riseup/login/, with the trailing slash).
Every token holder can read and change the account of whoever signed in on the page; the proxy's tokens and the RiseUp session are unrelated. For a second person, run a second copy with its own RISEUP_CONFIG_DIR, tokens and sign-in page.
The Dockerfile builds an image of the stdio server with Chromium, published as ghcr.io/tadnir/riseup-mcp from master, with the session in /data and the page on port 8768. Run it with docker run -i, or use it as a base for an image that adds your MCP proxy.
The sign-in page answers only to localhost, 127.0.0.1 and the host in RISEUP_LOGIN_URL, and each form carries a per-process token. Anyone who can open the page can sign in or out, so keep it on loopback or behind your own authentication.
One cashflow month as RiseUp's app reads it: its envelopes (fixed, variable, tracking categories, income) with planned amounts and their transactions, and the transactions excluded from the cashflow.
| Name | Required | Description | Default |
|---|---|---|---|
| month | Yes | Cashflow month, YYYY-MM. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden. It does disclose the shape of what comes back (fixed/variable/tracking/income envelopes, planned amounts, included and excluded transactions), which is genuine value. However it says nothing about read-only nature, auth/session requirements, or error behavior for invalid months.
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 front-loaded sentence that leads with the core resource ('One cashflow month...') and then details its contents. Dense but no filler; slightly run-on with the trailing 'excluded from the cashflow' clause, but efficient overall.
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?
With no output schema, the description must explain return values, and it does a reasonable job describing the envelope/transaction structure. It remains incomplete on session prerequisites and failure modes for a read tool with no annotations, but the core content picture is present.
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% and the single month parameter is already documented as 'Cashflow month, YYYY-MM.' The description only echoes 'one cashflow month' without adding format, range, or default semantics, so nothing is added beyond the schema — baseline 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 names a specific resource (a cashflow month as RiseUp renders it) and enumerates its constituents: envelopes by type, planned amounts, their transactions, and excluded transactions. An agent can tell this is a budget-month read distinct from the transaction-level siblings, though it never states a verb or explicitly distinguishes itself from list_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?
There is no when-to-use guidance and no named alternative. The agent cannot tell from the text whether this should be preferred over list_transactions or list_categories when it wants cashflow data, or what prerequisites (login/session) apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The categories a transaction can be moved to with move_transaction: variable, excluded, and the user's tracking categories (with their ids), as of the given month.
| Name | Required | Description | Default |
|---|---|---|---|
| month | Yes | Cashflow month, YYYY-MM. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does reasonably well: it discloses the returned contents (variable, excluded, tracking categories with their ids) and the temporal scoping ('as of the given month', implying the result changes month to month). It omits the auth/session requirement implied by riseup_login siblings and does not explicitly state the operation is read-only.
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 front-loaded sentence with no filler; the enumeration and month scoping are the payload. Slightly awkward fragment phrasing costs it the top score, but nothing is redundant.
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 one-parameter, read-only lookup with no output schema, the description conveys enough: what comes back, what the month controls, and which sibling consumes the result. Remaining gaps (auth requirements, whether non-tracking categories carry ids, id stability) are minor for this complexity level.
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 'month' parameter (YYYY-MM, Cashflow month) is already fully documented. The description only reinforces that the answer is scoped to that month; it adds no format or edge-case detail beyond the schema, so the baseline 3 applies.
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?
Names the exact resource (the categories a transaction can be moved to), enumerates their kinds (variable, excluded, tracking categories with ids), and ties them to the consuming sibling tool move_transaction. It is a noun phrase rather than a verb+resource, but an agent can still distinguish it from list_transactions or get_budget without opening a schema.
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?
By naming move_transaction as the consumer, it makes the use case clear: fetch this list to discover valid category values before moving a transaction. It gives no explicit when-not conditions, prerequisites, or alternative tools, so it falls short of the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One cashflow month's transactions, each with the category it is in (variable, fixed, excluded, income, or a tracking category), its merchant, date and amount.
| Name | Required | Description | Default |
|---|---|---|---|
| month | Yes | Cashflow month, YYYY-MM. | |
| search | No | Only transactions whose merchant name contains this text (case-insensitive). | |
| category | No | Only transactions in this category: variable, fixed, excluded, income, or a tracking category's name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the shape of each returned item (category, merchant, date, amount), but says nothing about pagination, ordering, result limits, or authentication requirements.
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 well-formed sentence with no filler, front-loading the scope (one month) before the field list. Slightly dense but nothing wasted.
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?
No output schema exists, so the description must cover return values, and it does list the per-transaction fields. However, for a list tool with no annotations it omits ordering, pagination, and any auth/session context, leaving gaps an agent would want.
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 documents month, search, and category fully. The description echoes the category value set (variable, fixed, excluded, income, tracking category), adding only marginal value beyond the schema, so the baseline 3 applies.
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 conveys a specific resource and scope: one cashflow month's transactions, enumerated with their fields. An agent can tell this is a per-month list/read tool, though it never names a verb or explicitly distinguishes itself from siblings like move_transaction or set_transaction_comment.
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 when-to-use guidance, no mention of prerequisites (e.g., an active session given the riseup_login/session_status siblings), and no routing to alternatives. The month scope is the only implicit usage signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a transaction to variable expenses, out of the cashflow (excluded), or into a tracking category; with applyTo=merchant, RiseUp applies it to the merchant's transactions too. Changes the user's RiseUp account. Returns where the transaction is afterwards.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Where to: "variable", "excluded", or a tracking category's id or name from list_categories. | |
| month | Yes | The cashflow month the transaction is in, YYYY-MM. | |
| applyTo | No | transaction: this one only. merchant: this and future transactions from the same merchant, as RiseUp's app offers. | |
| transactionId | Yes | transactionId from list_transactions or get_budget. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does considerable work: it names the mutation ('Changes the user's RiseUp account'), discloses the non-obvious merchant-wide side effect of applyTo=merchant, and states the return value. It still omits reversibility and whether authentication/permissions are required, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences that front-load the action and its destinations, with no filler. The semicolon-joined clauses pack a lot in, which is efficient if slightly heavy for quick scanning.
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 mutation tool with no annotations and no output schema, the description covers the action, side effects, and result state. The presence of riseup_login/riseup_session_status siblings implies auth handling, so the main remaining gap is reversibility of the change.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented in the input schema; the description largely restates the `to` and `applyTo` semantics. It adds little syntax or format detail beyond what the schema provides, so the baseline 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 gives a specific verb ('Move a transaction') and enumerates the exact destination states: variable expenses, excluded from cashflow, or a tracking category. None of the sibling tools (list_transactions, list_categories, set_transaction_comment) performs this action, so the agent can identify it immediately.
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?
It explains the semantics of the `to` and `applyTo` values, which implies when each option applies, but never states when to prefer this tool or when not to use it. There is no explicit routing against alternatives or prerequisites (e.g. needing a valid session first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the link where the user signs in to RiseUp (phone number, codes and two-step sign-in are done on that page, never in the chat). Returns the status when already signed in.
| 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 the full burden. It usefully discloses the dual behavior (returns a link, or status if already signed in), but says nothing about link lifetime, single-use, or what the returned status looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the action and immediately followed by the security-relevant constraint. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description covers what the agent needs: what is returned and where authentication actually happens. Only the conditional return format remains unspecified, a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so there is nothing to document and the baseline is 4. The description correctly implies the tool takes no input.
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?
States a specific verb and resource: 'Get the link where the user signs in to RiseUp.' It also distinguishes its two outcomes (link vs. status when already signed in), though it doesn't explicitly name riseup_session_status as the sibling that owns the pure status check.
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?
Gives clear context for use (when the user needs to sign in) and a strong exclusion: credentials, codes, and two-step sign-in happen on that page, never in the chat. No alternative tool is named for the already-signed-in case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sign out of RiseUp here: end the session and forget it.
| 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 the full burden. "End the session and forget it" does disclose the core behavior — the session is terminated and not persisted — which is useful. However, it says nothing about whether authentication is required first, whether the server-side token is revoked, or what happens if called with no active session.
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?
One short, front-loaded sentence that puts the action first and the effect second. "here" is mild filler, but nothing else is wasted.
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 zero-param, no-output tool this is close to sufficient, but with no annotations and no output schema the description could reasonably add that no further authenticated calls succeed until riseup_login is called again. It stops just short of fully closing the loop.
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 tool takes zero parameters, so there is no parameter semantics to document; per the baseline for 0 params this is a 4. The description correctly implies no arguments are needed.
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?
Specific verb ("Sign out") plus resource ("RiseUp" session), and the effect is stated. It is trivially distinguishable from siblings riseup_login and riseup_session_status, so an agent can route correctly without opening any schema.
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?
"Sign out of RiseUp here" implies the usage context (you have an active session you want to terminate), but there is no explicit when-to-use/when-not statement and no named alternative such as riseup_session_status for checking state. Implied guidance only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Whether this server is signed in to RiseUp, since when, until when, and the sign-in link when it is not.
| 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 the full burden and does disclose real behavioral detail: it is a state-inspection read, it exposes a since/until window, and the sign-in link is returned conditionally (only when not signed in). It does not explicitly state read-only semantics or that no side effects occur, which is the remaining gap.
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?
One sentence, front-loaded with the core state question and then the returned attributes; every clause adds information and none is wasted.
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?
Since there is no output schema, the description must convey the response shape, and it does: sign-in status, start, expiry, and the link on failure. Only minor detail is missing (e.g. that the window represents token/session validity and what a signed-out record contains).
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 tool takes zero parameters, so there is nothing for the schema or description to document beyond the empty object; baseline 4 applies.
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?
States the specific resource (this server's RiseUp sign-in session) and the exact payload it reports: signed-in state, validity window, and the sign-in link when signed out. That clearly separates it from riseup_login and riseup_logout, though the verb is implicit ('whether...since when...until when') rather than an explicit 'returns/reports'.
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 statement of when to call this versus riseup_login or other siblings. Usage is only implied: an agent can infer it is the pre-flight check for auth state and the place to get a sign-in link, but there is no when/when-not guidance or named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the note on a transaction in RiseUp. Changes the user's RiseUp account.
| Name | Required | Description | Default |
|---|---|---|---|
| comment | Yes | The note; empty clears it. | |
| transactionId | Yes | transactionId from list_transactions or get_budget. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only signals that this is a mutation; it does not say what permissions are needed, whether the write is idempotent, whether it overwrites an existing note beyond the schema's 'empty clears it', or what confirmation is returned. 'Changes the user's RiseUp account' is too vague to be useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, appropriately sized and front-loaded with the core action. However, the second sentence ('Changes the user's RiseUp account') restates the setting of a note on RiseUp rather than earning its place with new information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and no error/permission context, the description is too thin. It does not tell the agent what a successful call yields or what happens when transactionId is invalid, leaving gaps that structured fields cannot fill.
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%, and the schema already explains that 'comment' empty clears the note and where transactionId comes from. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.
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?
States a specific verb and resource ('Set the note on a transaction'), which is distinguishable from siblings like list_transactions and get_budget. The trailing sentence 'Changes the user's RiseUp account' is vague and over-broad but does not obscure the core action.
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 versus move_transaction or the read tools, and no mention of prerequisites or context. An agent must infer usage entirely from the name and sibling list.
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.
v0.1.0get_budgetlist_categorieslist_transactionsmove_transactionriseup_loginriseup_logoutriseup_session_statusset_transaction_commentScored across 8 tools
Most tools have clearly distinct purposes (session vs. read vs. modify). The main overlap is between get_budget and list_transactions, since both return a month's transactions with categories, though descriptions differentiate their framing (envelopes/planned amounts vs. flat transaction list).
The data tools use a clean verb_noun pattern (get_budget, list_transactions, move_transaction), but the three session tools are prefixed riseup_ (riseup_login, riseup_session_status, riseup_logout), creating two conventions. Readable, but not uniform.
Eight tools is well within the ideal range and each earns its place: session lifecycle, budget/transaction reads, category lookup, and two account-mutating actions. No redundancy that inflates the count.
Covers the session lifecycle plus the core read (budget, transactions, categories) and write (move, comment) operations on transactions. Gaps remain, e.g. creating transactions or editing planned/budget amounts, but core workflows are functional.
Ask your AI about your own accounts, debts, budgets and goals. OAuth sign-in, read-only by default.
The budget app your AI agent can use. Check budgets and log spending, with no bank logins.
Read-only banking and personal finance for AI agents: accounts, transactions, spending, budgets.
Household finance memory, budgets, transactions, and monthly reviews for AI assistants.
