Skip to main content
Glama
chrischall

Credit Karma MCP

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

ck_sync_transactions

Idempotent

Sync Credit Karma transactions into the local SQLite database, then refresh account balances once (see ck_get_account_balances; a balance failure is reported in balances, never thrown; a call that pauses with more to fetch leaves…

Instructions

Sync Credit Karma transactions into the local SQLite database, then refresh account balances once (see ck_get_account_balances; a balance failure is reported in balances, never thrown; a call that pauses with more to fetch leaves balances to the call that finishes). Incremental by default (fetches since last sync + 30-day overlap for updates). There is no login flow: credentials are re-read from the saved session (ck_set_session), CK_COOKIES, or a signed-in creditkarma.com tab via the ContextMint Bridge extension; if none is usable it fails with an error saying how to sign back in. 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.

Input 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, walk the whole history with no date cutoff. Starts from the beginning, except that it continues a full backfill paused by max_pages. Also the way to restart after a sync that failed or stopped on a stuck cursor.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.1.2
    • changedInput schema / properties / force_full / description
      Previous value: -"If true, re-fetch all transactions from the beginning"New value: +"If true, walk the whole history with no date cutoff. Starts from the beginning, except that it continues a full backfill paused by max_pages. Also the way to restart after a sync that failed or stopped on a stuck cursor."
  2. Changed1 schema field changedv3.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. Changed1 schema field changedv2.5.0
    • 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"
+}
  4. First observedv2.3.1

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations: incremental vs full behavior, the exact resumability contract (another_run_needed:true plus a note, continue from where it stopped), that a balance failure is reported in `balances` and never thrown, and how auth is resolved or how it fails. This is rich behavioral context an agent cannot get from readOnlyHint/openWorldHint/idempotentHint alone.

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

Conciseness4/5

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

Front-loads the core action before the parenthetical caveats, and every clause carries real information. The nested parentheses make it dense to parse, but it is appropriately sized for the complexity involved.

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?

With no output schema, the description compensates by naming the response fields (`balances`, another_run_needed, a note) and the failure semantics. Auth prerequisites and resumption behavior are covered, so an agent has everything needed to call it correctly.

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 description coverage is 100%, so max_pages and force_full are already fully documented in the schema. The description adds little parameter-specific detail beyond restating that force_full restarts from a failed/stuck sync. Baseline 3 is appropriate.

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?

States a specific verb+resource: sync Credit Karma transactions into the local SQLite database, plus a balance refresh. It names the related sibling (ck_get_account_balances) and distinguishes itself from read-only siblings like ck_list_transactions by being the sync/persist operation.

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?

Explains the default incremental mode (since last sync + 30-day overlap), when resumption applies, and that credentials come from ck_set_session/CK_COOKIES/bridge, not a login flow. It routes to ck_get_account_balances for balances, but does not explicitly state when to prefer force_full or a sibling over this tool.

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

Deploy Server

Other Tools