Skip to main content
Glama
beel-es

BeeL MCP server

Official
by beel-es

beel_delete_customers_bulk

DestructiveIdempotent

Delete multiple customers by IDs in a single bulk request. Deletes eligible customers, returns per-row status for those that cannot be deleted (e.g., have invoices). Frees identifiers for reuse.

Instructions

Deletes the customers listed in ids from this company (NIF). The operation is partial: the customers that can be deleted are deleted, and the rest keep their place in customers_deletion with the status that explains why. That is why it answers 200 with a body instead of 204, and why it answers 200 even when no row could be deleted.

Each deletion has the same semantics as DELETE /v1/companies/{company_id}/customers/{customer_id}: the customer is retained internally for tax record-keeping purposes but is no longer exposed by the API, its identifier is released for reuse, and invoices already issued to it keep their own copy of the recipient's details. Deleting is not deactivating: deleting frees the identifier, so the same NIF can be registered again, while PATCH with active: false leaves the customer where it is with its NIF still taken. A customer that has invoices cannot be deleted and comes back with row status HAS_INVOICES.

Endpoint: DELETE /v1/companies/{company_id}/customers/bulk

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idsYesComma-separated customer IDs
company_idYesNIF (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.
Behavior5/5

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

Beyond the annotations (destructive, idempotent, open-world), the description discloses critical behaviors: partial deletion with 200 response even when nothing is deleted, internal retention for tax purposes, identifier release, and the contrast with deactivation. It also explains the response body structure via customers_deletion. No contradiction with annotations.

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 relatively long but every paragraph adds essential detail for a destructive bulk operation. It is logically structured: first the partial-deletion behavior and response, then the per-deletion semantics, then the delete-vs-deactivate distinction. It could be slightly tightened, but the density of information justifies the length.

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 the complexity (bulk partial operation, response semantics, comparison with deactivation), the description is remarkably complete. It covers operation behavior, response code rationale, per-deletion semantics, and the difference from deactivation. There is no output schema, but the description explains the response body sufficiently. No missing details that would prevent correct invocation.

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

Parameters5/5

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

The schema covers both parameters with descriptions, but the tool description adds substantial meaning: `company_id` is the only context source (ignoring the BeeL-Active-Company header), and it explains 403 behaviors for unreachable or non-existent NIFs. The `ids` parameter's semantics are enriched by the description of partial deletion. This goes well beyond the schema's simple descriptions.

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 clearly states the verb ('Deletes'), the resource ('customers listed in `ids`'), and the scope ('from this company (NIF)'). It also distinguishes the operation from its alternatives by explaining the partial nature and contrasting with single-delete and deactivate semantics. This makes the tool's purpose unmistakable even among many siblings.

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?

The description explicitly contrasts deleting with deactivating via PATCH active:false, explaining when each is appropriate and the consequences (identifier release vs. retention). It also states that customers with invoices cannot be deleted and will return HAS_INVOICES, giving clear conditions for use. This is more than enough guidance for an agent to decide when to invoke this tool.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/beel-es/beel-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server