Skip to main content
Glama
chrischall

Credit Karma MCP

by chrischall
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Credit Karma MCP

CI npm license

A Model Context Protocol server that connects Claude to Credit Karma, giving you natural-language access to your transactions, spending patterns, and account summaries.

WARNING

AI-developed project. This codebase was entirely built and is actively maintained by Claude Code. No human has audited the implementation. Review all code and tool permissions before use.

What you can do

Ask Claude things like:

  • "Sync my latest transactions"

  • "What did I spend on food last month?"

  • "Show me my top merchants this year"

  • "How much did I spend in March compared to February?"

  • "Which accounts have the most activity?"

  • "Run a SQL query against my transactions"

Related MCP server: BudgetBakers MCP Server

Requirements

Acknowledgement of Terms

By using this MCP server, you acknowledge and agree to the following:

1. This server accesses your own Credit Karma account. Every request is dispatched through your own signed-in browser tab via the fetchproxy extension. You are the one logged in. It does not — and cannot — access anyone else's account.

2. Credit Karma's Terms govern your use of this server, just as they govern your direct use of creditkarma.com. The clauses most relevant here:

You must not sell, transfer, or assign your account to anyone else… you may not allow anyone else to log into our Services as you.

CK does contemplate third-party data retrieval at the user's direction (Section 3.7). There is no explicit anti-scraping clause in the membership agreement; Section 4.1 restricts copying or distributing CK content without express prior written consent.

You are agreeing to those terms — read by the maintainer 2026-05-23 — every time you invoke a tool in this server. Critically: this server runs as you, not as a third party logging in on your behalf. You direct the tool.

3. Personal, non-commercial use only. This project is not affiliated with, endorsed by, sponsored by, or in partnership with Intuit, Credit Karma, or any financial institution. It is a personal automation tool that reads your transaction history, spending categories, and account snapshots — the same data Credit Karma already shows you in their app. Do not use it on someone else's account, do not redistribute their content, and do not use it to make trading or lending decisions on behalf of others.

4. This server may break. Credit Karma rotates its internal endpoints; what works today may 404 tomorrow. This is the nature of unofficial integrations.

5. You accept full responsibility for any consequences of using this server in connection with your Credit Karma account — rate limiting, account warnings, suspension, or any enforcement action Intuit takes. If Credit Karma objects to your use, stop using this server. Do not commit your .env to git — your CK session/auth artifacts are credentials, and the Membership Agreement holds you responsible for their confidentiality.

This section is the maintainer's good-faith summary of the terms — it is not legal advice and does not modify or supersede Credit Karma's actual Membership Agreement.

Installation

1. Clone and build

git clone https://github.com/chrischall/creditkarma-mcp.git
cd creditkarma-mcp
npm install
npm run build

2. Configure

cp .env.example .env
# See "Authentication" below to get your CK_COOKIES value

3. Add to Claude

Claude Code — add to .mcp.json in your project:

{
  "mcpServers": {
    "creditkarma": {
      "command": "node",
      "args": ["/absolute/path/to/creditkarma-mcp/dist/index.js"]
    }
  }
}

Claude Desktop — edit ~/Library/Application Support/Claude/claude_desktop_config.json (Mac) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "creditkarma": {
      "command": "node",
      "args": ["/absolute/path/to/creditkarma-mcp/dist/index.js"],
      "env": {
        "CK_COOKIES": "CKTRKID=...; CKAT=eyJ...%3BeyJ...; ..."
      }
    }
  }
}

4. Restart Claude

Fully quit and relaunch. Then ask: "Sync my Credit Karma transactions".

Authentication

Credit Karma uses short-lived JWTs. This server handles automatic token refresh — you only need to set up credentials once (or when your session expires).

creditkarma-mcp tries three auth paths in priority order; whichever succeeds first is used. Existing setups keep working unchanged.

  1. CK_COOKIES env var (legacy). Set the full Cookie header in your Claude Desktop config or .env. This is the path shown in the config above.

  2. Cached session from ck_set_session. Once called, the tool persists the Cookie header to .env as CK_COOKIES — so subsequent runs collapse into path 1.

  3. fetchproxy fallback (no env vars needed — easiest onboarding). When neither is configured, the server reads CKAT + CKTRKID cookies once at startup from your already-signed-in creditkarma.com tab via the fetchproxy browser extension. After that one read, all CK API calls go directly from Node — the extension is not in the request hot path. Install the fetchproxy extension (Chrome Web Store / Safari .dmg), sign into creditkarma.com, and the MCP just works.

