Неофициальный проект. Этот проект не связан, не одобрен и не спонсируется Plaid Inc. "Plaid" является торговой маркой Plaid Inc. Это самохостируемый клиент, который взаимодействует с API Plaid, используя предоставленные вами учетные данные.
Самохостируемый MCP-сервер с доступом только для чтения, который подключает ваши банковские счета, кредитные карты, займы и брокерские счета (через Plaid) к MCP-клиенту, такому как Claude Code. Задавайте вопросы о своих финансах на обычном языке — без участия сторонних агрегаторов (Monarch, Mint и т. д.).
"Какой мой общий баланс по всем счетам?"
"Покажи транзакции на сумму более $100 за последние 30 дней."
"За какие подписки я все еще плачу?"
"Сколько я потратил на продукты в прошлом месяце?"
"Есть ли банк, требующий повторной аутентификации?"
Пример сессии (иллюстративный):
you : What did I spend on groceries last month?
claude : [calls get_transactions]
$487.23 across 14 transactions. Top merchants:
Whole Foods ($198), Trader Joe's ($156), Safeway ($89).
you : Any subscriptions I'm still paying for?
claude : [calls get_recurring_transactions]
7 active recurring outflows totaling $142/mo:
Netflix ($15.99), Spotify ($11.99), NYT ($4), ...Related MCP server: FinLynq
Все 9 инструментов работают только для чтения. Каждый возвращает {<data>: [...], "warnings": [...]} так, чтобы один неисправный банк не нарушал работу всего запроса.
Инструмент | Что он делает |
| Все счета во всех подключенных банках с балансами |
| Текущие + доступные балансы в реальном времени (с фильтрацией по счетам) |
| Транзакции за указанный период (до 2 лет назад) |
| Поиск по ключевым словам среди продавцов / имен / контрагентов |
| Обнаруженные потоки регулярных поступлений + списаний |
| Кредитные карты, студенческие займы, ипотеки с APR и деталями платежей |
| Текущие активы с тикером + метаданными ценных бумаг |
| История покупок / продаж / дивидендов за период |
| Состояние каждого подключенного банка (показывает необходимость ре-аутентификации) |
Требуется Python 3.11+, аккаунт Plaid (бесплатный план Trial) и MCP-клиент.
Зарегистрируйтесь на https://dashboard.plaid.com/signup → выберите план Trial (бесплатно, 10 элементов).
Team Settings → Products: включите Transactions, Liabilities, Investments.
Team Settings → API: скопируйте ваш client_id и production secret.
git clone https://github.com/JosueM1109/personal-finance-mcp.git
cd personal-finance-mcp
python3.11 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env # then fill in PLAID_CLIENT_ID and PLAID_SECRET
pytest -v # sanity checkЗапускайте по одному разу для каждого банка, который хотите подключить:
uvicorn link_helper:app --port 8765Откройте http://localhost:8765, нажмите Link a bank и завершите процесс Plaid Link. Терминал выведет строку вида PLAID_TOKEN_CHASE=access-prod-xxx... — вставьте ее в .env и повторите для каждого банка.
python server.py # serves on http://localhost:8000/mcpclaude mcp add --transport http personal-finance http://localhost:8000/mcpПопробуйте "list my accounts", чтобы проверить работу.
Для развертывания, доступного отовсюду:
Docker (включен): docker build -t personal-finance-mcp . && docker run --rm -p 8000:8000 --env-file .env personal-finance-mcp
Любой Python-хостинг (Fly.io, Railway, Raspberry Pi + Tailscale, VPS): установите переменные окружения из .env.example, откройте /mcp через HTTPS, защитите авторизацией.
Prefect Horizon (используется автором — $0 регулярных затрат): см. docs/DEPLOYMENT.md для полного руководства.
Защитите эндпоинт. Открытый MCP-эндпоинт с вашими токенами раскрывает все подключенные счета. Используйте OAuth 2.1, Cloudflare Access или привяжите только к частной сети.
Однопользовательский режим. Одно развертывание на человека. Не делитесь доступом.
Только чтение. Ни один инструмент не изменяет состояние в финансовых учреждениях. Не добавляйте инструменты, которые это делают.
Токены живут в переменных окружения, никогда не записываются на диск. .env добавлен в gitignore.
Вы несете ответственность за соблюдение правил Plaid. Вы являетесь клиентом Plaid под своей учетной записью.
Перед каждым развертыванием:
[ ] .env никогда не коммитится: git log --all -- .env ничего не возвращает
[ ] В истории нет реальных токенов: git log -S'access-prod-' --all возвращает только заглушки
[ ] Перед MCP-эндпоинтом стоит защита (или доступ только через localhost)
[ ] HORIZON=1 (или аналогичное) установлено в переменных окружения развертывания, блокируя link_helper.py там
[ ] Проверяйте get_institutions_status() каждые несколько недель на предмет необходимости повторной аутентификации
Инструмент возвращает пустоту, несмотря на наличие данных. Продукты Plaid не были включены при подключении банка. Переподключите с активными Transactions + Liabilities + Investments. Инструмент выводит PRODUCTS_NOT_SUPPORTED в warnings, если причина в этом.
get_institutions_status() показывает re_auth_required. Сессия Plaid для банка истекла. Запустите link_helper.py в режиме обновления — ваш существующий токен доступа останется прежним. См. docs/DEPLOYMENT.md.
Plaid Link показывает банк как "unsupported" (часто с Amex). Обычно это проблема INSTITUTION_REGISTRATION_REQUIRED — банки с OAuth требуют предварительной регистрации для каждого учреждения в панели управления Plaid. См. docs/TROUBLESHOOTING.md.
Другие проблемы: docs/TROUBLESHOOTING.md.
server.py — сервер FastMCP, 9 инструментов только для чтения.
plaid_client.py — обертка SDK Plaid: маскирование токенов SecretStr, 5-минутный кэш состояния для каждого элемента, форматирование ответов, структурированное отображение ошибок.
link_helper.py — локальное приложение FastAPI для Plaid Link. Отказывается работать, если установлено HORIZON=1.
Более глубокий разбор (включая причины выбора /transactions/get вместо /transactions/sync): docs/ARCHITECTURE.md.
См. CONTRIBUTING.md. Область применения намеренно узкая: только чтение, один пользователь, на базе Plaid.
Get live current + available balances for accounts.
| Name | Required | Description | Default |
|---|---|---|---|
| account_ids | No | Optional filter. When omitted, returns balances for every account across every healthy Item. When provided, only matching accounts are returned; Items that don't own any of the IDs emit a warning (INVALID_ACCOUNT_ID) rather than failing the call. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds minimal behavioral context. It mentions 'live current + available' but does not elaborate on rate limits, authentication, or implications of the optional 'account_ids' parameter (e.g., warnings).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One efficient sentence with no redundant words. Front-loaded with the primary 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 a single optional parameter and an output schema (not shown), the description is adequate. It covers the core purpose but could explain 'live' vs 'available' if not obvious from the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no new meaning beyond the schema. The phrase 'live current + available' characterizes the data but not 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 ('Get'), the resource ('balances'), and the specific attributes ('live current + available'). This distinguishes it from sibling tools like 'list_accounts' or 'get_transactions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'list_accounts' or 'get_investment_holdings'. Lacks context for 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.
Return health status for every linked Item/institution.
No additional network calls beyond what all_items already makes (it
uses the 5-minute health cache). Enumerates linked Items and reports their
current health status.
Returns: {"items": [{"env_key", "institution", "institution_id", "status", "reason"}, ...]}
| 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?
Annotations already declare readOnlyHint=true, confirming safety. The description adds valuable behavioral context: uses a 5-minute health cache and makes no extra network calls, which helps agents understand cost and freshness.
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 extremely concise: two short paragraphs, no fluff, front-loaded with purpose. 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, an output schema exists, and the description includes a return format example with all fields, it is fully sufficient. The caching behavior is also noted, making it 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?
Input schema has zero parameters, so schema coverage is 100%. Description does not need to explain parameters; the only relevant detail is the cached nature, which is already mentioned elsewhere.
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 'Return health status for every linked Item/institution.' The verb 'return' and resource are precise, and it distinguishes from sibling tools that deal with financial data like balances or transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides clear context: 'No additional network calls beyond what all_items already makes (it uses the 5-minute health cache).' This implies when to use it (when you need health status cheaply) but lacks explicit when-not or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return investment holdings with security metadata across all linked Items.
Joins holdings with the securities list returned in the same response to provide symbol, name, and security type. Adds institution to each holding.
Returns: {"holdings": [...], "warnings": [...]}
| 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?
Annotations already declare readOnlyHint=true. Description adds value by explaining that it joins holdings with securities and adds institution info, providing context beyond the annotation.
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 plus a return format line. Every sentence is informative and no words are wasted. Front-loaded with the core action.
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 presence of output schema, description is complete. It explains the join operation and the return structure (holdings, warnings), 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?
No parameters defined, so baseline is 4. Description does not need to add parameter details, and it appropriately mentions 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?
Description clearly states verb 'Return' and resource 'investment holdings'. It specifies joining with securities list and adding institution. However, it does not explicitly distinguish from sibling tools like get_investment_transactions, but the name and context imply the difference.
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 vs alternatives. Usage is implied by the tool's name and description, but lacks when-not or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch investment transactions in [start_date, end_date] across all healthy Items.
Dates are ISO YYYY-MM-DD. Uses offset pagination (count=500 per page). If start_date is older than ~2 years before end_date, the window is clipped and a warning is emitted. Each transaction is joined with security metadata (ticker symbol, name) from the same response.
Returns: {"investment_transactions": [...], "warnings": [...]}
| Name | Required | Description | Default |
|---|---|---|---|
| start_date | Yes | ||
| end_date | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant details beyond readOnlyHint: fetches across all healthy Items, offset pagination, date clipping, and security metadata joining. No contradiction 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?
Concise but could be more front-loaded. Every sentence adds value; no fluff.
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?
Covers pagination, date handling, security metadata, warnings, and return format. Output schema exists, so no need to detail return values further.
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?
Adds meaning beyond schema: explains ISO format, clipping behavior for start_date, and that dates are inclusive. Schema has 0% description coverage, so description carries full burden.
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 fetches investment transactions within a date range across all healthy Items. Distinguishes from siblings like get_transactions (non-investment) and get_investment_holdings (holdings vs transactions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on pagination and date window clipping. Does not explicitly state when not to use or alternatives, but the scope is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return credit, student-loan, and mortgage liability details across all linked Items.
For Items where the liabilities product is not enabled, a per-Item warning with code PRODUCTS_NOT_SUPPORTED is emitted instead of failing the call.
Returns: {"credit": [...], "student": [...], "mortgage": [...], "warnings": [...]}
| 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?
Beyond the readOnlyHint annotation, the description discloses that per-Item warnings are emitted instead of failure when the liabilities product is not enabled, adding valuable behavior context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a return example provide all necessary information with no redundancy; front-loaded with 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 tool has no parameters and the output schema is provided, the description is complete, covering expected return fields and edge-case behavior.
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 zero parameters and 100% schema coverage, the description doesn't need to add parameter meaning, and it appropriately focuses on the output structure, which is clear.
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 returns liability details for credit, student-loan, and mortgage across all linked Items, distinguishing it from sibling tools like get_balances or get_transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies broad usage across all Items but does not provide explicit guidance on when to use this tool versus alternatives or mention any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return recurring inflow and outflow streams across all linked Items.
Calls /accounts/get first per Item to collect account IDs (required by /transactions/recurring/get), then fetches recurring streams and shapes them into unified inflows/outflows lists.
Returns: {"inflows": [...], "outflows": [...], "warnings": [...]}
| 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?
The description discloses internal behavior (calling /accounts/get first) and output shaping, adding value beyond annotations which only indicate readOnlyHint. 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?
The description is concise with three sentences and a return block, each sentence earning its place, front-loaded with the main 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 no parameters and an output schema exists, the description sufficiently covers the tool's behavior, internal API calls, and return shape, with no missing critical information.
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 (0 params, 100% schema coverage). The description adds meaning by explaining the underlying process, which compensates for the lack of parameter details.
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 returns recurring inflow and outflow streams across all linked Items, with a specific verb and resource that distinguishes it from sibling tools like get_transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for recurring transactions but does not explicitly state when to use this tool vs alternatives like get_transactions or list_accounts. No when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch transactions in [start_date, end_date] across all healthy Items.
Dates are ISO YYYY-MM-DD. Uses Plaid /transactions/get with offset pagination (count=500 per page). If start_date is older than ~2 years before end_date, the window is clipped and a warning is emitted.
| Name | Required | Description | Default |
|---|---|---|---|
| start_date | Yes | ||
| end_date | Yes | ||
| account_ids | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds critical details: date format (ISO YYYY-MM-DD), pagination (offset-based, count=500), date window clipping with warning emission. 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?
Three tightly written sentences: purpose first, then technical specs. Every sentence adds value. No fluff.
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 output schema exists, return value details are unnecessary. The description covers date range, pagination, and constraints (healthy Items, clipping). Missing account_ids explanation and clarity on 'healthy Items' prevent a perfect score.
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 bears full burden. The start_date and end_date parameters are explained (format, clipping behavior), but account_ids is not described at all. This leaves a significant gap for the optional 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?
Description clearly states the tool fetches transactions in a date range 'across all healthy Items,' distinguishing it from siblings like search_transactions. The verb 'fetch' and resource 'transactions' are specific and unambiguous.
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 specifies when to use (date range queries) and hints at usage conditions (healthy Items, pagination). However, it does not explicitly state when not to use or name alternative tools for filtered searches, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every account across all linked Items, with balances.
Returns: {"accounts": [...], "warnings": [...]}. Warnings describe Items that are unhealthy (re-auth required, etc.) or hit API errors on this call.
| 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?
Annotations already indicate readOnlyHint=true. The description adds value by detailing the return format including warnings for unhealthy Items and API errors, which goes beyond the annotation.
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, no fluff. The return format is included concisely.
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 presence of output schema (implied), the description is fully complete. It explains the output structure and warning 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?
With zero parameters and 100% schema coverage, the description need not explain parameters. It appropriately focuses on the tool's behavior and output.
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 uses a specific verb 'List' and resource 'accounts' with scope 'across all linked Items'. It clearly distinguishes from siblings like 'get_balances' which are more 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?
The description implies usage for retrieving all accounts, but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search transactions by keyword across merchant, name, and counterparty names.
Fetches transactions in [start_date, end_date] and filters them with a case-insensitive substring match against:
merchant_name
name
counterparties[].name
The match is performed on the raw Plaid payload before shaping so that
counterparty names (which are dropped by shape_transaction) are
searchable. Dates are ISO YYYY-MM-DD. The window is clipped to ~2 years
and a WINDOW_CLIPPED warning is emitted when applicable.
Returns: {"transactions": [...], "warnings": [...]}
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| start_date | Yes | ||
| end_date | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds valuable behavioral details: case-insensitive substring match on raw Plaid payload, date formatting, window clipping, and warning emission. This goes 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?
The description is well-structured with bullet points, front-loaded purpose, and concise details. Every sentence adds value with no fluff.
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 search algorithm, date handling, and warnings, the description is complete. Output schema exists, so return values are covered.
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 covers 3 parameters with 0% description coverage. The description explains that query is a keyword substring match, dates are ISO YYYY-MM-DD, and window is clipped to ~2 years, adding significant 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 it searches transactions by keyword across merchant, name, and counterparty names. It distinguishes from siblings like get_transactions which likely retrieves all transactions without keyword filtering.
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 this tool: for keyword searching within a date range. It doesn't explicitly exclude alternatives, but the context of sibling tools implies get_transactions is for unfiltered retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_balancesget_institutions_statusget_investment_holdingsget_investment_transactionsget_liabilitiesget_recurring_transactionsget_transactionslist_accountssearch_transactionsScored across 9 tools
Each tool targets a distinct aspect of personal finance data (balances, transactions, investments, liabilities, etc.), with clear boundaries. There is no overlap in functionality; even transaction-related tools distinguish between regular, investment, recurring, and search operations.
All tools follow a consistent verb_noun pattern in snake_case, primarily using 'get_' for retrieval and 'list_' for accounts, which is predictable and unambiguous.
With 9 tools, the server is well-scoped for a personal finance data aggregator. Each tool serves a clear purpose without redundancy, covering core financial data retrieval needs.
The tool surface covers most essential read operations for personal finance: accounts, balances, transactions (multiple types), liabilities, and holdings. Minor gaps such as lack of categorization or income/expense summaries are acceptable for a focused data provider.
Query your real net worth, spending, transactions, budgets and portfolio from any MCP client.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Read-only bank & investment accounts via Plaid: balances, holdings, transactions, SQL analytics.
Personal finance for AI agents — onboard, import statements, categorize & budget over MCP.
