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., "@finance-mcp show my spending summary for last 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.
Local, privacy-first access to your bank and credit-card transactions for Copilot, backed by SimpleFIN. It pulls transactions from your institutions into a normalized on-disk cache and exposes them to Copilot as an MCP server. Nothing leaves your machine except the single HTTPS call to SimpleFIN — no third-party SaaS sees your data, and no fake/sample data is ever shown.
All of these institutions are supported by SimpleFIN (verified against its live institution search): Target credit card, Nordstrom Card Services, Amazon Chase card (via Chase Bank), Fidelity credit card, Fidelity NetBenefits (via Fidelity Investments), Charles Schwab, and Cyprus Credit Union. SimpleFIN costs ~$15/yr flat with no per-account billing, and you hold the access token.
Related MCP server: simplefin
The SimpleFIN access URL embeds Basic-Auth credentials that can read your transactions. It is therefore stored outside this project directory (this repo may live in a synced folder like Dropbox):
Access URL + transaction cache live in ~/.finance-mcp/ (dir 0700, files 0600).
Override the location with FINANCE_MCP_HOME.
The access URL may instead be supplied via the SIMPLEFIN_ACCESS_URL env var
(takes precedence over the saved file), so it never has to touch disk.
Get a SimpleFIN setup token: sign up at https://bridge.simplefin.org/ and generate one (it is a base64 string).
Claim it (one-time — the token dies after a successful claim):
uv run finance-mcp claim # prompts for the token
# or: uv run finance-mcp claim <SETUP_TOKEN>The resulting access URL is saved to ~/.finance-mcp/access_url (mode 0600).
Pull your transactions into the cache:
uv run finance-mcp sync --days 120uv run finance-mcp accounts # balances per account
uv run finance-mcp transactions --search grocery # search the full archive
uv run finance-mcp transactions --start 2026-01-01 --account <id> --json
uv run finance-mcp summary --group-by month # inflow/outflow aggregation
uv run finance-mcp summary # defaults to group-by category, excludes transfers
uv run finance-mcp networth # net-worth total per snapshot date
uv run finance-mcp stats # archive size + date coverage
uv run finance-mcp categorize # seed default rules + show coverage
uv run finance-mcp uncategorized # top still-uncategorized merchants
uv run finance-mcp rules list # show categorization rules
uv run finance-mcp rules add --pattern "trader joe" --category Groceries
uv run finance-mcp rules rm --rule-id <id> # remove a rule
uv run finance-mcp set-category <txn_id> Travel # pin one transaction's category
uv run finance-mcp sync --days 120 # refresh from SimpleFIN
uv run finance-mcp subscriptions detect # save recurring charges as a tracked list
uv run finance-mcp subscriptions # audit: did tracked bills post? + new candidates
uv run finance-mcp subscriptions mark --name Sketch --lifecycle canceled --effective 2026-04-01
uv run finance-mcp web # local read-only review UI in the browsersubscriptions detect scans the archive for recurring monthly charges and saves
them into the budget config so your subscriptions become a durable list rather
than something re-inferred on every run; it is idempotent and skips merchants
already tracked. subscriptions (audit) then reports any tracked bill that did
not post in its cycle — a possible billing problem or cancellation — and surfaces
untracked recurring merchants as candidates to add. A saved subscription needs
no envelope budget: a match keyword pins it to its merchant. Detection is a
heuristic starting point — review the saved list and remove any false positives.
subscriptions mark is the cancellation watch: after you cancel (or try to
cancel) a subscription, mark it canceling (attempted, unconfirmed) or
canceled (confirmed) with the effective date. The audit then stops reporting
its expected charges as missing — the absence is what you wanted — and instead
warns you if a charge posts on or after that date, so a cancellation that didn't
take is surfaced rather than silently billed. --lifecycle active reactivates a
bill. Recurring bills and subscriptions are one list: anything in the budget's
recurring calendar can be watched this way.
SimpleFIN caps a request at 90 days and expects <=24 requests/day, so sync
chunks long ranges into <=89-day windows and you should rely on the archive for
day-to-day queries rather than re-syncing constantly. Any SimpleFIN warnings or
errors (errors/errlist) are always surfaced.
finance-mcp web starts a local, read-only web UI for reviewing the archive and
the budgeting reports without leaving the terminal-driven workflow:
uv run finance-mcp web # serves http://127.0.0.1:8765/
uv run finance-mcp web --port 9000 # pick a different portIt binds to 127.0.0.1 only by default because it serves private financial data
(override with --host only if you understand the exposure). The request Host
header is always checked against an allowlist, so a 127.0.0.1 bind is not
defeated by DNS-rebinding; to reach a non-loopback or wildcard bind from another
device, name that device-facing host with --allow-host (every other Host is
refused). Every page is backed by the same functions the MCP server exposes, so
the browser view and Copilot see identical data, and nothing is mutated — there
is no sync or confirm action in the UI. Tabs cover accounts, transactions,
spending, net worth, transfers, and the burn-down / forecast / allocation /
subscription reports; each view also exposes the raw JSON it rendered.
Every sync does two things locally, both in ~/.finance-mcp/ (mode 0600):
updates cache.json — the latest normalized snapshot, and
folds the data into archive.db, a SQLite database that is the durable,
searchable, multi-year history.
The archive is append-only: transactions are upserted by their stable
SimpleFIN id (a pending charge is later promoted to posted without duplicating),
first_seen is preserved, and nothing is ever deleted — so a transaction stays
in the archive even after it ages out of SimpleFIN's rolling window. Each sync
also records a balance snapshot per account, which is what powers
networth / net_worth_history trends over time.
All read commands and MCP tools serve from archive.db (falling back to
cache.json only before the first sync on this version). You can also query it
with any SQLite tool:
sqlite3 ~/.finance-mcp/archive.db \
"SELECT posted, amount, description FROM transactions ORDER BY posted_ts DESC LIMIT 10;"The server runs over stdio and exposes these tools:
Tool | Network? | Purpose |
| no | accounts + balances + institution |
| no | just balances and as-of dates |
| no | filter by date / account / search / amount (includes category) |
| no | inflow/outflow grouped by category, account, org, or month |
| no | category coverage + spend-by-category breakdown |
| no | the active substring → category rules |
| no | add a rule (optionally flag matches as transfers) |
| no | delete a rule by id |
| no | pin one transaction's category (survives sync) |
| no | total balance per snapshot date (net-worth trend) |
| no | archive size + earliest/latest transaction |
| yes | refresh the cache + archive from SimpleFIN |
With uv installed, you can claim/sync and run the
server straight from this repo — uvx fetches and builds it on demand:
# one-time claim + first sync
uvx --from git+https://github.com/dfrysinger/finance-mcp finance-mcp claim
uvx --from git+https://github.com/dfrysinger/finance-mcp finance-mcp sync --days 120Then register it with Copilot CLI by adding this to ~/.copilot/mcp-config.json
under mcpServers (or run /mcp in Copilot to manage):
{
"mcpServers": {
"finance": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/dfrysinger/finance-mcp",
"finance-mcp-server"
],
"tools": ["*"]
}
}
}If you cloned the repo and prefer running from the working tree:
{
"mcpServers": {
"finance": {
"command": "uv",
"args": ["--directory", "<ABSOLUTE_PATH_TO>/finance-mcp", "run", "finance-mcp-server"],
"tools": ["*"]
}
}
}get_transactions/spending_summary serve the durable archive (archive.db),
which sync (CLI) or sync_now keeps up to date.
SimpleFIN does not provide spending categories, so categories are assigned
locally by a rule engine (case-insensitive substring match on description/payee)
plus per-transaction manual overrides — nothing is guessed from outside your data.
Internal movements (transfers, card payments, P2P) are flagged so honest spend
totals exclude them; pass --include-transfers / include_transfers=true to count them.
Amounts are signed: negative = money out. Use max_amount=0 for spending-only,
min_amount=0 for income-only.
uv run pytest -qVerified end-to-end against SimpleFIN's public demo dataset (claim → fetch → normalize → cache → query, plus an MCP stdio round-trip).
Return just the balance and as-of date for each cached account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Mentions 'cached account', implying possible staleness, but does not elaborate on caching behavior, auth requirements, or rate limits. Without annotations, description carries full burden; minimal but adequate.
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 action, no extraneous words. Every word earns its place, perfectly concise.
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 zero parameters and existence of output schema, description fully covers the tool's purpose and output. States it returns balances for all cached accounts, which is complete for a simple read 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?
No parameters; schema coverage is 100% trivially. Baseline score of 4 applies as per guidelines for 0-parameter tools.
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?
Clearly states it returns balance and as-of date for each cached account. Verb 'return' and resource specified, distinguishing it from sibling tools like list_accounts which likely return full account details.
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 versus alternatives like list_accounts or spending_summary. Implied usage for quick balance checks, but lacks exclusions or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a category rule: a merchant match (+ optional predicates) -> category.
field is description, payee, or any. priority is
lowest-wins. Set is_transfer=True for internal transfers / card payments
so they are excluded from spending totals. Set account_id to scope the
rule to a single account (so a generic descriptor like "FUNDS TRAN" can be
reclassified on one account without affecting the same text elsewhere);
leave it None to apply to every account.
The merchant match defaults to a case-insensitive substring; set
match_mode='regex' to match pattern as a case-insensitive regular
expression instead (useful when a store number splits a merchant name).
Optional predicates further narrow a rule and must all hold to match:
amount_min/amount_max bound the amount magnitude (abs(amount),
so 200-350 matches a $304 charge), and day_min/day_max bound the
posted day-of-month (1-31) — together they isolate a recurring charge like a
mid-month insurance premium from other charges at the same merchant.
| Name | Required | Description | Default |
|---|---|---|---|
| field | No | any | |
| day_max | No | ||
| day_min | No | ||
| pattern | Yes | ||
| category | Yes | ||
| priority | No | ||
| account_id | No | ||
| amount_max | No | ||
| amount_min | No | ||
| match_mode | No | substring | |
| is_transfer | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: priority lowest-wins, default substring matching, absolute amount bounding, day-of-month bounds, and is_transfer exclusion from totals. It is thorough and accurate.
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 (~150 words), with a clear first sentence stating the core function, followed by organized explanations of key parameters. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 11 parameters and the presence of an output schema, the description thoroughly covers all usage aspects, leaving no ambiguity for an AI agent to select and invoke the tool correctly.
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 0%, and the description adds substantial meaning to all 11 parameters, including field options, priority behavior, match mode, and predicate semantics (e.g., amount bounds use abs(amount)). This far exceeds baseline requirements.
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 adds a category rule with a merchant match and optional predicates mapping to a category. It effectively distinguishes from sibling tools like list_category_rules and remove_category_rule by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use specific parameters (e.g., is_transfer for internal transfers, account_id for scoping, match_mode for regex). However, it does not explicitly compare with sibling tools like set_transaction_category, which could be an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audit each scheduled transfer: did it fire on time, late, early, or not at all.
Dates are YYYY-MM-DD; end defaults to today and start to a year back.
day_tolerance is how far a transfer may drift and still count as fired. A
genuinely-ambiguous allocation surfaces as missing until its transfer link
is confirmed via confirm_transfer.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | No | ||
| day_tolerance | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: date defaults, drift tolerance, and ambiguity handling. It also implies read-only audit behavior without stating destructive actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, parameter explanation, ambiguity note. No fluff, well-structured.
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 output schema exists, the description adequately covers the report content and edge cases. It is complete for the tool's complexity.
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?
Despite 0% schema description coverage, the description explains all three parameters: end and start defaults/formats, day_tolerance as drift threshold. It adds 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 tool audits scheduled transfers to check if they fired on time, late, early, or not at all. It uses a specific verb and resource, distinguishing it from siblings like confirm_transfer.
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 explains date format, default values, and day_tolerance meaning. It also mentions when an allocation surfaces as missing and directs to confirm_transfer for resolution, providing explicit when-to-use and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report archive size and date coverage (transaction count, earliest/latest).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must convey behavior. It states 'report' (read-only), but no mention of side effects, required state (e.g., archive existence), or idempotency. The description is adequate but lacks explicit behavioral detail.
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 of 10 words conveys the essential purpose. It is front-loaded and efficient, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema, the description sufficiently explains what the tool reports. However, it does not specify the scope (e.g., whether it covers all archives or a specific one), which could be clarified.
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, and schema coverage is 100%. The description adds value beyond the schema by specifying the output contains archive size, date coverage, transaction count, and earliest/latest dates, clarifying what the tool returns.
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 reports archive size and date coverage (transaction count, earliest/latest). It uses a specific verb ('report') and resource ('archive stats'), distinguishing it from sibling tools like 'spending_summary' or 'net_worth_history'.
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. However, its unique focus on archive stats implies usage context; it is distinct from other reporting tools. A note on prerequisites or when not to use would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-envelope planned target vs. actual spend for one YYYY-MM month.
Reads the budget config and the categorized archive. Returns each envelope's target, actual spend, and remaining (negative = over budget), plus unmapped spend on accounts in no envelope so nothing is silently dropped.
| Name | Required | Description | Default |
|---|---|---|---|
| month | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it reads budget config and archive, returns per-envelope data with unmapped spend, and implies no destructive behavior. Without annotations, this provides good transparency, though could explicitly state it 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?
Three sentences, front-loaded with purpose, each sentence adds value without waste. Efficient and clearly structured.
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?
Adequately explains output (target, actual, remaining, unmapped spend) and edge case. With an output schema present, full return details are not needed. Slightly lacks mention of permissions or limitations.
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 specifies the 'month' parameter format as YYYY-MM, adding meaning beyond the schema's type string; with 0% schema description coverage, this is valuable context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares planned target vs. actual spend per envelope for a given month, and mentions it reads budget config and categorized archive, distinguishing it from siblings like budget_forecast or spending_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?
No explicit guidance on when to use this tool versus alternatives; does not mention when-not-to-use or provide selection criteria relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-envelope sufficiency over a window: will each cover its upcoming bills.
Dates are YYYY-MM-DD. as_of defaults to today and through to 60 days
later. Each envelope gets a verdict (ok / at_risk / balance_unknown)
with the projected minimum balance and, when at risk, the date and shortfall.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | ||
| through | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 the tool returns a verdict ('ok'/'at_risk'/'balance_unknown'), projected minimum balance, and when at risk the date and shortfall. It implies read-only behavior (forecasting) and does not mention side effects. Adding an explicit statement about non-modification would make it 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?
The description is concise (two short sentences plus a line about output) and front-loads the core purpose. It avoids unnecessary words. However, it mixes format defaults and output details without clear separation, slightly reducing structure.
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 presence of an output schema and the tool's moderate complexity, the description covers purpose, parameter defaults/format, and output fields (verdicts, balances, shortfalls). Missing elements include error conditions, rate limits, or authentication info, but these are not critical for basic usage.
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 compensates by explaining the date format (YYYY-MM-DD) and default values for 'as_of' and 'through'. However, it does not explain the semantic meaning of the parameters (e.g., 'as_of' as the start of the forecast window). This is adequate but leaves room for improvement.
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 does 'per-envelope sufficiency over a window' to check if each envelope will cover its upcoming bills. This specific verb-resource combination distinguishes it from siblings like 'account_balances' (current balances) and 'spending_summary' (historical spending).
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 explains date format and defaults ('as_of' defaults to today, 'through' to 60 days later) but does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. The context is clear for basic use but lacks exclusions or alternative directions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report category coverage and the breakdown of transactions per category.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the basic function and does not mention any behavioral traits such as authentication needs, data freshness, or computational cost.
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. It could be slightly more informative without losing conciseness, but it is not overly 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 the presence of an output schema, the description does not need to detail return values. However, for a report tool among many, additional context about the scope or aggregation would improve completeness. The description is adequate but 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 tool has no parameters and schema coverage is 100%. The description correctly implies no input is needed. Baseline is 4 as there is no parameter information to add.
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 reports 'category coverage and the breakdown of transactions per category,' which is a specific verb+resource. However, it does not differentiate from sibling tools like spending_summary or budget_burndown that may also involve category reporting.
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 among the many sibling tools. The description lacks any context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirm one transfer link by id, locking the pairing as authoritative.
A confirmed link is excluded from every future reconcile, so the user's decision is never silently recomputed. Only a two-leg link can be confirmed; confirming an unmatched single leg is rejected. Returns the updated link or an error.
| Name | Required | Description | Default |
|---|---|---|---|
| link_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: the link is excluded from future reconciles, and only two-leg links can be confirmed. It does not detail error scenarios beyond mentioning rejection.
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 concise, front-loaded with the main action, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and the tool's simplicity, the description covers the core behavior and return type. It could mention the output schema structure but is adequate.
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 only parameter 'link_id' is only implied by 'by id' but not explicitly described. With 0% schema coverage, the description should compensate, but it does not clarify the meaning or format of the parameter.
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 ('confirm') and the resource ('transfer link') and explains the effect ('locking the pairing as authoritative'), making it distinct from siblings like 'reconcile_transfers'.
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?
Provides clear context for when to use (to confirm a two-leg link) and a condition (rejection of single-leg links), but does not explicitly name alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query cached transactions.
Dates are YYYY-MM-DD. Amounts are signed (negative = money out), so use
max_amount=0 for spending only or min_amount=0 for income only.
Each transaction carries a derived category and is_transfer flag; pass
category to filter to one, or include_transfers=False to drop internal
transfers and card payments. Returns the matching transactions plus the count.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| search | No | ||
| category | No | ||
| end_date | No | ||
| account_id | No | ||
| max_amount | No | ||
| min_amount | No | ||
| start_date | No | ||
| include_pending | No | ||
| include_transfers | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that transactions are cached (implying potential staleness) and that amounts are signed. However, it lacks details on data freshness, pagination behavior, or error conditions, which would be expected for a query 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 a single, well-structured paragraph with a clear opening sentence. Each subsequent sentence adds specific value without redundancy. It uses line breaks effectively to separate logical sections, making it 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 10 parameters and no annotations, the description covers essential user-facing filtering but misses details on search, account_id, limit, and include_pending. The caching behavior is mentioned but not elaborated. The presence of an output schema reduces the need to describe return values, but the overview remains incomplete for a tool of this complexity.
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 0%, so the description must compensate. It explains the semantics of dates (YYYY-MM-DD), amounts (signed), category filtering, and include_transfers. It provides example usage (max_amount=0 for spending). However, it omits explanations for search, account_id, limit, and include_pending, leaving a 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 starts with a specific verb and resource ('Query cached transactions'), immediately clarifying the tool's core function. It details filtering capabilities (dates, amounts, category, transfers) that distinguish it from sibling tools like list_transfers or account_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 provides clear guidance on when to use parameters such as max_amount/min_amount for spending/income filtering, and include_transfers to exclude internal transfers. While it doesn't explicitly state when not to use the tool or mention alternatives, the usage context is well-explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List cached accounts with balances and the institution each belongs to.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions 'cached' but does not explain caching behavior, data staleness, or any side effects. Lacks disclosure of read-only nature or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that directly states purpose without unnecessary words. Efficiently front-loaded.
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?
Simple tool with no parameters and output schema present. Description is complete enough for the agent to understand what it returns and when to use it.
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 baseline 4 applies. Description adds no parameter info but none is 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?
Description uses specific verb 'List' and resource 'cached accounts' with what is included (balances, institution). Clearly states the action and scope, distinguishing from sibling tools like account_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 this tool vs alternatives like account_balances or get_transactions. Missing context such as when to refresh or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the category rules (pattern -> category) currently in effect.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so description carries full burden. It only says 'list' (read operation) and 'currently in effect', but lacks details on pagination, data freshness, permissions, or 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?
Single sentence that is clear and front-loaded. Could add a bit more context without being wordy, but remains 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?
Adequate for a simple list operation with an output schema. However, given 22 sibling tools, some guidance on when to use this tool vs others would improve completeness.
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?
Input schema has 0 parameters, so schema coverage is 100%. No parameter info is needed, meeting baseline of 4 for zero-param tools.
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 lists category rules with pattern->category mapping, and specifies 'currently in effect', which is specific and distinguishes from sibling tools like add_category_rule and remove_category_rule.
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 vs its many siblings (22 total). No context about when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List reconstructed transfer links as from_account -> to_account $amount [why].
The raw feed names only the product type a transfer went to, never the named
account; each link here recovers the hidden counterparty and records why it was
drawn. status optionally restricts to one lifecycle state (confirmed /
inferred / unconfirmed / unmatched); unconfirmed links are the
ones awaiting the user's review and sort first.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully explains reconstruction, status meanings, and sorting order with no contradictions.
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, well-structured paragraphs with no wasted words; front-loads the key purpose.
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 single parameter and presence of output schema, the description provides all necessary context for a listing 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?
Only parameter 'status' is explained with possible values and their implications, compensating for 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists reconstructed transfer links in a specific format, distinguishing it from siblings like confirm_transfer.
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?
Provides clear context for status filtering and behavior (e.g., unconfirmed sort first), but does not explicitly compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Total balance across all accounts per as-of date, from the archive.
Each sync records a balance snapshot, so this builds a net-worth trend over time (oldest first). Loan/credit balances are negative, so the total is true net worth.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds value by disclosing that loan/credit balances are negative, data is from the archive, and each sync records a snapshot. It does not cover data freshness or time range limits, but the core behavioral traits are well explained.
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 sentences, front-loaded with the main purpose, and every sentence adds value. No redundancy or 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?
An output schema exists, so return value details are handled. The description covers purpose, data source, and key behavioral aspects. It could mention if there are any constraints (e.g., date range limits), but given no input params, it is 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?
The input schema has zero parameters with 100% description coverage, so the description need not add parameter information. The baseline of 4 is appropriate as the description effectively communicates that no parameters 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?
The description clearly states it provides total balance across all accounts per as-of date, building a net-worth trend over time. It differentiates from siblings like 'account_balances' by focusing on historical snapshots, not current 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 use for historical net worth trend analysis but does not explicitly state when to use this tool vs alternatives like 'account_balances' or 'spending_summary'. No exclusions or alternative names are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rebuild internal-transfer links from the archive (idempotent).
Re-runs the matcher over the categorized archive and persists the links,
preserving every confirmed link and recomputing the rest. Returns counts of
inferred / needs-confirm / unmatched links plus promotions and downgrades.
Run this after a sync so list_transfers reflects the latest data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses idempotency, preservation of confirmed links, recomputation of the rest, and the return format (counts of inferred/needs-confirm/unmatched plus promotions/downgrades). It could mention any potential side effects or resource usage, but overall it is transparent.
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 extremely concise: three sentences with no wasted words. The purpose, idempotency, and usage timing are front-loaded. Every sentence adds value.
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 and an output schema (though not shown), the description explains the return counts and when to use the tool. It could elaborate on 'promotions and downgrades' but is still sufficiently complete for an agent to decide.
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 has zero parameters, so schema coverage is 100% irrelevant. The description adds context about the tool's behavior and return values, which is valuable beyond the trivial 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 explicitly states the tool rebuilds internal-transfer links from the archive and is idempotent. It distinguishes from siblings like confirm_transfer (for individual confirmation) and list_transfers (for viewing), making the purpose clear and specific.
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 advises running after a sync so list_transfers reflects latest data, providing clear context. However, it does not explicitly mention when not to use it or list alternatives by name, which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Loud alerts for debt payments that were returned or missed.
as_of is YYYY-MM-DD, defaulting to today. Audits each configured debt
account (loans, mortgages, financed purchases) directly from its own
transactions, so a payment is caught no matter which account funded it. A
returned payment (posted then reversed) and a month whose payments net to
zero or less (none posted, or fully reversed) each surface as a red flag; the
payment amount is never compared, so any positive net counts as paid. A
returned or missed payment that is later re-made or covered by an extra
payment is downgraded to made_good and drops out of the red count. A debt
that syncs only a balance surfaces as an explicit unauditable note rather
than a silent gap. With no debt_accounts configured the report is simply
empty.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description thoroughly discloses behavior: audits each debt account, defines red flags (returned payments, net zero/negative months), downgrading to made_good, and unauditable note for balance-only sync.
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?
Description is detailed but well-structured; each sentence adds value. Could be slightly more concise, but it's informative and clear.
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 of the report (multiple edge cases) and the presence of an output schema, the description covers all necessary behavioral and usage details, including parameter semantics.
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?
Single parameter 'as_of' with 0% schema coverage; description adds format (YYYY-MM-DD), default (today), and purpose, which is essential for correct invocation.
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?
Clearly states it provides 'loud alerts for debt payments that were returned or missed.' Distinguishes itself from siblings like account_balances, spending_summary, and subscription_audit_report by specifying debt-focused alerting.
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?
Explains when to use (check for missed/returned debt payments) and conditions (no debt accounts leads to empty report). Lacks explicit when-not-to-use but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a category rule by its id.
| Name | Required | Description | Default |
|---|---|---|---|
| rule_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it 'Delete's, implying mutation, but there is no disclosure of side effects, permission requirements, or behavior when the rule_id does not exist. With no annotations provided, the description carries full burden but falls short.
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 with no fluff. It is front-loaded and efficient, but the extreme brevity edges toward underspecification rather than 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?
While the tool is simple and an output schema exists (though not shown), the description lacks details on success/failure outcomes, idempotency, or any conditions. This is insufficient for an agent to use it confidently without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds no meaning beyond the parameter name and type. 'by its id' is redundant and does not explain the format, constraints, or source of the rule_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 'Delete' and the resource 'category rule', and specifies the unique identifier as the key parameter. It effectively distinguishes itself from sibling tools like 'add_category_rule' and 'list_category_rules'.
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. There is no mention of prerequisites, error conditions, or context in which deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pin a category to a single transaction.
Manual overrides win over every rule and survive re-syncs, so use this to fix a one-off that the rules get wrong.
| Name | Required | Description | Default |
|---|---|---|---|
| txn_id | Yes | ||
| category | Yes | ||
| is_transfer | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: manual overrides override rules and persist across re-syncs. However, it lacks details on side effects, permissions, 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 extremely concise: two sentences that front-load the action and context without any 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 has 3 parameters, no annotations, and an output schema, the description covers purpose and usage but omits parameter semantics and output details, leaving gaps for a complete understanding.
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 adds no parameter-level details. It does not explain txn_id, category, or is_transfer, leaving the agent reliant on parameter names alone.
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 ('Pin a category to a single transaction') and distinguishes it from sibling tools like add_category_rule by emphasizing manual overrides as one-off fixes.
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 when to use this tool (to fix one-off categorization errors that rules get wrong), but does not explicitly mention when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregate net spending over a date range, grouped for budgeting.
group_by is category (default), account, org, month, or
envelope. Categories come from a local rules engine plus manual
overrides. Internal transfers and income (payroll, benefits, investment
income) are excluded by default so the totals reflect real spending; set
exclude_transfers=False or exclude_income=False to include them.
Per group, outflow is spend, inflow is refunds/returns that net
against it, and unclassified_inflow is positive amounts with no spending
category (surfaced but not netted). net is outflow plus refunds.
envelope rolls spend up by the configured budget envelope that owns each
account (so spend on a non-envelope account such as a loan or brokerage falls
into an (unmapped) bucket). It needs at least one envelope in the budget
config; with none configured it returns an error rather than an empty view.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | ||
| group_by | No | category | |
| start_date | No | ||
| exclude_income | No | ||
| include_pending | No | ||
| exclude_transfers | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses exclusions of transfers/income by default, explains net calculation, and covers edge cases like unmapped envelopes and errors. Minor omission: no mention of rate limits or permissions.
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 first, then parameter details. Every sentence adds value, though slightly verbose in places. Front-loads key information effectively.
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, no required, and output schema exists, the description covers group_by nuances and output fields. Missing details on date range defaults and include_pending behavior, but overall sufficient for agent understanding.
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 0%, so description compensates well. It fully explains group_by options and output semantics (outflow, inflow, net, unclassified_inflow). It does not detail date or boolean parameters but schema provides defaults.
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 aggregates net spending over a date range for budgeting, with a specific verb and resource. It distinguishes from siblings like get_transactions and account_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 for budgeting by date range with grouping, and through sibling context suggests when to use alternatives. It lacks explicit when-not-to-use statements but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flag tracked bills that did not post (billing problem / cancellation) and surface untracked recurring merchants as candidates for the assistant to judge.
Dates are YYYY-MM-DD; end defaults to today and start to a year back so
a monthly charge clears min_occurrences. tracked is the full roster of
configured recurring bills with each one's amount, due day, last-seen date, and
next due date. expected_missing is the deterministic high-stakes alert;
candidate_new is advisory — the assistant decides which candidates are real
subscriptions.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | No | ||
| day_tolerance | No | ||
| min_occurrences | No |
| Name | Required | Description |
|---|---|---|
No output 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 details each output section (tracked, expected_missing, candidate_new) and discloses that candidate_new is advisory. It does not mention any destructive behavior, which is fine for a report. Slight room for improvement: clarifying that it 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?
The description is somewhat lengthy but well-structured: first sentence states purpose, then parameter details, then output breakdown. Every sentence adds value, but it could be slightly more concise without losing clarity.
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 output schema exists (though not shown in full), the description explains return values in detail: tracked is full roster, expected_missing is deterministic alert, candidate_new is advisory. All parameters (0 required) are covered, and the tool's behavior is fully described. No gaps for this report-type 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 description coverage is 0%, so the description must compensate. It explains end (defaults to today), start (defaults to a year back), and min_occurrences in context. However, 'day_tolerance' is not mentioned, leaving one parameter unexplained. The YYYY-MM-DD format is given, adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to flag tracked bills that didn't post and surface untracked recurring merchants as candidates for judgment. The verb 'flag' and 'surface' with specific resources (tracked bills, untracked merchants) distinguish this from siblings like subscriptions_detect.
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?
Usage guidelines are provided: explanations of date defaults, min_occurrences, and the advisory nature of candidate_new. The description tells the assistant to decide real subscriptions from candidates. However, it doesn't explicitly state when not to use the tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect recurring charges from history and save them as tracked bills.
Scans the archive for merchants with repeated, same-amount, monthly-spaced
debits and writes each as a recurring bill in the budget config (creating
the config if absent), so your subscriptions become a saved list rather than
something re-inferred on every audit. Idempotent: a merchant already tracked
is skipped. Dates are YYYY-MM-DD; end defaults to today and start to
a year back. day_tolerance (default 7) is the day-of-month drift allowed
when deciding whether a charge is already covered by an existing bill.
Weekly/yearly merchants are reported under unsupported_cadence (only
monthly bills are tracked). Monthly merchants that could not be auto-tracked
— text too generic/variable to pin, or a recurring charge at a different
price from an already-tracked subscription — are reported under
needs_review (each with a reason) rather than written.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | No | ||
| day_tolerance | No | ||
| min_occurrences | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses idempotency (skips already tracked merchants), mutation (writes to config, creates if missing), date formats, defaults, and cadence restrictions. It also explains edge cases like unsupported cadence and needs_review. Comprehensive 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?
Description is a single paragraph, front-loaded with the main action. It efficiently packs necessary details without excessive fluff. Minor redundancy ('so your subscriptions become a saved list...') but overall concise and well-structured.
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 4 parameters, no required ones, no annotations, and an output schema that exists but is not shown, the description covers core functionality, defaults, and edge cases. It mentions outputs (`unsupported_cadence`, `needs_review`) but lacks detail on output structure. Missing `min_occurrences` explanation slightly reduces completeness.
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 0%, so description must add meaning. It explains `end`, `start`, and `day_tolerance` with defaults and format. However, it omits `min_occurrences` (default 3) entirely, leaving its role unclear. Thus partially compensates but has a clear 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?
Description clearly states the tool detects recurring charges and saves them as tracked bills. It specifies the resource (history, merchants) and action (detect, save), distinguishing it from siblings like subscription_audit_report (likely read-only) and subscriptions_mark (likely manual).
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?
Description explains when to use the tool for automatic detection and saving of subscriptions. It clarifies that weekly/yearly merchants go to 'unsupported_cadence' and ambiguous ones to 'needs_review', providing context on limitations. However, it does not explicitly mention alternatives 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.
Mark a tracked recurring bill as canceling, canceled, or active again.
The cancellation watch: after you cancel (or try to cancel) a subscription,
record it here so the audit stops reporting its expected charges as missing
and instead warns you if it charges again. lifecycle is canceling (a
cancellation was attempted but not confirmed), canceled (confirmed), or
active (reactivate a bill you'd marked). cancel_effective is the
YYYY-MM-DD date the cancellation takes effect and is required for canceling
and canceled — any matching charge on or after it is surfaced as the bill
"coming back". Omit it when reactivating. variable optionally flags the
bill as one whose amount changes every cycle (a usage-based or escrow bill):
true matches it by merchant and date regardless of amount and reports the
actual charged amount, false restores exact-amount matching, null
leaves the setting unchanged. The bill is found by name
(case-insensitive); the name must match exactly one bill.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| variable | No | ||
| lifecycle | Yes | ||
| cancel_effective | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly explains the consequences of marking lifecycle (audit behavior changes) and the effect of the variable flag on matching. It lacks mention of error handling, idempotency, or permissions, but given no annotations, it provides substantial 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 well-structured with the main action first, then detailed explanations for each parameter. It avoids unnecessary details but could be streamlined slightly. Overall 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?
The description covers the main functionality, parameter details, and effects on audit. With an output schema present, it doesn't need to detail return values. It lacks mention of potential errors (e.g., if name doesn't match exactly one), but overall is contextually adequate.
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 complete semantics for all four parameters: explains valid values for lifecycle, format and conditional requirement for cancel_effective, and three-way behavior for variable. This fully compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action (mark lifecycle status) and differentiates from sibling tools like subscriptions_detect and subscription_audit_report by focusing on lifecycle management. It uses specific verb 'mark' and specifies the resource and possible states.
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 details when to use each lifecycle state (canceling, canceled, active) and provides context for cancel_effective and variable. It lacks explicit mention of when not to use or alternative tools, but the context is sufficient for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pull fresh data from SimpleFIN into the cache (network call).
Respect SimpleFIN's ~24 requests/day budget: a sync of >89 days makes one request per ~89-day window. Returns a summary including any SimpleFIN errors.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses that it is a network call, it respects a request budget, and it returns a summary with errors. It implies a cache-update operation. It could add details about side effects or permissions, but it is transparent about key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the first sentence stating the core purpose and the second providing essential behavioral constraints. No superfluous words; front-loaded and 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?
Given the existence of an output schema (not shown), the description doesn't need to detail return values. It covers the tool's function, budget constraints, parameter behavior, and error handling. Minor gaps: no mention of cache duration or authentication requirements, but overall sufficient for a simple 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?
The schema description coverage is 0%, so the description must add meaning. It explains how the 'days' parameter influences the number of requests: 'a sync of >89 days makes one request per ~89-day window.' This adds behavioral context beyond the schema's basic type and default.
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: 'Pull fresh data from SimpleFIN into the cache (network call).' It identifies the data source, the action (pull), and the target (cache). While it doesn't explicitly differentiate from siblings, the verb 'sync' and context imply a distinct refresh operation.
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 explains when to use the tool (to sync data) and provides critical context about respecting SimpleFIN's daily request budget and how the 'days' parameter affects request count. However, it does not mention alternatives or when not to use the tool.
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.0account_balancesadd_category_ruleallocation_audit_reportarchive_statsbudget_burndownbudget_forecastcategorization_statusconfirm_transferget_transactionslist_accountslist_category_ruleslist_transfersnet_worth_historyreconcile_transfersred_flags_reportremove_category_ruleset_transaction_categoryspending_summarysubscription_audit_reportsubscriptions_detectsubscriptions_marksync_nowEach tool targets a distinct function or domain: accounts, transactions, categories, transfers, subscriptions, budgets, audits, etc. Overlaps are minimal (e.g., multiple audit reports but for different areas) and descriptions are detailed enough to disambiguate.
Tool names consistently use snake_case and follow a descriptive noun_verb or noun_noun pattern (e.g., list_accounts, sync_now, budget_burndown). No mixing of conventions or cryptic abbreviations.
22 tools is above average but justified given the broad domain of personal finance (syncing, accounts, transactions, categories, budgets, transfers, subscriptions, audits). Each tool serves a specific purpose; however, a few report tools could potentially be consolidated.
The tool surface covers core operations (sync, read, categorize, budget, audit) and advanced features (subscription detection, transfer reconciliation). Missing is the ability to create/update/delete transactions or budgets directly, but the server is primarily analytical, so this is acceptable.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Personal finance assistant — track transactions, budgets, net worth via Plaid
Personal finance, bank account, and shared memory connector for Claude, ChatGPT, Gemini Spark & more
Read-only bank access for your AI agent. Connects Claude, ChatGPT, Cursor, Gemini, Codex.
Brazilian Open Finance MCP — 30+ banks (Itaú, Nubank, etc.) to Claude/Cursor. Read-only.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dfrysinger/finance-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
