Skip to main content
Glama
Bank File Tool Statement Review MCP

Bank File Tool Statement Review MCP

by Content-true

Review export headers

review_export_headers

Verify CSV or spreadsheet export headers include required date, description, and amount fields before reconciliation. Inspect column names only—no transaction data.

Instructions

Locally inspect column names from a CSV or spreadsheet export. Supply headers only, never transaction rows or account details.

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": {
      "headers": "<headers>"
    },
    "name": "review_export_headers"
  }
}

Input Schema

NameRequiredDescriptionDefault
headersYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the burden, and it does disclose something valuable: processing happens locally and the agent must never pass transaction rows or account details, which signals a privacy-preserving, non-persistent operation. However, it remains silent on whether anything is stored or transmitted, and on what the tool actually produces for a tool literally named 'review'.

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 short sentences, no filler, with the core action front-loaded and the data-handling constraint immediately after. Nothing could be removed without losing meaning.

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 single-parameter tool with no output schema, the description explains the input well but never says what comes back — recognized column names, a mapping suggestion, warnings, or nothing at all. Given the name 'review', the absent return-value hint is a real gap that the lack of an output schema leaves unfilled.

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 0%, so the description must compensate, and it does clarify that 'headers' means column names taken from an export rather than full rows. It adds no guidance on expected format (raw header line vs. split names) or on the schema's own limits (1–40 items, 120 chars each).

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?

States a specific verb and resource: inspecting column names from a CSV or spreadsheet export, and the word 'Locally' scopes it. Its purpose is clearly distinct from the siblings (totals reconciliation, official links), though it does not explicitly name them as alternatives.

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?

There is no explicit statement of when to use this versus reconcile_statement_totals, nor any workflow context (e.g. 'call this first to map columns before reconciling'). The sentence 'Supply headers only, never transaction rows' is an input constraint, not usage routing, so it does not count as when-to-use guidance.

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