Skip to main content
Glama
chrischall

Credit Karma MCP

by chrischall

ck_sync_transactions

Sync Credit Karma transactions into a local SQLite database, resuming automatically after login or pagination pauses to keep spending data current for analysis.

Instructions

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.

Input Schema

TableJSON 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.6/5.0
Behavior5/5

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

Beyond the readOnlyHint:false annotation, the description discloses meaningful behavior: it writes to a local SQLite database, performs incremental syncs with overlap, can trigger authentication flows, and is bounded/resumable via another_run_needed. This is substantial additional transparency, with no contradiction.

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

Conciseness5/5

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

Three dense sentences with no filler. The purpose is front-loaded, and each sentence adds meaningful behavioral or operational detail.

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 2-parameter tool with no output schema, the description covers the key invocation behaviors and the resumption contract. It stops slightly short of fully describing the return payload or failure modes, but nothing critical is missing for correct invocation.

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?

Schema description coverage is 100%, so the baseline is 3, but the description adds context beyond the schema: it explains the pausing/resuming model and another_run_needed:true, which enriches the meaning of max_pages and force_full.

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 states a specific verb and resource: 'Sync Credit Karma transactions into the local SQLite database.' This clearly differentiates it from the sibling get/list/query tools, which are read operations rather than write-oriented sync operations.

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 clear operational context: incremental by default, 30-day overlap, auto login/MFA when needed, and resumability. It does not explicitly state when to use this tool versus alternatives or when not to use it, so it falls short of a perfect score.

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