Allows pushing transaction updates to Airtable spreadsheets for external data synchronization.
Allows pushing transaction updates to Google Sheets for external data synchronization.
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., "@fintable-mcp List all my accounts with balances"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An unofficial MCP (Model Context Protocol) server for fintable.io, enabling AI assistants like Claude to manage your financial categories, rules, and transactions directly — no more clicking through multi-step wizards.
Note: This is a community project, not officially supported by fintable.io. It works by communicating with Fintable's Laravel Livewire 3 backend using your browser session. If you're the Fintable developer and would like to collaborate on an official MCP server or public API, please open an issue — we'd love to work with you! 🤝
Once installed, you can ask Claude or your favorite MCP Client things like:
"Create these expense categories: Office Supplies, Shipping, Packaging, Equipment Rental, Software Subscriptions"
"Create rules: 'Staples' → Office Supplies, 'UPS' → Shipping, 'USPS' → Shipping"
"Run all rules to categorize my transactions"
"What's my current account balance at Ally Bank?"
"List all my categorization rules"
No more going through a 3-page wizard 20 times to set up 20 categories. Just tell Claude what you need.
Related MCP server: LunchMoney MCP Server
Tool | Description |
| List all connected bank accounts with balances |
| List all transaction categories |
| List categorization rules (with pagination) |
| List/search transactions with optional filtering |
Tool | Description |
| Create a single category |
| Create up to 50 categories at once |
| Create a categorization rule |
| Create multiple rules at once |
| Execute all rules on uncategorized transactions |
| Delete a categorization rule |
| Trigger bank account sync via Plaid |
| Push updates to Airtable/Google Sheets |
Python 3.10+
A fintable.io account with connected bank accounts
Claude Desktop (or any MCP-compatible client — Cherry Studio, etc.)
git clone https://github.com/jasoncbraatz/fintable-mcp.git
cd fintable-mcppip install -r requirements.txtOr with uv (faster):
uv pip install -r requirements.txtYou have two options — automatic (recommended) or manual.
Option A: Automatic cookie extraction (recommended)
Install rookiepy, which reads cookies directly from Chrome's local database using your OS credentials:
pip install rookiepyThat's it. As long as you're logged into fintable.io in Chrome, the server grabs fresh cookies on every run. No manual copying, no expiration headaches.
Option A½: Self-refreshing cookie jar (advanced)
If you want the server to maintain its own session without needing Chrome or rookiepy after the first run, add the --persist-cookies flag to your config (see step 4). This saves session cookies to ~/.fintable-mcp-cookies.json and auto-updates them from server responses — the session stays alive as long as it doesn't expire server-side between runs.
The initial seed comes from whichever auth method is available (rookiepy, env var, etc.). After that, the server is self-sufficient.
Security note: This stores session cookies on disk. The file is a dotfile in your home directory and isn't advertised anywhere, but anyone with read access to your home folder could find it. If that's a concern, stick with Option A.
Note for Python 3.13+: You may need to set
PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1before installing rookiepy:PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1 pip install rookiepy
Option B: Manual cookie export
If you'd rather not install rookiepy (or you're using a browser other than Chrome):
Open Chrome and go to fintable.io — make sure you're logged in
Open DevTools (F12 or Cmd+Option+I)
Go to the Network tab
Click on any request to fintable.io
Find the Cookie header in Request Headers
Copy the entire cookie string
You'll pass this as an environment variable in the next step.
Add the following to your Claude Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
If using rookiepy (Option A) — no env vars needed:
{
"mcpServers": {
"fintable": {
"command": "python",
"args": ["/absolute/path/to/fintable-mcp/fintable_mcp.py"]
}
}
}If using --persist-cookies (Option A½) — pair with rookiepy or env var for initial seed:
{
"mcpServers": {
"fintable": {
"command": "python",
"args": ["/absolute/path/to/fintable-mcp/fintable_mcp.py", "--persist-cookies"]
}
}
}If using manual cookies (Option B):
{
"mcpServers": {
"fintable": {
"command": "python",
"args": ["/absolute/path/to/fintable-mcp/fintable_mcp.py"],
"env": {
"FINTABLE_COOKIES": "your_full_cookie_string_here"
}
}
}
}💡 Replace
/absolute/path/to/fintable-mcp/fintable_mcp.pywith the actual path where you cloned this repo.
After saving the config, fully quit and relaunch Claude Desktop. The fintable tools will appear in Claude's tool list.
This server authenticates using your fintable.io browser session cookies — the same cookies your browser uses when you're logged in.
Cookie resolution order:
Persisted cookie jar — If --persist-cookies is active and ~/.fintable-mcp-cookies.json exists with fresh cookies, use those. Self-updates from server Set-Cookie headers.
rookiepy — If installed, cookies are extracted fresh from Chrome's local database on every server start. Zero maintenance.
FINTABLE_COOKIES env var — Full cookie string from Chrome DevTools (fallback if rookiepy isn't installed).
FINTABLE_SESSION_COOKIE env var — Just the session cookie value (simplest manual option).
When --persist-cookies is active, whichever method provides the initial cookies will also seed the jar. On subsequent runs, the jar takes priority — and every server response refreshes it automatically.
Your credentials are never stored to disk by this server — they live only in memory while the server is running.
If you're using rookiepy (recommended), session expiration is handled automatically — fresh cookies are pulled from Chrome on every server start. Just make sure you stay logged into fintable.io in Chrome.
If you're using manual cookie export, your cookies will eventually expire. When they do, the server will return an authentication error. Re-export your cookies from Chrome and update the FINTABLE_COOKIES environment variable.
Fintable.io is a Laravel application using Livewire 3 + Alpine.js for its frontend — there's no public REST API. This MCP server:
Authenticates using your browser session cookies (CSRF token + session cookie)
Fetches pages to extract Livewire component snapshots from wire:snapshot HTML attributes
Makes Livewire protocol calls — POST requests to the /livewire-{hash}/update endpoint with component snapshots, method calls, and property updates
Parses HTML responses to extract structured data (accounts, categories, rules, transactions)
The Livewire update path includes a hash (e.g., /livewire-5c7ce5a8/update) that can change when the app is redeployed. The server auto-discovers this path from the data-update-uri HTML attribute on each page load, so it stays resilient across deployments.
The Livewire update endpoint includes a build hash (e.g., /livewire-5c7ce5a8/update) that changes on each deployment. The server auto-discovers this on every page fetch, but if Fintable significantly restructures their Livewire components or changes component names, things may break. This is inherent to working without an official API.
Since there's no JSON API, read operations depend on parsing HTML structure. If Fintable redesigns their UI layout, the parsing logic may need updating. This is the biggest maintenance burden of the current approach.
The ideal solution is for Fintable to expose lightweight JSON API endpoints. This would:
Eliminate the fragile HTML parsing
Remove the Livewire hash dependency
Enable more reliable integrations
Open the door for other community tools and integrations
Be a great selling point for the product (MCP-ready financial tools are a differentiator!)
If you're the Fintable developer reading this — even a handful of authenticated JSON endpoints for categories, rules, and transactions would make this server rock-solid and dramatically easier to maintain. Happy to collaborate on the design. 🚀
This server runs locally on your machine as a stdio subprocess of your MCP client. It:
Never exposes a network port
Never stores credentials to disk
Only communicates with fintable.io using your existing browser session
Runs as a single-user, single-client process
By default, session cookies are kept in memory only while the server is running. With rookiepy, they're extracted fresh from Chrome on each launch — no environment variables or config files needed.
If --persist-cookies is enabled, cookies are saved to ~/.fintable-mcp-cookies.json (a dotfile in your home directory). This is an opt-in tradeoff: convenience of a self-refreshing session in exchange for cookies existing on disk. Delete the file at any time to revoke the session.
PRs welcome! Some ideas for future improvements:
Support for transaction date range filtering
Category group management (create/rename groups)
Rule priority reordering
Export categories/rules as JSON for backup
Support for multiple Fintable accounts
Note on deletions: Category deletion is intentionally not supported — that's a destructive action best done through the Fintable web UI where you can see the full impact. A little friction before deleting things is a feature, not a bug.
This project is not affiliated with, endorsed by, or officially supported by fintable.io. It was built by reverse-engineering the Livewire 3 frontend protocol. Use at your own risk — the underlying Livewire protocol may change without notice.
MIT - Jason C Braatz
Create multiple transaction categories at once — the batch operation that saves you from clicking through the UI 20 times!
Each category is created sequentially with proper page state management.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal a non-read-only, non-destructive, non-idempotent mutation. The description adds value by revealing sequential creation and proper page state management, which are behavioral details beyond the annotations.
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, front-loaded with the main purpose. The marketing phrase ('saves you from clicking...') adds some length but is concise overall. Could be tighter but still 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 output schema exists and the tool is simple, the description covers batch creation and sequential processing. It does not detail error handling or limits, but those are in the schema. Adequate for the 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?
The input schema already contains descriptions for both parameters (names, group_header), so the description does not add additional parameter meaning. Baseline 3 applies as schema coverage is high.
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 creates multiple transaction categories at once, distinguishing it from the singular fintable_create_category tool. The verb 'Create' is specific and the resource 'bulk categories' is directly indicated.
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 hints at batch usage ('saves you from clicking through the UI 20 times') but does not explicitly state when to use this over fintable_create_category or provide exclusions. It leaves context implicit rather than offering direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create multiple categorization rules at once — batch rule creation!
Each rule maps a transaction description pattern to a category. Optionally runs all rules after creation to categorize existing transactions.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions creation and optional run-after-create, which adds to annotations. However, does not disclose idempotency, side effects, or permission requirements. Annotations already indicate readOnlyHint=false and destructiveHint=false.
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 concise sentences, front-loaded with purpose, no unnecessary words. Perfectly efficient for the tool's complexity.
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 covers core functionality and optional behavior. Lack of return value explanation is acceptable due to output schema. Could mention limitations or prerequisites.
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% but input schema contains descriptions for both parameters (rules, run_after_create). The description adds context about rule mapping, but does not compensate for missing schema descriptions beyond what's already in 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?
Description clearly states 'Create multiple categorization rules at once' using specific verb and resource. Distinguishes from sibling fintable_create_rule (single rule) by highlighting batch 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?
Description implies usage for bulk rule creation with optional post-create categorization, but lacks explicit guidance on when to use over alternatives like fintable_create_rule or fintable_run_all_rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new transaction category in Fintable.
The category will appear in the categorizer sidebar and can be used in rules. Use group_header to place the category under a group (e.g., 'Expense', 'COGS', 'Income').
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds information about the category appearing in the sidebar and being usable in rules, beyond the annotations which indicate a write operation. Could mention prerequisites like required 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?
Three sentences with clear front-loading of purpose. No unnecessary words, but could be slightly more 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 simple tool and good annotations, the description covers the main behavioral aspects. Lacks mention of output format or potential duplicates.
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 context for group_header (placing under a group) but the schema already provides detailed descriptions for both parameters. Moderate added 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?
Clearly states the tool creates a new transaction category in Fintable, and distinguishes from bulk creation or rule creation siblings.
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 guidance on using group_header, but does not explicitly state when to use this single-category tool versus the bulk sibling fintable_create_bulk_categories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new simple categorization rule.
A simple rule matches transaction descriptions containing the pattern text and assigns them to the specified category. After creating rules, use fintable_run_all_rules to apply them.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=false, destructiveHint=false, which align with create action. Description adds detail on pattern matching behavior beyond annotations.
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, clear, and front-loaded. No extraneous 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?
With sibling tools and output schema, description covers creation and next step. Could mention validation or scope but is satisfactory.
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% per context, yet description does not elaborate on parameters beyond vague references. Schema itself has good descriptions, but given the low coverage, description should compensate more.
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 the tool creates a 'simple categorization rule' with pattern matching. Distinguished from siblings like fintable_create_bulk_rules and fintable_create_category, but not explicitly.
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?
Indicates when to use (simple rule) and provides a next step (run_all_rules). Does not explicitly state when not to use or alternatives, but the context is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a categorization rule by its ID.
Use fintable_list_rules to find rule IDs. This is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds 'irreversible' beyond annotations (destructiveHint=true), consistent with destructive nature. No contradiction.
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 concise sentences, front-loaded purpose, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a simple delete with one param, existing output schema, and annotations providing behavioral hints.
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 already describes rule_id fully; description adds little new info beyond that.
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 it deletes a categorization rule by ID, distinguishing it from create/list siblings.
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?
Mentions using fintable_list_rules to find rule IDs and that the action is irreversible, but does not explicitly state 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.
List all bank accounts connected to Fintable with balances and latest transaction dates.
Returns account names, balances, latest transaction dates, and provider/bank/account IDs. Use this to get an overview of all connected financial accounts.
Returns: str: JSON list of accounts with name, balance, latest_transaction, provider, bank_id, account_id.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the exact output fields (account names, balances, latest transaction dates, provider/bank/account IDs) and confirms it returns a JSON list. This is additive context, though no edge cases like empty lists are mentioned.
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 short paragraphs plus a return type line, with the primary action front-loaded. Every sentence adds value, and there is 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 no parameters, a simple list operation, and existing annotations, the description fully covers what the tool does and returns. No missing information like pagination or limits is needed for this straightforward 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 input schema has no user-facing properties (only a required empty params object), so no parameter descriptions are needed. The description correctly omits parameter details, and the baseline of 4 applies for tools with zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List all bank accounts connected to Fintable with balances and latest transaction dates.' This is a specific verb+resource combination that clearly distinguishes it from sibling tools like fintable_list_transactions or fintable_list_categories.
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 says 'Use this to get an overview of all connected financial accounts,' which provides clear context for when to use it. It does not explicitly mention when not to use it or alternatives, but the scope is unambiguous given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all transaction categories configured in the Fintable categorizer.
Categories are organized into groups (e.g., COGS, Expense, Income). Use this to see what categories exist before creating new ones or rules.
Returns: str: JSON list of categories with their names.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior; description adds that categories are grouped and returns a JSON list, providing useful context beyond annotations.
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 short, front-loaded sentences with no wasted words; structure efficiently communicates purpose, usage, and return type.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and clear annotations, the description fully covers what the agent needs: purpose, grouping, and return format.
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 no actual parameters (empty object), so no parameter info needed. Description does not add param details but return format is noted.
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 lists all transaction categories, includes grouping info, and is distinct from sibling tools that create, delete, or list other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this before creating categories or rules, but does not list when not to use it or compare to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all categorization rules. Rules auto-categorize transactions based on description patterns.
Each rule has a pattern (e.g., 'Home Depot') and a target category (e.g., 'COGS'). When 'Run All Rules' is triggered, transactions matching the pattern get categorized.
Args: params: page number for pagination (rules are paginated).
Returns: str: JSON list of rules with id, pattern, category, and display text.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds value by explaining the purpose of rules, pagination behavior, and return format. No contradictions with annotations.
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: three sentences covering purpose, context, and parameters. Front-loaded with purpose, no redundant information, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (list with pagination) and the presence of annotations and output schema, the description is complete. It explains the rule concept, pattern/category, triggers, and return structure, leaving no gaps for an AI agent.
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 mentions the 'params' argument as page number for pagination, which adds context to the schema's description. However, it could be more precise about the nested structure, and schema description coverage is low (0%), so description partially compensates.
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 'List all categorization rules' and explains the function of rules, distinguishing it from create/delete/run siblings. It provides specific verb and resource, and includes pagination detail.
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 using this tool to view existing rules but lacks explicit guidance on when to use it versus alternatives like fintable_create_rule or fintable_run_all_rules. No exclusions or when-not-to-use are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List transactions from the Fintable transactions page.
Supports searching by description and pagination. Shows date, description, amount, category, and account for each transaction.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds value by stating support for search and pagination and listing the fields returned, but does not disclose additional behavioral traits beyond what annotations hint.
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 three sentences long, front-loaded with the purpose, and contains no unnecessary information. 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 the tool's simplicity (listing with two optional parameters), the description is complete. It covers the action, supported features, and output fields. An output schema exists, so return value details are not needed.
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 mentions 'searching by description' and 'pagination', which correspond to the two parameters (search and page). However, the input schema already provides descriptions for these parameters, so the description adds minimal extra meaning. Schema coverage for parameters is high.
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 'List' and the resource 'transactions' from the 'Fintable transactions page'. It also lists the fields returned, distinguishing it from sibling list tools like fintable_list_accounts and fintable_list_categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing transactions with optional search and pagination, but does not explicitly mention when to use this tool versus alternatives or when not to use it. It provides clear context for its intended purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-sync categories and transactions to connected Airtable/Google Sheets integrations.
Use this after making category changes to push updates to your spreadsheets.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, so the description's claim of re-syncing adds context but not new behavioral insights. 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 concise and front-loaded sentences with no unnecessary words. Efficient 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?
For a simple tool with no parameters and an output schema, the description fully covers the purpose and usage context. No gaps remain.
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 (the only 'params' is a container with no properties). With no parameters to document, the baseline is 4. The description adds no parameter info, which is acceptable.
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 re-syncs categories and transactions to connected Airtable/Google Sheets integrations, distinguishing it from sibling tools like fintable_sync_accounts and fintable_run_all_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?
Explicitly states to use after making category changes, providing clear context. However, it does not mention alternatives or when not to use it, missing a chance to differentiate further.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run all categorization rules to auto-categorize transactions.
This triggers the same action as clicking 'Run All Rules' in the Fintable UI. All rules are applied to uncategorized transactions in priority order.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by stating it applies rules to uncategorized transactions in priority order and mimics a UI action. No contradiction with annotations (idempotentHint=true aligns).
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 (3 sentences), front-loads the main purpose, and provides necessary detail 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 tool has no parameters, annotations are present, and an output schema exists (though not shown), the description fully explains the tool's function and behavior for agent invocation.
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 no actual parameters (only a required empty object). With 0 parameters, the baseline is 4. The description does not need to compensate for any missing parameter information.
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 (run all rules), resource (categorization rules), and result (auto-categorize transactions). It distinguishes from sibling tools like create_rule or list_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?
The description provides context that it triggers the same action as clicking 'Run All Rules' in the UI, but does not explicitly state when not to use it or suggest alternatives. Still, the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger a sync of all connected bank accounts via Plaid.
This fetches the latest transactions and balances from your connected banks.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only, not destructive, idempotent, and open-world. The description adds that it fetches transactions and balances, which implies data modification, but does not elaborate on side effects, duration, or state changes beyond what annotations convey.
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 consists of two sentences. The first sentence states the primary action, and the second adds detail. Every word contributes value with no redundancy or 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?
Given the tool is a simple sync trigger with an output schema, the description adequately covers the purpose and what is fetched. It could optionally mention that syncing might take time, but the current level is sufficient for an agent to understand the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single required parameter 'params' which is an empty object. Since there are no meaningful parameters, the description's lack of parameter detail is acceptable. The baseline is raised because schema coverage is low but there is nothing to cover.
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 triggers a sync of all connected bank accounts via Plaid, fetching latest transactions and balances. The verb 'sync' combined with 'accounts' matches the tool name and distinguishes it from sibling tools like 'list_accounts' (read-only) and 'resync_spreadsheets' (different resource).
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 indicates when to use the tool (to sync bank accounts) but does not provide explicit when-not-to-use or alternatives. Sibling tools exist for listing and resyncing spreadsheets, but no direct comparison or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct action and resource. Bulk operations are clearly named and separate from single operations, and all list/delete/sync tools have unique purposes.
All tools follow the predictable fintable_verb_noun pattern with snake_case. 'Bulk' modifiers are consistently used for batch operations, and verbs like create, list, delete, run, sync are used appropriately.
12 tools cover the core functionality of managing categories, rules, accounts, and transactions without redundancy or excessive granularity.
The set provides create/list/delete for rules, create/list for categories, and sync operations. Missing update operations for categories and rules, and no direct transaction categorization tool, but the domain is still functional.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Gainium — manage trading bots, deals, and balances via AI assistants
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Personal finance for AI agents — onboard, import statements, categorize & budget over MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jasoncbraatz/fintable-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
