BeeL MCP server

Official

Overview Schema Source Related Servers Discussions Admin

beel_delete_customer

DestructiveIdempotent

Deletes a customer of a company only when it has no invoices, freeing its NIF or alternative identifier for reuse; deactivate instead if invoices or recurring invoices exist.

Instructions

Deletes a customer of this company that has no invoices.

What deleting means: the customer is retained internally for tax record-keeping purposes, but is no longer exposed by the API: subsequent requests to it return 404, and it is never included in the customer list, under any value of the active filter.
Identifier released: its NIF or alternative identifier is freed, so a new customer may be created with the same identifier.
Customers with invoices: they cannot be deleted and the request answers 409 CLIENT_HAS_INVOICES. To stop using a customer, update it with active set to false instead of deleting it.
Customers used by a recurring invoice: while an active or paused recurring invoice has the customer as its recipient, the request answers 400 REFERENCED_BY_RECURRING_INVOICE.

BeeL API endpoint: DELETE /v1/companies/{company_id}/customers/{customer_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>",
      "customer_id": "<customer_id>"
    },
    "name": "beel_delete_customer"
  }
}

Input Schema

Name	Required	Description	Default
`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.
`customer_id`	Yes	Customer ID

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.10.0Nov 5, 2026
- addedInput schema / properties / customer_id / type
```
Added value: +"string"
```

Changed3 schema fields changedv0.5.0Aug 30, 2026

removedInput schema / $defs / UUID / example

Removed value: -"550e8400-e29b-41d4-a716-446655440000"

addedInput schema / additionalProperties
```
Added value: +false
```

changedInput schema / properties / company_id / description

Previous value: -"NIF (company) the operation acts on. 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 NIF you do not reach answers `403`, and so does a NIF that does not exist, so the existence of a NIF in another account is never disclosed."New value: +"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."

First observedv0.3.1Aug 25, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the supplied annotations by disclosing that deletion is a soft delete retained for tax records, that subsequent access returns 404, that the list filter never shows it, and that the NIF is released. It documents the 409 CLIENT_HAS_INVOICES and 400 REFERENCED_BY_RECURRING_INVOICE failure modes, which is exactly the behavioral context an agent needs for a destructive operation.

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?

Front-loads the core action, then uses labeled bullets for meaning, identifier release, blockers, and the recurring-invoice constraint. The length is justified for a destructive operation, and no sentence is wasted.

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?

For a destructive two-parameter tool with no output schema, the definition covers semantics, failure modes, alternatives, and side effects. Nothing an agent needs to invoke it safely is missing.

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 the company_id schema description already explains UUID, account context, and 403 behavior. The description adds little parameter-level meaning beyond restating the endpoint path, so the baseline of 3 is appropriate.

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: deletes a company customer that has no invoices. It distinguishes the operation from siblings such as beel_patch_customer and beel_delete_customers_bulk by scoping it to one customer and to the no-invoices condition.

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 names the alternative when deletion is blocked: set active to false via update instead. It also explains the recurring-invoice case with the exact 400 error, so the agent knows when not to call it and what to do instead.

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

Deploy Server