Server provides five MCP tools to interact with your Personal Capital / Empower financial data:
check_auth_status – Verify whether your session is authenticated and valid.
list_accounts – List accounts with balances, grouped by type; filter by category or hide zero-balance accounts.
get_net_worth – Get net worth summary with total assets vs liabilities and category subtotals.
get_transactions – Fetch recent transactions (default 30 days), filtered by search keyword and minimum amount; returns up to 100 most recent.
get_asset_allocation – Show investment holdings and asset allocation by asset class, optionally filtered by account.
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., "@Personal Capital MCP Connector What's my net worth?"
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.
personal-capital-connector/
├── pyproject.toml
└── src/personal_capital_connector/
├── __init__.py
├── __main__.py
├── auth.py # session persistence + 2FA flow
├── client.py # API wrapper + data formatters
├── server.py # FastMCP server with 5 tools
└── cli.py # CLI entry pointTool | What it answers |
| "What's my Chase credit card balance?" / "Show my savings accounts" |
| "What's my net worth?" / "How much do I owe vs own?" |
| "What did I spend at restaurants last month?" |
| "What am I holding in my 401k?" / "Which funds am I most concentrated in?" |
| "Is my Empower session still valid?" |
get_transactions parametersQuery a date range or a lookback window, filter, and page through results.
Parameter | Default | Notes |
| 30 | Lookback from today. Ignored when |
| — | ISO |
| — | Substring match on description, original description, or merchant. Comma-separated terms are ORed: |
| — | Substring of the account name, e.g. |
| — | Substring of the Personal Capital category, e.g. |
| 0 | Absolute-value bounds. |
| 100 / 0 | Page through results. The header always reports the full match count. |
| false | Sort ascending by date. |
Amounts are signed: money out is negative, money in is positive. The header shows the net, gross in, and gross out for everything matched — not just the rows on the current page.
Transactions — 2026-03-01 to 2026-03-31
3 of 271 matched
Matched total: net $17,746.50 (in $377,693.19 / out $359,946.69)
2026-03-31 5,516.08 Brokeragelink - Contribution [Amazon 401(k) Plan] (Retirement Contributions)
...
268 more. Re-run with offset=3 to continue.Install uv: https://docs.astral.sh/uv/
Step 1 — Authenticate once (interactive 2FA):
uv run --directory {full path to this directory} personal-capital-connector authYour session is saved to ~/.config/personal-capital-connector/session.json (chmod 600). Re-run this any time your session expires.
Step 2 — Add to Claude Desktop's MCP settings (e.g. ~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"personal-capital": {
"command": "{full path to uv}",
"args": [
"run",
"--directory",
"{full path to this directory}",
"personal-capital-connector"
]
}
}
}Step 3 — Restart Claude and start asking questions.
Check whether the Personal Capital session is authenticated and valid. Returns a status message. If not authenticated, explains how to fix it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it returns a status message and provides fix instructions. No contradictory annotations. For a read-only status check, this is adequate, though it doesn't detail potential side effects or session refresh behavior.
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 efficient sentences that front-load the main purpose. Every sentence adds value with zero 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?
Fully adequate given no parameters and presence of an output schema. Covers purpose, behavior, and guidance for an auth check 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 exist, and schema coverage is 100%. Description adds no param-specific info, which is acceptable as there are none to describe.
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 checks authentication status for a Personal Capital session. The verb 'check' and resource 'auth status' are specific and distinguish from sibling tools that retrieve financial data.
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 use before other operations by stating it checks validity and offers guidance if not authenticated. However, it does not explicitly state when to use or not use it, nor mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show investment holdings and asset allocation breakdown. Displays allocation by asset class (US Stocks, International Stocks, Bonds, etc.) with dollar values and percentages, then lists holdings per account. Use account_filter to focus on retirement accounts, a specific brokerage, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| account_filter | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It explains that the tool shows allocation by asset class with dollar values and percentages, and lists holdings per account. However, it does not mention whether data is real-time or historical, any authentication requirements, or if the tool is read-only (assumed safe). Adequate but not thorough.
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 concise sentences: the first states the main action, the second elaborates on output details, and the third provides parameter usage. It is front-loaded with the core purpose, with no fluff or 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 that an output schema exists (context signals indicate true), the description does not need to explain return structure. It sufficiently covers the key behaviors (asset class breakdown and per-account listing), includes parameter usage, and matches the tool's complexity. Minor omission: no mention of data scope (e.g., all accounts or filtered).
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 has 0% description coverage for the only parameter, account_filter. The description adds value by stating 'Use account_filter to focus on retirement accounts, a specific brokerage, etc.,' which gives contextual usage beyond the parameter name. This compensates for the schema's lack of descriptions, though format constraints are not detailed.
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 opens with 'Show investment holdings and asset allocation breakdown,' clearly specifying the verb and resource. It further details the output format (by asset class with values and percentages, then per account), making the tool's purpose unambiguous and distinguishing it from siblings like get_transactions or get_net_worth.
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 does not explicitly state when to use this tool versus alternatives. It provides parameter guidance ('Use account_filter to focus on retirement accounts...') but lacks comparison or exclusions relative to sibling tools. The purpose implies usage context, but direct guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a summary of current net worth broken down into total assets vs total liabilities, with subtotals by account category (cash, investments, credit cards, loans).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosure. It does not mention whether results are real-time or cached, or if special authentication is needed. The description only specifies the output content.
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, efficient sentence that immediately states the tool's purpose and output structure. No superfluous 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 zero parameters and the existence of an output schema, the description provides a complete picture of what the tool returns: a net worth summary with breakdowns. No additional context is necessary.
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?
There are no parameters, so the description cannot add meaning beyond the schema. Baseline of 4 is appropriate as the description is not required to elaborate on nonexistent 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 clearly states it gets a summary of current net worth with a breakdown into assets vs liabilities and by account category. It effectively differentiates from siblings like get_asset_allocation and list_accounts.
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. The description implies it's for a high-level overview, but lacks explicit when or when-not recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch recent transactions from all connected accounts. Supports filtering by keyword (merchant/description) and minimum dollar amount. Returns up to 100 transactions sorted most-recent first.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| search | No | ||
| min_amount | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses key behavioral traits: returns up to 100 transactions sorted most-recent first. This is good context for an agent. Missing details like authentication needs or side effects, but given it's a fetch operation, this is acceptable.
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, filtering, output characteristics. No redundancy and 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 existence of an output schema (not shown), the description does not need to detail return values. It covers purpose, filtering, and output limits. However, the unexplained 'days' parameter is a gap in 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 has 3 parameters: days, search, min_amount. Description explains search (keyword, merchant/description) and min_amount (dollar amount) but omits any explanation of the 'days' parameter. Schema description coverage is 0%, so the description should compensate fully but does not.
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 verb 'Fetch' and resource 'transactions' with scope 'from all connected accounts'. This distinguishes it from siblings like list_accounts (accounts) and get_net_worth (summary) which are clearly different.
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 mentions filtering capabilities (keyword, min_amount) but does not explicitly state when to use this tool versus alternatives or provide when-not-to-use scenarios. However, sibling tool names make the differentiation obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Personal Capital / Empower accounts with current balances. Accounts are grouped by type: cash (checking/savings), credit (credit cards), investment (brokerage/401k/IRA), loan (mortgage/auto/student), and other. Closed accounts are always excluded. Zero-balance accounts are shown by default. Use type_filter to narrow to a specific category.
| Name | Required | Description | Default |
|---|---|---|---|
| type_filter | No | all | |
| hide_zero_balance | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing that closed accounts are excluded, zero-balance accounts are shown by default, and grouping by type. It omits authentication requirements and error handling, but covers core 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?
The description is four sentences, each serving a distinct purpose: core function, grouping, default behavior, and filtering option. No extraneous words, well-organized.
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, the description need not explain return values. It covers key behaviors (grouping, closed account exclusion, zero-balance handling, filtering). Missing authentication or error context, but sufficient for a list 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 coverage is 0%, so the description must add meaning. It explains the purpose of both parameters: type_filter narrows to a category with enum values mapped to account groupings, and hide_zero_balance controls whether zero-balance accounts are hidden. This adds significant value beyond the schema's bare enum 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 'List all Personal Capital / Empower accounts with current balances', specifying the verb (list), resource (accounts), and scope (all, with balances). It differentiates from siblings by detailing grouping by type and behaviors like excluding closed accounts.
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 context for when to use this tool (to list accounts) and mentions the type_filter for narrowing categories. However, it does not explicitly state when not to use it or offer alternative tools; sibling tools like get_net_worth or get_transactions imply different use cases.
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.0check_auth_statusget_asset_allocationget_net_worthget_transactionslist_accountsEach tool has a clearly distinct purpose: authentication status, account listing, net worth summary, transaction history, and investment allocation. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., check_auth_status, list_accounts, get_net_worth). The conventions are uniform and predictable.
With 5 tools, the set is well-scoped for a personal finance data connector. Each tool earns its place, covering essential read operations without being bloated or sparse.
The tools provide comprehensive coverage for reading personal finance data: authentication, accounts, net worth, transactions, and asset allocation. No obvious gaps for a read-only connector.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Query your real net worth, spending, transactions, budgets and portfolio from any MCP client.
Personal finance, bank account, and shared memory connector for Claude, ChatGPT, Gemini Spark & more
Ask your AI about bank accounts, spending, debts, holdings, and investment activity.
Personal finance assistant — track transactions, budgets, net worth via Plaid
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/PaulNorton/personal-capital-connector-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
