ariregister-mcp

Call an XML service query

xml_service_request

Read-only

Execute any e-Business Register XML (SOAP) query that has no dedicated tool by sending operation and JSON body; credentials are added automatically.

Instructions

Call any e-Business Register XML (SOAP) query that has no dedicated tool, e.g. ettevotjaMuudatusedTasuline_v1 (companies changed on a date), kandedMaarused_v1 (entries and rulings for a day), aruandeMyygituluEMTAKjargi_v1 (revenue by activity), detailandmed_v2. Your contract username and password are added automatically. body holds the fields of keha as JSON: arrays repeat an element, objects nest. Field names and required fields are in the per-query docs at https://avaandmed.ariregister.rik.ee/en/open-data-api/introduction-api-services; send them in the order the docs list them. The service rejects a request that leaves out a field it requires, even one with a documented default. The response is the keha element as JSON with all values as text.

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": {
      "operation": "<operation>",
      "body": "<body>"
    },
    "name": "xml_service_request"
  }
}

Input Schema

Name	Required	Description	Default
`body`	Yes	Fields of the request `keha`, e.g. {"kuupaev": "2026-11-06", "tulemuste_lk": 1}.
`operation`	Yes	Query name, e.g. 'ettevotjaMuudatusedTasuline_v1'.

Output Schema

Name	Required	Description	Default
`response`	Yes
`operation`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 10, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and externality profile is supplied structurally; the description adds useful context on authentication being injected automatically and on the service rejecting requests that omit required fields even when a default is documented. That last point is genuinely non-obvious behavior the schema cannot convey. It stops short of disclosing failure modes, error shapes or rate limits for an open-world external call, so it is good but not exhaustive.

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?

Purpose and the 'no dedicated tool' routing come first, then credentials, then body semantics, then the pitfall, then the response shape — a logical front-loaded order. The example list is compact and earns its space by naming three distinct query families in a few words.

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

Completeness3/5

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

An output schema exists, so return-value documentation is not strictly required, though the description usefully notes the response is `keha` as JSON with all values as text. For a generic pass-through tool whose valid inputs depend on external per-query docs, the definition is about as complete as prose can be without duplicating that catalogue. The residual gap is that correctness depends on an out-of-band link, which is reasonable but leaves the definition partly self-insufficient.

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 100% and both parameters carry descriptions, so the baseline is 3. The description does add real semantics beyond the schema by explaining that `body` maps to the `keha` element, that arrays repeat an element and objects nest, and that field ordering matters — rules not expressible in JSON Schema. That pushes it above the baseline but the per-query field contracts are delegated to an external URL, so the description cannot fully define valid values.

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

Purpose5/5

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

States a specific verb and resource ('Call any e-Business Register XML (SOAP) query') and immediately scopes it with 'that has no dedicated tool', which is exactly the distinction an agent needs against the listed siblings like get_company or search_companies. Concrete query-name examples (ettevotjaMuudatusedTasuline_v1, kandedMaarused_v1) make the resource concrete rather than abstract.

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

Usage Guidelines5/5

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

Explicitly frames this as the fallback path: use it only for queries that lack a dedicated tool, which routes the agent toward the specialised siblings when they exist. It also gives the practical prerequisites (credentials auto-added) and the constraint that request fields must follow the documented order.

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

Deploy Server