Skip to main content
Glama
bankstatemently

bankstatemently

Official
by bankstatemently
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Remote

Rate Statement Conversion

rate_statement
Destructive

Rate how accurately a converted bank statement was parsed by submitting a 1-5 score with optional structured feedback; updates existing ratings and contributes to public averages.

Instructions

Report how well a previously converted bank statement was parsed: submit a 1-5 rating, optionally with structured feedback at any rating. Your rating counts toward the average ratings shown on bankstatemently.com. Calling this again for the same document updates your existing rating without clearing feedback already submitted for it. Returns the stored rating state in the response — there is no separate tool to read your own rating back. Every response includes a "summary" field: use it as the single source of truth for what happened.

Input Schema

NameRequiredDescriptionDefault
ratingYes1-5 star rating for this conversion
feedbackNoFree-text feedback.
document_idYesDocument ID (from convert_statement or list_statements)
feedback_categoriesNoStructured feedback categories.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv2.1.0
    • removedInput schema / properties / export_format
      Removed value: -{
-  "description": "Which output format you exported this conversion to (csv, xlsx, qbo, or xero).",
-  "enum": [
-    "csv",
-    "xlsx",
-    "qbo",
-    "xero"
-  ],
-  "type": "string"
-}
    • changedInput schema / properties / feedback / description
      Previous value: -"Free-text feedback. Only accepted when rating is 3 or below."New value: +"Free-text feedback."
    • changedInput schema / properties / feedback_categories / description
      Previous value: -"Structured feedback categories. Only accepted when rating is 3 or below."New value: +"Structured feedback categories."
    • removedInput schema / properties / use_case
      Removed value: -{
-  "description": "Tags describing what you use the converted data for.",
-  "items": {
-    "enum": [
-      "bookkeeping",
-      "tax_preparation",
-      "financial_analysis",
-      "audit_compliance",
-      "reconciliation",
-      "personal_finance",
-      "data_migration",
-      "other"
-    ],
-    "type": "string"
-  },
-  "type": "array"
-}
    • removedInput schema / properties / use_case_other
      Removed value: -{
-  "description": "Free-text use case, for when \"other\" is among the use_case tags.",
-  "maxLength": 500,
-  "type": "string"
-}
  2. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations declare destructiveHint=true, readOnlyHint=false, openWorldHint=true; the description usefully qualifies the destructive surface by stating a repeat call 'updates your existing rating without clearing feedback already submitted for it', and it discloses the public-average effect on bankstatemently.com. Combined with the return-value and summary-field guidance, it adds real behavioral context beyond the annotations, though it omits auth/rate-limit details.

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-loaded with the core action (rate a converted statement), followed by the most decision-relevant edge cases (repeat-call semantics, no read-back tool, summary field). The bankstatemently.com detail is slightly peripheral but the prose remains compact with no filler sentences.

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 mutating tool with no output schema, the description covers the gap by explaining that the stored rating state is returned and that a 'summary' field is the source of truth. It also handles the idempotency/persistence question an agent would otherwise have to guess, leaving only minor return-shape detail unspecified.

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 the schema already documents all four parameters, and the baseline is 3. The description's only added semantics are 'at any rating' for the optional feedback and its restatement of the 1-5 scale, which is marginal value over the schema.

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: 'Report how well a previously converted bank statement was parsed' with the concrete action of submitting a 1-5 rating plus optional structured feedback. The purpose is unambiguous and distinct from conversion siblings like convert_statement, though it does not name a sibling by name in the description text (only the schema's document_id field references convert_statement/list_statements).

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?

Clear context: 'previously converted bank statement' implies use after convert_statement, and 'optionally with structured feedback at any rating' tells the agent feedback is not gated on rating value. It also clarifies the repeat-call behavior (updates existing rating) and notes there is no separate read-back tool, but stops short of explicit when-not-to-use or naming an alternative rating path.

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