BeeL MCP server

Official

Overview Schema Source Related Servers Discussions Admin

beel_update_payment_connection

Destructive

Update auto-invoicing settings for a company payment connection, including invoice series, charge filters, tax config, and email delivery, with partial-field updates.

Instructions

Updates the auto-invoicing settings of the payment connection named by {connection_id} of a company your account owns or manages.

Partial by field: a field you omit keeps its current value. The series fields also accept an explicit null, which clears the series and falls back to the company default for that document type. filter_config is the exception: when sent, it replaces the whole object, not just the sub-fields you included — a partial filter_config clears every filter axis you left out.
Read-only fields: id, provider, status, environment, external_account_id, connected_at, last_event_at and active_filters are not part of this request and are ignored if sent. status moves through the disconnect operation, never here.
Series: each one must exist, be active, belong to this NIF and carry a compatible document type, or the request answers 422.

BeeL API endpoint: PATCH /v1/companies/{company_id}/payment-connections/{connection_id} (reference: https://docs.beel.es)

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": {
      "company_id": "<company_id>",
      "connection_id": "<connection_id>",
      "body": "<body>"
    },
    "name": "beel_update_payment_connection"
  }
}

Input Schema

Name	Required	Description
`body`	Yes
`company_id`	Yes	Unique identifier (UUID) of the company the operation acts on — its identifier, not its NIF. It is the only source of context: the account that owns it is derived from it, and the `BeeL-Active-Company` header plays no part. A company you do not reach answers `403`, and so does a company that does not exist, so the existence of a company in another account is never disclosed.
`connection_id`	Yes	Unique identifier (UUID) of the payment connection the operation acts on, as returned by `GET /v1/companies/{company_id}/payment-connections`. A NIF can hold several connections of the same provider, so the provider slug alone does not name one. A connection of another NIF answers `404`, exactly like one that does not exist.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.10.0Nov 5, 2026

changedInput schema / $defs / UpdateCompanyPaymentConnectionRequest / description

Previous value: -"The settings to change. A field you omit keeps its current value; the series fields also\naccept an explicit `null`, which clears the series.\n"New value: +"The settings to change. A field you omit keeps its current value; the series fields and\n`tax_inclusive_tax` also accept an explicit `null`, which clears them.\n"

removedInput schema / $defs / UpdateCompanyPaymentConnectionRequest / properties / prices_include_tax

Removed value: -{
-  "description": "Whether provider amounts are read as tax-inclusive. Turning it on requires\n`tax_inclusive_tax` in the same request, or the request answers `422`\n`TAX_INCLUSIVE_RATE_REQUIRED`: without the tax there is nothing to reverse.\n",
-  "type": "boolean"
-}

changedInput schema / $defs / UpdateCompanyPaymentConnectionRequest / properties / simplificada_threshold / description

Previous value: -"Amount in EUR at or above which auto-invoicing must issue an ordinary invoice instead\nof a simplified one. Between 0.01 and 3000.00.\n"New value: +"Deprecated. No longer affects auto-invoicing: a buyer with a tax ID and full address\nalways gets an ordinary invoice; without them, a simplified one up to 3,000 EUR.\nStill accepted; between 0.01 and 3000.00.\n"

changedInput schema / $defs / UpdateCompanyPaymentConnectionRequest / properties / tax_inclusive_tax / anyOf

Previous value: -[
-  {
-    "allOf": [
-      {
-        "$ref": "#/$defs/TaxInfo"
-      }
-    ],
-    "description": "The tax to reverse out of the gross amount. Send it together with\n`prices_include_tax: true`; `null` clears it.\n"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "allOf": [
+      {
+        "$ref": "#/$defs/TaxInfo"
+      }
+    ],
+    "description": "Optional. The tax applied to a charge for which the provider sends no tax breakdown;\nwhen set, it takes precedence over the company's tax configuration for those charges.\nOmit it to keep the current value; send `null` to clear it, so the company's tax\nconfiguration applies again.\n"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / body / type
```
Added value: +"object"
```

Addedv0.9.0Oct 1, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=false, but the description adds materially more: omitted fields keep their value, series and `tax_inclusive_tax` accept explicit null to clear, and `filter_config` replaces the entire object rather than merging — a genuinely dangerous surprise that the schema only hints at. It also enumerates fields silently ignored and the 422 failure mode when a series does not exist, is inactive, or carries an incompatible document type.

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?

Front-loaded with the core action, then organized into labeled bullets that each carry distinct operational content. Slight redundancy with the schema's series and filter descriptions, but the 422 failure detail and the read-only field list earn their space.

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

Completeness4/5

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

For a nested, non-idempotent PATCH with no output schema, the definition covers permissions scope, merge semantics, error behavior and the endpoint. It does not say what the call returns (presumably the updated connection), which is the one thing an agent must infer.

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 67% and the description compensates well, explaining body-level merge semantics, null-clearing behavior, and the whole-object replacement rule for `filter_config`. It does not elaborate on `auto_create_customer`, `send_invoice_by_email` or `event_source` beyond what the schema already says, which is acceptable but leaves a small gap.

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 opening sentence names a specific verb (updates), a specific resource (the auto-invoicing settings of a payment connection) and the scoping condition (a company your account owns or manages). It also disambiguates from the sibling disconnect operation by stating that `status` moves through disconnect and never here.

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

Usage Guidelines4/5

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

Usage context is clear: this is the settings-mutation path for an existing connection, and status transitions are explicitly excluded and routed elsewhere. It stops short of naming read tooling explicitly for the settings (only the schema's `connection_id` points at the list endpoint), so the 'inspect first, then patch' workflow is implied rather than stated.

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

Deploy Server