BeeL MCP server

Official

Overview Schema Source Related Servers Discussions Admin

beel_get_setup_status

Read-only

Check setup status for each company: see if live issuing is possible, what blockers or missing items exist (VeriFactu, payment, series), and the recommended next action.

Instructions

Read-only setup status across your account: for each company it reports whether it can issue Live, exactly what is missing (issuing-readiness blockers, default series, VeriFactu, payment connection) and the single recommended next action. Use this to drive onboarding instead of guessing. Aggregates several endpoints; a section that could not be read carries an error and never a default, so an unknown is never reported as ready.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`company_id`	No	Optional: restrict the report to a single company, by its company id (a UUID). This is not the NIF; the NIF is reported as a field of each company.

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No	Why the report is incomplete: the company listing failed, a filter matched nothing, or entries were unusable. Present only when something went wrong.
`account`	Yes	The authenticated account, or an error note if identity could not be read.
`companies`	Yes
`environment`	Yes	Which BeeL environment this session operates on. `live` means every invoice issued is a real fiscal document.
`next_action`	Yes	Single recommended next action across the whole account.

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv0.5.0Aug 30, 2026

changedInput schema / properties / company_id / description

Previous value: -"Optional: restrict the report to a single company (NIF) id."New value: +"Optional: restrict the report to a single company, by its company id (a UUID). This is not the NIF; the NIF is reported as a field of each company."

addedOutput schema / properties / account / properties / error / description

Added value: +"Why this section could not be read. Present only on failure."

addedOutput schema / properties / companies / items / properties / company_id / description
```
Added value: +"The company id (a UUID), not the NIF."
```

addedOutput schema / properties / companies / items / properties / default_series / properties / error

Added value: +{
+  "description": "Why this section could not be read. Present only on failure.",
+  "type": "string"
+}

addedOutput schema / properties / companies / items / properties / error

Added value: +{
+  "description": "Why this section could not be read. Present only on failure.",
+  "type": "string"
+}

addedOutput schema / properties / companies / items / properties / payment_connection / properties / error

Added value: +{
+  "description": "Why this section could not be read. Present only on failure.",
+  "type": "string"
+}

changedOutput schema / properties / companies / items / properties / ready / description

Previous value: -"Can issue Live (no blockers)."New value: +"Can issue Live (no blockers). `null` means readiness could not be read — see `error`; it does not mean not ready, and it does not mean ready."

changedOutput schema / properties / companies / items / properties / ready / type
```
Previous value: -"boolean"New value: +[
+  "boolean",
+  "null"
+]
```

addedOutput schema / properties / companies / items / properties / verifactu / properties / error

Added value: +{
+  "description": "Why this section could not be read. Present only on failure.",
+  "type": "string"
+}

addedOutput schema / properties / error

Added value: +{
+  "description": "Why the report is incomplete: the company listing failed, a filter matched nothing, or entries were unusable. Present only when something went wrong.",
+  "type": "string"
+}

First observedv0.3.1Aug 25, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Beyond readOnlyHint/openWorldHint, it adds meaningful behavior: aggregation of endpoints, error sections with no default, and the guarantee that unknown status is never reported as ready. It does not cover auth or rate-limit behavior, but those are less material for a read-only status tool.

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?

Two sentences with front-loaded purpose, a specific content list, a concrete use case, and a precise error-handling guarantee. No filler or repetition of schema details.

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?

With an output schema present and one self-documented optional parameter, the description covers what the tool does, when to use it, and how it behaves under partial failures. An agent has enough information to invoke it correctly.

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 already documents company_id fully (optional, UUID, not NIF) at 100% coverage. The description itself adds no new parameter detail, so baseline 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 it is a read-only aggregated setup status report and specifies the exact contents (Live capability, missing blockers, default series, VeriFactu, payment connection, recommended next action). This clearly differentiates it from the many individual get_* siblings.

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?

'Use this to drive onboarding instead of guessing' gives a clear trigger, and 'Aggregates several endpoints' tells the agent this replaces multiple getter calls. It does not explicitly enumerate alternatives like beel_get_issuing_readiness for a single-readiness detail view, so not a 5.

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

Deploy Server