Skip to main content
Glama
Sign In
e-arveldaja MCP Server

e-arveldaja MCP Server

by iseppo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Create Bank Account

create_bank_account

Add a bank account to e-arveldaja by supplying its name and IBAN, enabling bank transaction reconciliation and invoice display.

Instructions

Create a bank account

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": {
      "account_name_est": "<account_name_est>",
      "account_no": "<account_no>"
    },
    "name": "create_bank_account"
  }
}

Input Schema

NameRequiredDescriptionDefault
account_noYesAccount number (IBAN)
swift_codeNoSWIFT/BIC code
cl_banks_idNoBank ID
account_name_estYesAccount name
show_in_sale_invoicesNoShow on invoices

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.29.2
    • addedInput schema / additionalProperties
      Added value: +false
  2. Addedv0.25.3
  3. Removedv0.25.2
  4. First observedv0.18.1

TDQS

C2.2/5.0
Behavior2/5

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

Annotations already carry the full safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), so the bar is lower, but the description adds nothing beyond them: no auth/permission requirements, no note on whether created accounts are immediately usable, no mention of uniqueness constraints on account_no, and no statement of side effects. This tool is non-idempotent, which is worth flagging and is not stated.

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

Conciseness2/5

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

At four words the text is technically concise, but this is under-specification rather than conciseness: there is no front-loaded substance to trim. The single sentence conveys no information beyond the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a non-idempotent mutation tool touching financial master data, the description omits everything relevant: required-field expectations, whether duplicate account numbers are rejected, and what happens on success. The absence of an output schema means the description should carry more, not less.

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% with 5 documented parameters, so the schema does the heavy lifting and a baseline of 3 applies. The description adds no extra meaning about which fields are required or how they interact (e.g., cl_banks_id vs swift_code).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description is a verbatim restatement of the tool name and title ("Create Bank Account" / "Create a bank account") with no added specificity. It does not distinguish this tool from siblings like update_bank_account, delete_bank_account, or get_bank_account, nor does it indicate what an account creation entails.

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?

No when-to-use guidance, prerequisites, or alternative tools are named. An agent must infer from the tool name alone that this is the creation path in the bank-account CRUD family, with no explicit routing cues.

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