Set CK_DISABLE_FETCHPROXY=1 to opt out of the fallback (turns missing credentials into a hard error — useful in headless CI).

Getting your credentials (env-var path)

Option A — fetchproxy extension (recommended)

  1. Install the fetchproxy 0.3.0 extension (Chrome Web Store or Safari .dmg).

  2. Sign into creditkarma.com in that browser.

  3. Leave CK_COOKIES unset in your Claude config.

The MCP reads the HttpOnly CKAT + CKTRKID cookies via chrome.cookies.get on the first tool call, then operates direct-to-API from Node. To re-auth (e.g. after Credit Karma signs you out), just sign back in to creditkarma.com.

Option B — manual (DevTools)

  1. Log in to creditkarma.com in Chrome

  2. Open DevTools → Network → click any request to creditkarma.com → Request Headers

  3. Right-click the cookie header → Copy value

Then either paste into CK_COOKIES in your Claude config / .env, or call ck_set_session from within Claude with the Cookie header value.

The server extracts the access and refresh JWTs from the CKAT cookie inside the header and refreshes the access token automatically as needed.

Session expiry

  • Access token: ~15 minutes (auto-refreshed transparently)

  • Refresh token: ~8 hours

  • When the refresh token expires:

    • fetchproxy path: sign back into creditkarma.com — the MCP re-reads fresh cookies on the next tool call.

    • env-var path: grab a fresh Cookie header from DevTools and update CK_COOKIES (or call ck_set_session).

Available tools

Tool

What it does

ck_set_session

Store credentials from your browser Cookie header (auto-extracts JWTs from the CKAT cookie)

ck_sync_transactions

Sync transactions into the local SQLite database

ck_list_transactions

List transactions with filters (date, account, category, merchant, amount)

ck_get_recent_transactions

Fetch the N most recent transactions

ck_get_spending_by_category

Spending totals grouped by category

ck_get_spending_by_merchant

Spending totals grouped by merchant

ck_get_account_summary

Transaction counts and totals by account

ck_query_sql

Run a read-only SQL query against the local database

How it works

Transactions are synced from Credit Karma's GraphQL API into a local SQLite database (default: ~/.creditkarma-mcp/transactions.db). All query tools run against this local database — fast, offline-capable, and queryable with SQL.

Sync strategy: incremental by default (fetches since last sync date with a 30-day overlap for updates). Use force_full: true to re-fetch everything.

Auto-refresh: if the access token has expired, the server automatically refreshes it before syncing. If the refresh token has also expired, it throws an error asking you to re-authenticate.

Database schema

transactions (id, date, description, status, amount, account_id, category_id, merchant_id, raw_json)
accounts     (id, name, type, provider_name, display)
categories   (id, name, type)
merchants    (id, name)
sync_state   (key, value)

Configuration

Env var

Description

Default

CK_COOKIES

Full Cookie header from a signed-in creditkarma.com request

(unset — falls back to fetchproxy)

CK_DISABLE_FETCHPROXY

Set to 1 to skip the fetchproxy fallback (headless / CI)

(unset)

CK_DB_PATH

Path to SQLite database file

~/.creditkarma-mcp/transactions.db

Troubleshooting

"CK auth: set CK_COOKIES, or call the ck_set_session MCP tool, or install the fetchproxy extension…" — neither auth path is configured. Either fill in CK_COOKIES in your Claude config, or install the fetchproxy extension and sign into creditkarma.com in your browser.

"TOKEN_EXPIRED" — your refresh token has expired. Sign back into creditkarma.com (fetchproxy path) or grab a fresh Cookie header from DevTools and update CK_COOKIES / call ck_set_session.

"fetchproxy fallback failed" — the env-var path wasn't configured and the extension couldn't be reached. Confirm the fetchproxy extension is installed, signed into Credit Karma, and that it's running (open the extension popup). To disable the fallback, set CK_DISABLE_FETCHPROXY=1.

Sync returns 0 transactions — check that your auth is fresh. The refresh token inside the CKAT cookie expires after ~8 hours.

