Skip to main content
Glama
dfrysinger

finance-mcp

by dfrysinger

add_category_rule

Add a rule to automatically categorize transactions based on merchant pattern, with optional filters on amount range and day-of-month. Supports per-account scoping and excluding transfers.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fieldNoany
day_maxNo
day_minNo
patternYes
categoryYes
priorityNo
account_idNo
amount_maxNo
amount_minNo
match_modeNosubstring
is_transferNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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