BeeL MCP server

Official

Overview Schema Source Related Servers Discussions Admin

beel_get_issuing_readiness

Read-onlyIdempotent

Check whether a company can issue a STANDARD invoice right now and get the blockers preventing it, evaluated independently per company NIF.

Instructions

Returns whether a company can issue its STANDARD invoice right now in the environment of the request, and the blockers that stop it otherwise. Readiness is a per-NIF property, evaluated independently for each company of the account.

ready: true only when blockers is empty.
Activation: issuing any fiscal document requires the company to be activated in the environment of that document, whether or not it goes to VeriFactu.
VeriFactu chain: the AEAT census and signed representation are additionally demanded only when the company is under the VeriFactu regime in this environment — the same fact that decides, at issue time, whether its invoices are registered. A company with VeriFactu off is ready with a NIF, a default series and an activation, and the separate verifactu block reports the compliance chain independently.
Not evaluated: the account's quota or subscription, and the payload of any particular invoice.

BeeL API endpoint: GET /v1/companies/{company_id}/issuing-readiness (reference: https://docs.beel.es)

⚠️ Read before calling:

Which company an operation acts on, and how that is selected. (resource: beel://guardrails/multi-nif)

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>"
    },
    "name": "beel_get_issuing_readiness"
  }
}

Input Schema

Name	Required	Description	Default
`company_id`	Yes	Unique identifier (UUID) of the company whose issuing readiness is evaluated — 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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.5.0Aug 30, 2026

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

changedInput schema / properties / company_id / description

Previous value: -"NIF (company) whose issuing readiness is evaluated. 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."New value: +"Unique identifier (UUID) of the company whose issuing readiness is evaluated — 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."

First observedv0.3.1Aug 25, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds substantial semantics beyond that: readiness is per-NIF and evaluated independently per company, `ready` is true only when `blockers` is empty, activation is required regardless of VeriFactu, and the AEAT census plus signed representation are demanded only under the VeriFactu regime. It does not describe response shape in detail or latency/rate behavior, keeping it just below top marks.

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 core answer is front-loaded in the first sentence, and the bullets are labeled and scannable rather than prose-heavy. The 'Read before calling' warning pointing to a resource URI is slightly out of place in a tool description and adds length without adding callable detail, but overall the text is economical for the amount of domain nuance conveyed.

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?

There is no output schema, and the description compensates by explaining the two response keys (`ready` and `blockers`) and their relationship, plus the independently reported `verifactu` block. Combined with the explicit non-evaluated scope and the company_id error semantics in the schema, an agent has everything needed to call this correctly and interpret the result.

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 100% and the schema already explains that company_id is a UUID (not the NIF) and that a 403 covers both unauthorized and nonexistent companies. The description's contribution is limited to reinforcing that readiness is a per-company/per-NIF property, which adds modest scope meaning but no new syntax or selection detail beyond the schema.

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 first sentence names a specific verb (returns whether), a specific resource (company issuing readiness for its STANDARD invoice), and the scope (in the environment of the request), plus the failure payload (`blockers`). It also carves out the boundary against related concepts by stating the separate `verifactu` block reports the compliance chain independently, so an agent can tell it apart from verifactu-configuration and setup-status tools.

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?

The 'Not evaluated' bullet effectively gives exclusions (quota, subscription, invoice payload), which steers the agent away from using it for those questions, and the guardrails pointer addresses company selection. It stops short of explicitly naming a sibling (e.g. beel_get_setup_status or beel_validate_nif) or stating a when-to-call trigger such as 'call before issuing an invoice', so it is clear context without full alternative routing.

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

Deploy Server