e-arveldaja MCP Server

Confirm Purchase Invoice

confirm_purchase_invoice

Destructive

Confirm and lock a purchase invoice to finalize it without changing approved totals; use a fresh approved preview if totals need correction.

Instructions

Confirm and lock a purchase invoice without changing approved totals. Totals correction requires a fresh approved preview.

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": {
      "id": "<id>"
    },
    "name": "confirm_purchase_invoice"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Object ID
`plan_handle`	No
`recalculate_totals`	No
`approved_correction`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.32.1Oct 19, 2026
- addedInput schema / properties / plan_handle
```
Added value: +{
+  "pattern": "^[A-Za-z0-9_-]{43}$",
+  "type": "string"
+}
```
Changed1 schema field changedv0.29.2Oct 17, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
Changed4 schema fields changedv0.25.7Sep 19, 2026
- removedInput schema / properties / approved_correction / properties / current_gross_price / anyOf
```
Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / approved_correction / properties / current_gross_price / type
```
Added value: +[
+  "number",
+  "null"
+]
```
- removedInput schema / properties / approved_correction / properties / current_vat_price / anyOf
```
Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / approved_correction / properties / current_vat_price / type
```
Added value: +[
+  "number",
+  "null"
+]
```

Changed2 schema fields changedv0.25.2Jul 26, 2026

addedInput schema / properties / approved_correction

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "approval_digest": {
+      "pattern": "^[0-9a-f]{64}$",
+      "type": "string"
+    },
+    "correction_required": {
+      "type": "boolean"
+    },
+    "current_gross_price": {
+      "anyOf": [
+        {
+          "type": "number"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "current_vat_price": {
+      "anyOf": [
+        {
+          "type": "number"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "invoice_id": {
+      "exclusiveMinimum": 0,
+      "maximum": 9007199254740991,
+      "type": "integer"
+    },
+    "is_vat_registered": {
+      "type": "boolean"
+    },
+    "proposed_gross_price": {
+      "type": "number"
+    },
+    "proposed_vat_price": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "invoice_id",
+    "is_vat_registered",
+    "current_vat_price",
+    "current_gross_price",
+    "proposed_vat_price",
+    "proposed_gross_price",
+    "correction_required",
+    "approval_digest"
+  ],
+  "type": "object"
+}

addedInput schema / properties / recalculate_totals
```
Added value: +{
+  "type": "boolean"
+}
```

First observedv0.18.1Jul 9, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds real value beyond that: it specifies the invoice is 'locked' (irreversible finalization) and that totals will not be altered, plus the freshness requirement for correction approvals. It still omits what happens on failure or whether a plan_handle must be pre-approved.

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?

Two sentences, front-loaded with the action and its key constraint, then the correction prerequisite. Zero filler, though it is arguably terse enough that no signal about the plan_handle/recalculate_totals interaction survives.

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?

For a destructive, non-idempotent finalization tool with a complex nested payload and no output schema, the description covers the locking semantics and correction gate but leaves the preview-digest lifecycle, plan_handle role, and recalculate_totals behavior unaddressed. Adequate but with clear gaps.

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 only 25% (just 'Object ID' on id), and the nested approved_correction object has eight required fields documented nowhere. The description partially compensates by tying an 'approved preview' to the approved_correction workflow, but plan_handle and recalculate_totals remain unexplained by either schema or description.

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 gives a specific verb and resource ('Confirm and lock a purchase invoice') and adds a distinguishing constraint ('without changing approved totals') that separates it from update_purchase_invoice. It does not explicitly name sibling tools, but an agent can tell this is the finalization step rather than an edit.

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 second sentence, 'Totals correction requires a fresh approved preview,' implies the prerequisite of running preview_purchase_invoice_totals_correction before confirming a correction, which is genuine routing guidance. However, it never names the preview tool, states when NOT to use this tool (e.g. use update_purchase_invoice for changes), or describes what happens if the digest is stale.

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

Deploy Server