Tools not appearing — fully quit and relaunch Claude Desktop. In Claude Code, run /mcp to check server status.

"No such file or directory: dist/bundle.js" — run npm run build (not just tsc).

Security

  • Credentials are stored only in your local .env file (gitignored), Claude config, or your browser's cookie jar (fetchproxy path)

  • .env is written at mode 0600 (owner read/write only) by ck_set_session

  • ck_set_session refuses to save a refresh token whose JWT exp is already in the past — prevents stale credentials from polluting .env

  • The fetchproxy path doesn't persist anything to disk — cookies are read into memory once per MCP run, directly from the user's browser via chrome.cookies.get

  • The server never logs credentials; warnings go to stderr only (stdout is reserved for the MCP JSON-RPC stream)

  • Only SELECT queries are permitted via ck_query_sql — no writes to Credit Karma; the underlying node:sqlite prepare() also rejects multi-statement input

Development

npm test               # run the test suite (vitest)
npm run build          # compile TypeScript → dist/, bundle for MCPB
npm run test:watch     # watch mode
npm run test:coverage  # coverage report (CI enforces 100% on src/**)

Versions are bumped automatically by the Tag & Bump GitHub Action (.github/workflows/tag-and-bump.yml). Do not bump manually.

Pull requests

Changes land via PR, including for solo work — release notes are generated from merged PRs only (config in .github/release.yml). Apply one of these labels to every PR: enhancement, bug, security, refactor, documentation, test, dependencies, ci, or ignore-for-release (excludes from notes). The PR title becomes the changelog bullet, so write it like a user-facing entry.

Project structure

src/
  auth.ts               resolveAuth() — three-path priority (CK_COOKIES env / ck_set_session cache / fetchproxy), plus loadAuthIntoClient()
  client.ts             Credit Karma GraphQL client (auto-refresh, JWT helpers, cookie parser)
  index.ts              MCP server entry point; bootstraps tokens from CK_COOKIES
  db.ts                 SQLite schema, migrations, and upsert helpers
  transaction.graphql   Documents the transactions selection set (sent as a persisted-query hash, not this text)
  tools/
    auth.ts             ck_set_session — refuses stale refresh tokens, writes .env at 0600
    sync.ts             ck_sync_transactions — incremental sync with resume-on-failure
    query.ts            ck_list_transactions, ck_get_recent_transactions,
                        ck_get_spending_by_category, ck_get_spending_by_merchant,
                        ck_get_account_summary
    sql.ts              ck_query_sql — SELECT-only escape hatch
tests/
  helpers.ts            Shared test helpers (fakeServer, makeJwt)
  auth.test.ts          resolveAuth + loadAuthIntoClient (mocks @fetchproxy/bootstrap)
  client.test.ts
  db.test.ts
  tools/
    auth.test.ts
    sync.test.ts
    query.test.ts
    sql.test.ts

License

MIT

Available Tools

9 tools
ck_get_account_summaryB
Read-only

Return per-account debit, credit, and net totals.

ParametersJSON Schema
NameRequiredDescriptionDefault
end_dateNoYYYY-MM-DD
start_dateNoYYYY-MM-DD

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, consistent with the read operation described. The description adds what is returned (debit/credit/net) but no additional behavioral traits like rate limits, account scope, or data freshness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no redundancy, efficiently conveys the core purpose. Every word is necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has 2 optional parameters, read-only, but no output schema. Description does not clarify if totals are for all accounts, what 'net' means, or response format. Adequate but leaves ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for both start_date and end_date (YYYY-MM-DD). The description does not add extra meaning beyond the schema, so baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it returns per-account debit, credit, and net totals. It distinguishes from siblings like 'ck_list_transactions' but not explicitly; the verb 'Return' and resource 'account summary' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives like 'ck_get_spending_by_category' or 'ck_list_transactions'. The description does not mention prerequisites or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ck_get_recent_transactionsA
Read-only

