e-arveldaja MCP Server

Book Owner-Paid Expense

create_owner_expense_reimbursement

Creates a journal entry to reimburse an owner for a business expense paid personally, recording the expense, VAT, and owner payable.

Instructions

Create a journal for a business expense paid personally by the owner.

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": {
      "owner_client_id": "<owner_client_id>",
      "effective_date": "<effective_date>",
      "description": "<description>",
      "net_amount": "<net_amount>",
      "vat_rate": "<vat_rate>",
      "expense_account": "<expense_account>"
    },
    "name": "create_owner_expense_reimbursement"
  }
}

Input Schema

Name	Required	Description
`vat_rate`	Yes	VAT rate as decimal (e.g. 0.24 for 24%; 0 only when the document has no VAT). Must be a fraction, NOT a percentage — use 0.24, not 24. For non-deductible VAT keep the document's rate (or pass vat_amount) and set vat_deduction_mode="none": the VAT is then added to the expense and the owner payable.
`net_amount`	Yes	Net amount (without VAT)
`vat_amount`	No	Exact VAT amount (overrides vat_rate if provided)
`description`	Yes	Expense description
`vat_account`	No	Input VAT account (default 1510)
`effective_date`	Yes	Expense date (YYYY-MM-DD)
`document_number`	No	Receipt/document number
`expense_account`	Yes	Expense account number (e.g. 5000, 6000)
`owner_client_id`	Yes	Owner/shareholder client ID
`payable_account`	No	Payable to owner account (default 2110)
`vat_deduction_mode`	No	VAT deduction mode. Use partial with deductible_vat_amount.
`deductible_vat_amount`	No	Deductible part of VAT when vat_deduction_mode=partial, or an explicit deductible VAT amount to override the default or configured ratio.
`expense_account_dimension_id`	No	Dimension ID of the expense account; required when that account has dimensions
`payable_account_dimension_id`	No	Dimension ID of the payable account (e.g. the owner's own dimension); required when that account has dimensions (e.g. a 2110 split by lender)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.39.0Nov 5, 2026

changedInput schema / properties / vat_rate / description

Previous value: -"VAT rate as decimal (e.g. 0.24 for 24%; 0 = no VAT/non-deductible). Must be a fraction, NOT a percentage — use 0.24, not 24."New value: +"VAT rate as decimal (e.g. 0.24 for 24%; 0 only when the document has no VAT). Must be a fraction, NOT a percentage — use 0.24, not 24. For non-deductible VAT keep the document's rate (or pass vat_amount) and set vat_deduction_mode=\"none\": the VAT is then added to the expense and the owner payable."

Changed2 schema fields changedv0.38.0Nov 2, 2026

addedInput schema / properties / expense_account_dimension_id

Added value: +{
+  "description": "Dimension ID of the expense account; required when that account has dimensions",
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}

addedInput schema / properties / payable_account_dimension_id

Added value: +{
+  "description": "Dimension ID of the payable account (e.g. the owner's own dimension); required when that account has dimensions (e.g. a 2110 split by lender)",
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}

Changed1 schema field changedv0.29.2Oct 17, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
Addedv0.25.3Jul 27, 2026
Removedv0.25.2Jul 26, 2026
First observedv0.18.1Jul 9, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: it does not say whether the resulting journal is created unconfirmed, whether it can be duplicated on retry, or what the owner payable side effect is — relevant for a non-idempotent mutation with 14 parameters.

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?

A single well-formed sentence, front-loaded with the verb and resource, with no filler. It is efficient, though the brevity borders on under-specification for a 14-parameter mutation.

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 with 14 parameters, 6 of them required, complex VAT deduction modes and dimension resolution, and no output schema, one sentence is far from complete. Nothing about post-call state, journal confirmation status, or common failure conditions is disclosed.

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% and the schema itself carries substantial domain rules (VAT as fraction not percentage, vat_amount overriding vat_rate, default accounts 1510/2110, dimension requirements). The description adds no additional parameter meaning, so the baseline 3 applies.

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?

The description states a specific verb and resource: 'Create a journal for a business expense paid personally by the owner.' That tells an agent this is a specialised journal-creation for owner reimbursements, distinct from generic journal creation in intent, though it never names create_journal explicitly as the alternative.

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 when-to-use guidance, no prerequisite (e.g. owner client must exist, accounts must have dimensions resolved), and no routing against create_journal or create_transaction, which are the obvious generic siblings. The agent must infer everything from the title.

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

Deploy Server