Skip to main content
Glama
krax1337

mcp-server-zenmoney

by krax1337

Create account

create_account

Create a manual cash, card, checking, or e-money account in ZenMoney. Use it to add accounts not synced by a bank, with opening balance and currency.

Instructions

Create a cash, card, checking or e-money account. Bank-synced accounts are created by ZenMoney itself.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNocash, ccard (card), checking, emoneycash
titleYes
balanceNoOpening balance
savingsNo
currencyNoISO code; defaults to the main currency
in_balanceNoCount in the total balance and reports
credit_limitNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the agent knows this is a non-destructive write that may duplicate on repeat calls. The description adds only the bank-sync exclusion and says nothing about permissions or currency defaults beyond the schema.

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, zero filler, with the supported types front-loaded and the exclusionary note second. Nothing wastes space.

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 7-parameter mutation tool with no output schema and only 57% schema coverage, the description is thin. It never explains opening balance behavior, savings, credit_limit, or in_balance, so an agent must infer semantics from terse schema strings alone.

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 57%, with type, balance, currency, and in_balance already described in the schema. The description usefully glosses 'ccard' as 'card' and lists the valid types, but leaves title, savings, and credit_limit (including that credit_limit applies to card/e-money accounts) unaddressed.

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 (create) and resource (account) plus the supported account types, which maps directly to the enum. It also draws a scope boundary by excluding bank-synced accounts, though it does not name sibling tools like update_account or adjust_account_balance.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The note that bank-synced accounts are created by ZenMoney itself is a genuine when-not-to-use signal. However, there is no guidance on choosing between create_account, update_account, and adjust_account_balance, or on prerequisites such as required currency context.

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