Return the N most recent transactions. Convenience shortcut for ck_list_transactions.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of transactions to return (default 25)

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint true. Description adds that it returns 'most recent' but doesn't elaborate on ordering or limitations. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, each with clear purpose. No redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one parameter, the description combined with annotations and schema provides adequate context. Could clarify ordering criteria, but not necessary given it's a shortcut.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 'limit' with description. Description only reiterates the parameter indirectly. No added meaning beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it returns the N most recent transactions, and distinguishes itself as a convenience shortcut for ck_list_transactions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Describes it as a shortcut for ck_list_transactions, implying quick access to recent transactions. However, lacks explicit when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ck_get_spending_by_categoryB
Read-only

Group debit transactions by category and return totals.

ParametersJSON Schema
NameRequiredDescriptionDefault
accountNoPartial account name filter
end_dateNoYYYY-MM-DD
start_dateNoYYYY-MM-DD

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, and the description aligns with a read operation. However, no additional behavioral traits (e.g., data range, limits) are disclosed 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One concise sentence that front-loads the action and result. No extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is minimal and does not specify the output format, which is absent from an output schema. It omits what 'totals' means and whether credits are excluded. For a simple aggregation tool, more context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for all three parameters. The description adds no extra meaning beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it groups debit transactions by category and returns totals. It distinguishes from sibling tools that group by merchant or provide account summaries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 ck_get_spending_by_merchant. The description lacks context for selecting this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ck_get_spending_by_merchantA
Read-only

Return top merchants by total debit spend.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoDefault 25
categoryNoPartial category name filter
end_dateNoYYYY-MM-DD
start_dateNoYYYY-MM-DD

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint annotation confirms safety. The description adds the behavioral detail that only debit spend is considered, not credit. However, it does not disclose ordering, whether results are truncated, or response structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, direct sentence with no unnecessary words or fluff. Perfectly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with 4 optional params and no output schema. The description is adequate but missing details like ordering direction (e.g., descending by total spend) and whether 'top' is by count or amount. Could be more complete for autonomous usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 4 parameters are described in the schema (100% coverage). The description adds no extra parameter semantics beyond what the schema provides, such as the default for limit or date format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Return top merchants by total debit spend' clearly states the verb, resource, and scope, distinguishing it from sibling tools like ck_get_spending_by_category.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives such as ck_get_spending_by_category or ck_list_transactions. The description implies usage for merchant analysis but lacks explicit context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ck_healthcheckVerify credentials and upstream reachabilityA
Read-onlyIdempotent

Resolves the credential the way real tools do, then makes one authenticated request to creditkarma.com. Reports which source supplied the credential, whether creditkarma.com accepted it, the round-trip time, and a plain-English hint distinguishing 'no credential' from 'credential rejected' from 'a creditkarma.com-side problem'. Call this when a real tool fails and you want to know which hop broke. Read-only; never returns the credential itself.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already supply readOnly, idempotent, and openWorld hints, so the bar is lower. The description adds valuable behavioral detail beyond those hints: it resolves credentials the same way real tools do, makes exactly one authenticated request, reports the credential source, distinguishes failure modes, and explicitly says it never returns the credential. This is strong additional transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence earns its place: behavior, reported outputs, trigger condition, and safety guarantee. The description is front-loaded with the core action and remains concise despite covering subtle failure-mode distinctions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and no output schema, the description fully covers what the agent needs: what the tool does, what it returns, how to interpret results, when to use it, and that it never exposes credentials. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, and schema coverage is 100%, so description carries no parameter burden. The baseline for zero-parameter tools is 4, and the description does not need to explain inputs. It stays safe rather than claiming extra credit for describing non-existent parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb-resource pairing: it resolves the credential, makes one authenticated request to creditkarma.com, and reports diagnostic results. It clearly distinguishes itself from the sibling transaction and query tools by being a health check that diagnoses which hop broke.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to call it: 'Call this when a real tool fails and you want to know which hop broke.' It gives clear context for use but does not explicitly name alternatives or state when not to use it, though the diagnostic purpose makes the boundary fairly obvious.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ck_list_transactionsB
Read-only

