Skip to main content
Glama
jaakla

Merit MCP

by jaakla
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Merit Write Sales

merit_write_sales
Read-only

Preview an unsent sales invoice for Merit, returning operation details and a confirmation code; confirming writes a real accounting invoice.

Instructions

Preview-only write tool. Does not execute changes; returns intended operation details and a confirmation_code for merit_write_sales_confirm. Create unsent accounting invoices, not unposted drafts. Delivery (email/e-invoice), deletion, and credit invoices are handled manually in Merit and are not exposed by this server. Actions: sales_invoice_create: Create an unsent accounting invoice through Merit v1 /sendinvoice, NOT an unposted draft. Restricted schema: Customer={Id: customer GUID}; DocDate, TransactionDate, DueDate as YYYYMMDD; InvoiceNo (string), CurrencyCode='EUR', PriceInclVat=false, singular InvoiceRow list, TaxAmount, TotalAmount (VAT-exclusive). Optional FComment and HComment text. Each row requires Item={Code, Description, UOMName}, Quantity>0, Price>=0, TaxId GUID, Account. Read items_list first; Code must exactly match an existing non-stock item. The server verifies items again at confirmation and refuses missing, stock, or unrecognized items. Do not supply Item.Type. Use InvoiceRow (singular), not InvoiceRows; UOMName belongs inside Item, not on the row. Resolve company-specific TaxId GUIDs via taxes_list; never invent them. TaxAmount entries are {TaxId, Amount>=0} and must cover exactly the row TaxIds. TotalAmount must be positive and match the sum of row Quantity × Price, rounded per row to cents. Unknown fields are rejected at every level, including Payment, AccountingDoc, DelivNote, discounts, rounding adjustments, and item-creation fields. Negative quantities/prices are not supported. Choose InvoiceNo using the company's numbering convention; no automatic allocation is provided. Confirmation creates a real, unsent accounting invoice in Merit. It can affect the ledger and reports before delivery; this is NOT an unposted draft. Only the preview is non-writing. Review before confirming; send manually in Merit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNo
actionYes
bank_idNo
filtersNo
payloadNo
confirmedNo
delivnoteNo
add_attachmentNo
confirmation_codeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.5.0
    • changedInput schema / properties / filters / anyOf
      Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / payload / anyOf
      Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "items": {
-      "additionalProperties": true,
-      "type": "object"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "items": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "type": "array"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context: preview returns a confirmation_code, confirmation creates a real unsent accounting invoice affecting the ledger and reports, items are re-verified at confirmation, and unknown fields are rejected at every level. This goes well beyond the annotations and does not contradict them.

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?

The description is long but front-loads the most important distinction (preview vs. confirmation) and each sentence carries operational constraints. There is some repetition around 'not an unposted draft' and the density could be better structured, but for the complexity involved it is reasonably efficient.

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

Completeness5/5

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

Given a 9-parameter write-preview tool with no output schema, the description is exceptionally complete: it covers the preview/confirm lifecycle, ledger impact, manual boundaries, payload shape, validation behavior, and field-level restrictions. Nothing essential for correct invocation appears missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry parameter meaning, and it richly documents the payload structure, required field formats, singular InvoiceRow, TaxId resolution, and validation rules. However, several top-level parameters such as id, bank_id, filters, delivnote, and add_attachment are not explained, leaving gaps despite the strong payload coverage.

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?

The description states a specific action and scope ('Preview-only write tool... returns intended operation details and a confirmation_code') and distinguishes this preview tool from the confirmation sibling. It further specifies that it creates unsent accounting invoices, not unposted drafts, making the resource and state unambiguous.

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?

It explicitly says to use this tool for preview and then use merit_write_sales_confirm with the returned confirmation_code. It also names what is not exposed by this server (delivery, deletion, credit invoices) and clarifies that only the preview is non-writing, giving clear when-to-use and when-not-to-use guidance.

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

Deploy Server

Other Tools