finance

Accounts: Import accounts from CSV

import_accounts

    Bulk-create accounts from CSV text.

    Parity with the web account-import flow, adapted for a chat agent: pass
    the CSV as text (not a file). Columns are auto-detected (name + type are
    required; balance, institution, interest_rate, credit_limit,
    minimum_payment, term_months optional). Rows that can't be parsed are
    skipped and reported; valid rows still import. Created atomically.

    Account type accepts friendly strings (checking, savings, cash, credit
    card, loan, mortgage, student loan, investment, other asset, other
    debt). Respects the Free-plan account cap — if existing + new accounts
    would exceed it, the whole import is rejected before any insert.

    Args:
        csv_text: CSV content as a string (header row + account rows). Max
            1000 rows.
        skip_duplicates: When True (default), skip rows whose name matches
            an existing active account. When False, a duplicate name still
            imports (creating a second account with that name).

    Returns:
        ``{"success": True, "imported_count": N, "skipped_duplicates": K,
        "error_count": M, "errors": [...up to 20...], "account_names":
        [...]}`` on success, or ``{"error": "..."}`` (empty/invalid CSV, no
        valid rows, all duplicates, or account-limit exceeded).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "csv_text": "<csv_text>"
    },
    "name": "import_accounts"
  }
}

Input Schema

Name	Required	Description	Default
`csv_text`	Yes
`skip_duplicates`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 22, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The description goes well beyond the sparse annotations. It discloses partial-failure behavior (invalid rows are skipped and reported while valid rows import), atomicity (created atomically), the Free-plan account cap enforcement (whole import rejected before any insert), and the exact return/error shape. This gives an agent a thorough picture of what will happen.

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?

The description is structured with clear paragraphs and an Args/Returns block. It is longer than minimal but every sentence carries useful information; the core purpose is front-loaded. A minor deduction because the return-value section is somewhat verbose, though it is valuable with no output schema present.

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?

Even without an output schema, the description specifies the success and error return formats, input constraints (max 1000 rows, required/optional columns), duplicate handling, and the account cap behavior. For a bulk-import tool with both validation and partial-failure semantics, this is complete enough for an agent to invoke it correctly.

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

Parameters5/5

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

With 0% schema description coverage, the description fully compensates: it explains csv_text as CSV string with header row, max 1000 rows, and describes skip_duplicates behavior with both True and False outcomes. It also explains the auto-detected columns and required vs optional fields, adding meaning that the schema completely lacks.

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 opens with 'Bulk-create accounts from CSV text' – a specific verb, resource, and method that clearly distinguishes this from single-account creation via create_account and from import_transactions. The title and first sentence together make the tool's scope immediately obvious.

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 clearly establishes the context: this is for bulk-importing accounts from CSV text, adapted from the web flow for a chat agent. It explains how to pass CSV as text and what fields are auto-detected, but it does not explicitly name alternatives or say when not to use it (e.g., for single accounts or transaction imports).

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

All finance tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?