List transactions with optional filters. Paginated.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoDefault 50
offsetNoDefault 0
statusNoe.g. posted, pending, cancelled
accountNoPartial account name match
categoryNoPartial category name match
end_dateNoYYYY-MM-DD
merchantNoPartial merchant name match
max_amountNoMaximum absolute amount
min_amountNoMinimum absolute amount
start_dateNoYYYY-MM-DD

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already convey read-only behavior. The description adds pagination context but does not disclose further traits like rate limits or data freshness. With annotation coverage, this is adequate but not exemplary.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise with two purposeful sentences. Front-loaded with the primary action and key features (filters, pagination). No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 10 optional parameters and no output schema, the description is minimal. It covers the core function but omits details like default pagination behavior or response structure. Adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description does not need to repeat parameter details. It only generically mentions 'optional filters' without enhancing understanding beyond the schema, earning a baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists transactions with optional filters and pagination. However, it does not explicitly differentiate from sibling tools like ck_get_recent_transactions, which likely has a more specific scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 ck_get_recent_transactions or ck_query_sql. It implies usage for general filtered listing but lacks explicit when-to-use or when-not-to-use instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ck_query_sqlA
Read-only

Execute a raw SQL SELECT query (CTEs via WITH ... SELECT are supported) against the transactions database. Non-SELECT statements (INSERT, UPDATE, DELETE, DROP, etc.) are rejected. Tables: transactions, accounts, categories, merchants, sync_state.

ParametersJSON Schema
NameRequiredDescriptionDefault
sqlYesA SELECT SQL statement

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description complements the readOnlyHint annotation by confirming only SELECT queries are allowed, adding support for CTEs and listing tables, giving full behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence conveys all essential information: allowed SQL type, rejection of other types, CTE support, and table names. Every word is productive.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, read-only, no output schema), the description covers the necessary details: what SQL is accepted, what tables exist, and constraints. No gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes the 'sql' parameter as 'A SELECT SQL statement', achieving 100% coverage. The description adds value by noting CTE support and available tables, going beyond the schema's brief description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Execute', the resource 'raw SQL SELECT query', and specifies it's against the 'transactions database', distinguishing it from sibling tools that offer pre-built functions like filtering or aggregation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states that non-SELECT statements are rejected and lists available tables, providing clear usage boundaries. However, it does not explicitly compare to sibling tools or mention when to prefer this tool over them.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ck_set_sessionA

Store a Credit Karma session to enable automatic token refresh. Pass the full Cookie header from a signed-in creditkarma.com request (Chrome DevTools → Network → any creditkarma.com request → Request Headers → right-click the cookie header → Copy value). For most users the easier onboarding path is to install the fetchproxy extension and sign into creditkarma.com — the MCP reads the cookies automatically.

ParametersJSON Schema
NameRequiredDescriptionDefault
cookiesYesFull Cookie header from a signed-in creditkarma.com request (contains CKAT, CKTRKID, etc.)

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations report readOnlyHint=false, indicating mutation. The description confirms this by stating it stores session data for token refresh. It explains the mechanism (cookie storage) without contradicting annotations. It could disclose more about potential side effects (e.g., token refresh behavior) but is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two efficient sentences: first states purpose, second gives actionable instructions. No fluff, front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple authentication setup tool with one required parameter and outputless, the description covers purpose, usage method, and alternative path completely. No gaps remain for an agent to misuse the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema provides a good description for the single 'cookies' parameter. The description adds further context by specifying what the cookie contains (CKAT, CKTRKID, etc.) and how to obtain it, enhancing understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Store a Credit Karma session to enable automatic token refresh.' The verb 'store' and noun 'session' are specific. Sibling tools are transaction/account focused, so this authentication tool is well-distinguished.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit instructions for two usage paths: manually copying the Cookie header or installing the fetchproxy extension. It implicitly tells when to use (when needing automatic token refresh for other Credit Karma tools) but does not explicitly state when not to use or contrast with alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ck_sync_transactionsA

Sync Credit Karma transactions into the local SQLite database. Incremental by default (fetches since last sync + 30-day overlap for updates). If no valid token, initiates the login/MFA flow automatically. Bounded and resumable: when it pauses with more to fetch it returns another_run_needed:true and a note — run it again and it continues from where it stopped.

