e-arveldaja MCP Server

Create Client

create_client

Register a new buyer, supplier, or both in e-arveldaja by providing name and entity type. Use it to add clients, suppliers, and contact or VAT details.

Instructions

Create a new client (buyer/supplier)

Input Schema

TableJSON Schema

Name	Required	Description
`code`	No	Business registry code or personal ID
`name`	Yes	Client name
`email`	No	Contact email
`notes`	No	Notes
`is_client`	Yes	Is a buyer
`telephone`	No	Phone
`is_supplier`	Yes	Is a supplier
`address_text`	No	Address
`invoice_vat_no`	No	VAT number
`allow_duplicate`	No	Create even when a live client with the same registry code exists, or the code/VAT is the company's own (default false: refused with the existing client id(s)).
`bank_account_no`	No	Bank account (IBAN)
`cl_code_country`	No	Country code (default EST)
`is_physical_entity`	Yes	REQUIRED: true = natural person, false = legal entity/company (a checksum-valid Estonian registry `code` is then also required, or a foreign registration with foreign_identity_attested). The API rejects creation without this.
`foreign_identity_attested`	No	Operator accountant-attestation that a FOREIGN (cl_code_country != EST) legal entity's identity has been verified. Required to create a foreign legal entity. Must be an explicit operator input — never set it from extracted/OCR document fields.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.29.2Oct 17, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```

Changed1 schema field changedv0.27.0Sep 26, 2026

addedInput schema / properties / allow_duplicate

Added value: +{
+  "description": "Create even when a live client with the same registry code exists, or the code/VAT is the company's own (default false: refused with the existing client id(s)).",
+  "type": "boolean"
+}

Changed2 schema fields changedv0.25.2Jul 26, 2026

addedInput schema / properties / foreign_identity_attested

Added value: +{
+  "description": "Operator accountant-attestation that a FOREIGN (cl_code_country != EST) legal entity's identity has been verified. Required to create a foreign legal entity. Must be an explicit operator input — never set it from extracted/OCR document fields.",
+  "type": "boolean"
+}

changedInput schema / properties / is_physical_entity / description

Previous value: -"REQUIRED: true = natural person, false = legal entity/company (registry `code` then also required). The API rejects creation without this."New value: +"REQUIRED: true = natural person, false = legal entity/company (a checksum-valid Estonian registry `code` is then also required, or a foreign registration with foreign_identity_attested). The API rejects creation without this."

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 this is a non-read-only, non-destructive, non-idempotent mutation, so the safety profile is covered. The description adds no behavioral context of its own — no mention of duplicate-refusal semantics, the attestation requirement, or how creation differs from the update path — even though the schema does carry some of this.

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 front-loaded sentence with zero filler. It is efficient, though its brevity borders on under-specification for a 14-parameter mutation tool.

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 14-parameter create tool with non-trivial constraints (duplicate refusal, foreign-entity attestation, required physical-entity flag) and no output schema, a one-line description is thin. The schema compensates for parameter detail, but the description itself supplies no context an agent would want before invoking a write operation.

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 14 parameters (including allow_duplicate, is_physical_entity, foreign_identity_attested) are fully documented in the schema itself. The description contributes nothing beyond it, 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 new client') and clarifies the entity covers both buyer and supplier roles, which helps distinguish it from read/update siblings like get_client or update_client. However, it does not name an alternative sibling or explicitly contrast with them.

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: nothing about using update_client for existing records, nothing about duplicate handling, and nothing about prerequisites such as the required is_physical_entity flag. The agent gets no routing information beyond the verb.

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

Deploy Server

Create Client

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools