Skip to main content
Glama
beel-es

BeeL MCP server

Official
by beel-es
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

beel_get_company

Read-onlyIdempotent

Retrieve a company's fiscal data, activation state in Test and Live, and VeriFactu registration status, including all editable fields to read back stored values.

Instructions

Returns the identity and activation state of a company: its fiscal data, whether it is switched on in Test and in Live, and its VeriFactu registration state.

It also returns every field PATCH /v1/companies/{company_id} accepts — contact details, legal representative, bank details, IAE, activity start date, payment term and the rendering block — so what was written can be read back without keeping a copy of it. A field never set comes back absent: that means "nothing stored", not "hidden".

Its invoice series are not part of this response: read them from GET /v1/companies/{company_id}/series.

Endpoint: GET /v1/companies/{company_id}

⚠️ Fiscal guardrails — read before calling:

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

For the exhaustive rules and worked examples, call beel_docs_search.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
company_idYesUnique 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.0

TDQS

A4.3/5.0
Behavior4/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description adds valuable behavioral detail: unset fields come back absent meaning 'nothing stored' rather than hidden, and the response includes all fields accepted by the PATCH endpoint. It also directs attention to fiscal guardrails. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well structured and front-loaded: main purpose first, then what is and is not included, then endpoint, then guardrail pointer. Every sentence adds necessary context, and the warning block is clearly separated. No filler.

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 read tool with no output schema, the description is remarkably complete: it covers the response scope, absence semantics, series exclusion, endpoint, and points to external docs for exhaustive rules. The input schema handles parameter context. Nothing critical is missing for correct invocation.

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 company_id parameter is already thoroughly documented in the input schema. The description does not add parameter-level detail, but it does not need to, since the schema carries the full burden. Baseline 3 applies.

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?

Description states exactly what the tool returns: company identity, activation state in Test/Live, and VeriFactu registration. It also specifies the scope of fields returned and explicitly distinguishes itself from the series endpoint. This clearly separates it from siblings like beel_list_companies and beel_patch_company.

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 description gives clear context: use this to read back what was written via PATCH, and it explicitly says series are not included and should be fetched from the dedicated endpoint. It does not enumerate every alternative, but the read-back and series-exclusion guidance is enough for an agent to choose it correctly.

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

Deploy Server

Other Tools