ParametersJSON Schema
NameRequiredDescriptionDefault
max_pagesNoPages this call may fetch before pausing (a deep backfill is hundreds). Overrides CK_SYNC_MAX_PAGES. Omit both for an unbounded sync.
force_fullNoIf true, re-fetch all transactions from the beginning

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only indicate readOnlyHint:false, so the description carries the burden of explaining mutation. It goes beyond by detailing the incremental fetch range (last sync + 30-day overlap), automatic token/MFA handling, and the bounded/resumable contract with another_run_needed:true. This is rich behavioral disclosure that annotations alone cannot provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: purpose and scoping, authentication behavior, and pause/resume semantics. Information is front-loaded with the core purpose, followed by essential behavioral details. No fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains key side effects and return indicators (another_run_needed:true). However, it does not detail the full return shape or what happens to pre-existing local rows (e.g., upsert vs. append), which is relevant for a sync tool. Still, the main operational aspects are covered, making it mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema already has 100% coverage with descriptions for both max_pages and force_full. The description adds valuable context, such as max_pages overriding the CK_SYNC_MAX_PAGES environment variable and the meaning of omitting it (unbounded sync). This extra semantic layer beyond the schema earns a score above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description opens with 'Sync Credit Karma transactions into the local SQLite database' – a specific verb (sync) and resource (transactions into local DB), clearly distinguishing this from siblings that merely list/get data. It also specifies the incremental default behavior, further clarifying its role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context on when it runs (incremental with overlap) and automatically handles auth via login/MFA. It also explains the bounded/resumable behavior with another_run_needed, but does not explicitly contrast with sibling tools or state when to prefer this over ck_list_transactions, so it falls short of full usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev2.7.0
    • Addedck_healthcheck
  2. 1 tool updatev2.5.0
    • Changedck_sync_transactions1 field changed
      • addedInput schema / properties / max_pages
        Added value: +{
+  "description": "Pages this call may fetch before pausing (a deep backfill is hundreds). Overrides CK_SYNC_MAX_PAGES. Omit both for an unbounded sync.",
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}
  3. 8 tool updatesv2.3.1
    • First observedck_get_account_summary
    • First observedck_get_recent_transactions
    • First observedck_get_spending_by_category
    • First observedck_get_spending_by_merchant
    • First observedck_list_transactions
    • First observedck_query_sql
    • First observedck_set_session
    • First observedck_sync_transactions
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation4/5

Most tools target clearly distinct operations: healthcheck, session setup, sync, listing, three spend/account aggregations, and raw SQL. The main overlap is ck_get_recent_transactions being a documented convenience shortcut for ck_list_transactions, and ck_query_sql intentionally overlaps lower-level reads, but the descriptions keep the boundaries clear.

Naming Consistency4/5

All tools share a consistent ck_ prefix and snake_case style, with most following a verb_noun pattern like ck_set_session, ck_sync_transactions, and ck_list_transactions. ck_healthcheck is the main deviation since it lacks a verb, and ck_query_sql uses a different verb than get/list, but the pattern remains predictable.

Tool Count5/5

Nine tools is well-scoped for a Credit Karma transactions and analytics server: setup, healthcheck, sync, listing, and several focused aggregation/query tools. Each tool has a justifiable place, and the count is neither too thin nor bloated.

Completeness5/5

The tool surface covers the full workflow: credential/session setup, health diagnostics, incremental syncing, transaction listing, spending aggregation, account summaries, and raw SQL access for advanced queries. For a read-only transactions analytics domain, there are no significant gaps that would cause agent failures.

Maintenance

ActivityActive
ResponsivenessResponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Monarch Money MCP Server

    whitebirchio
    A
    license
    A
    quality
    D
    maintenance
    Enables integration with Monarch Money to query financial data, analyze spending patterns, track budgets, and get personalized financial insights through conversational AI with Claude Desktop.
    11
    3
    ISC

  • BudgetBakers MCP Server

    vmrchnk
    A
    license
    A
    quality
    D
    maintenance
    Integrates Claude with the BudgetBakers Wallet API to access financial data including accounts, transactions, categories, and spending analytics.
    8
    30
    MIT

  • Yodlee MCP Server

    ashishmerani
    A
    license
    Not graded
    quality
    D
    maintenance
    Connects Claude Desktop to Yodlee financial data, enabling account management, transaction queries, spending summaries, and audio narrations.
    1
    MIT

  • personal-capital-connector-mcp

    meetv123
    F
    license
    A
    quality
    C
    maintenance
    Enables Claude to query Empower/Personal Capital financial accounts, net worth, transactions, and asset allocation via natural language.
    5
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chrischall/creditkarma-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server