Skip to main content
Glama
revclamp

RevClamp MCP Server

Official
by revclamp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

revclamp_reconcile_b2b_net_terms

Reconcile Shopify Plus B2B Net-15/30/60 invoices, upfront deposits, credit notes, and rounding tolerances using integer EUR-cent double-entry accounting to resolve wholesale payment mismatches.

Instructions

Reconciles Shopify Plus B2B Net-15/30/60 wholesale invoices, upfront deposits, credit notes, and rounding tolerances using integer EUR-cent double-entry accounting.

Input Schema

NameRequiredDescriptionDefault
toleranceCentsNo
orderTotalCentsYes
paidAmountCentsYes
creditNotesCentsNo
paymentTermsDaysYes
requiredDepositPercentYes
daysElapsedSinceInvoiceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed18 schema fields changedv1.20.1
    • removedInput schema / properties / creditNoteCents
      Removed value: -{
-  "description": "Optional post-invoice credit notes or return adjustments in integer cents (valid range: 0 to totalOrderCents, default: 0; singular alias for creditNotesCents).",
-  "type": "integer"
-}
    • addedInput schema / properties / creditNotesCents / default
      Added value: +0
    • removedInput schema / properties / creditNotesCents / description
      Removed value: -"Optional post-invoice credit notes or return adjustments in integer cents (valid range: 0 to totalOrderCents, default: 0; plural alias for creditNoteCents)."
    • addedInput schema / properties / creditNotesCents / minimum
      Added value: +0
    • addedInput schema / properties / daysElapsedSinceInvoice
      Added value: +{
+  "default": 0,
+  "minimum": 0,
+  "type": "integer"
+}
    • removedInput schema / properties / orderId
      Removed value: -{
-  "description": "Required B2B wholesale order or invoice identifier (e.g. 'gid://shopify/Order/908812' or 'ORD-2026-9088', max 64 chars).",
-  "type": "string"
-}
    • addedInput schema / properties / orderTotalCents
      Added value: +{
+  "minimum": 0,
+  "type": "integer"
+}
    • removedInput schema / properties / paidAmountCents / description
      Removed value: -"Required cumulative amount collected from the buyer in non-negative integer cents (e.g. 75000 for 750.00 EUR; must be >= 0)."
    • addedInput schema / properties / paidAmountCents / minimum
      Added value: +0
    • removedInput schema / properties / paymentTermsDays / description
      Removed value: -"Optional B2B net payment terms maturity window in integer days (allowed values: 15, 30, or 60 for Net-15, Net-30, or Net-60; default: 30)."
    • addedInput schema / properties / paymentTermsDays / enum
      Added value: +[
+  15,
+  30,
+  60
+]
    • removedInput schema / properties / requiredDepositCents
      Removed value: -{
-  "description": "Optional explicit upfront deposit threshold in integer cents (valid range: 0 to totalOrderCents). Overrides requiredDepositPercent when provided.",
-  "type": "integer"
-}
    • removedInput schema / properties / requiredDepositPercent / description
      Removed value: -"Optional upfront deposit percentage required before releasing warehouse fulfillment hold (valid range: 0 to 100, default: 30 i.e. 30% upfront deposit)."
    • addedInput schema / properties / requiredDepositPercent / maximum
      Added value: +100
    • addedInput schema / properties / requiredDepositPercent / minimum
      Added value: +0
    • addedInput schema / properties / toleranceCents
      Added value: +{
+  "default": 0,
+  "maximum": 500,
+  "minimum": 0,
+  "type": "integer"
+}
    • removedInput schema / properties / totalOrderCents
      Removed value: -{
-  "description": "Required gross invoice total in positive integer minor currency units / cents (e.g. 250000 for 2,500.00 EUR; must be > 0).",
-  "type": "integer"
-}
    • changedInput schema / required
      Previous value: -[
-  "orderId",
-  "totalOrderCents",
-  "paidAmountCents"
-]New value: +[
+  "orderTotalCents",
+  "paidAmountCents",
+  "requiredDepositPercent",
+  "paymentTermsDays"
+]
  2. First observedv1.20.0

TDQS

B3.1/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It does disclose meaningful behavioral context — integer EUR-cent arithmetic and double-entry accounting, implying exact, float-free, deterministic computation in a single currency — but it never states whether the tool is side-effect-free, whether it persists anything, or what the reconciliation result looks like.

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 that packs the domain, terms, and accounting model with no filler. It is dense but every clause carries information; only a slight readability cost from cramming many qualifiers into one sentence.

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 7-parameter tool with no annotations and no output schema, the description is under-specified: the agent cannot tell what is returned (a status, a delta, a journal entry?), how overdue terms interact with daysElapsedSinceInvoice, or what the reconciliation outcome means. The return-side burden falls entirely on nothing since no output schema exists.

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 0%, so the description must compensate and it partially does: credit notes, upfront deposits, payment terms (Net-15/30/60), order totals, and rounding tolerances all map to named parameters. However, daysElapsedSinceInvoice is never mentioned, and semantics such as what happens when the deposit is short or how toleranceCents changes the outcome are left unexplained.

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 names a specific verb ("Reconciles") and a precise resource domain (Shopify Plus B2B Net-15/30/60 wholesale invoices, deposits, credit notes, rounding tolerances). This is clearly distinct from the sibling tools (VAT validation, webhook signature, dispute linting, revenue-leakage audit), though it does not explicitly name or exclude those alternatives.

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 guidance on when to call this versus alternatives, no prerequisites (e.g., that Shopify Plus B2B orders are required), and no conditions under which it is inappropriate. The scope is implied by the description's subject matter alone.

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