Skip to main content
Glama
Sign In
BeeL MCP server

BeeL MCP server

Official
by beel-es
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

beel_restore_payment_event

Idempotent

Restores a discarded payment event and all events discarded with it in the same operation, returning them to the default list. Idempotent, so restoring an already active event does nothing.

Instructions

Reverses a previous discard, bringing a payment event back into the default list.

The operation reverses the whole discard operation: the event named in the request and every event with the same payment identity (see the discard operation) that was discarded together with it, that is, with exactly the same deleted_at timestamp. Events discarded in an earlier or later operation are not affected. Idempotent — restoring an event that is not discarded is a no-op.

BeeL API endpoint: POST /v1/companies/{company_id}/payment-connections/{connection_id}/events/{event_id}/restore (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>",
      "connection_id": "<connection_id>",
      "event_id": "<event_id>"
    },
    "name": "beel_restore_payment_event"
  }
}

Input Schema

NameRequiredDescriptionDefault
event_idYesIdentifier of the payment event, as returned by the list operation.
company_idYesUnique identifier (UUID) of the company the events belong to — 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.
connection_idYesUnique identifier (UUID) of the payment connection the operation acts on, as returned by `GET /v1/companies/{company_id}/payment-connections`. A NIF can hold several connections of the same provider, so the provider slug alone does not name one. A connection of another NIF answers `404`, exactly like one that does not exist.
idempotency_keyNoOptional idempotency key for this operation. Omit it and one is derived from the request itself, which makes a blind retry safe but also collapses a SECOND, deliberately identical operation into the first for 24 hours. Set it — to an order id, or anything unique per intended operation — whenever you mean to create something that may look identical to what you just created.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.9.0

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true) by disclosing the cascade rule: every event sharing the same payment identity and identical deleted_at is restored, while other discards are untouched. It also explicitly states the idempotent no-op behavior on a non-discarded event and gives the underlying endpoint, which no structured field provides.

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?

Front-loaded with the verb and effect, followed by scope, then idempotency, then the endpoint reference. Three short paragraphs, no filler; the API path and docs URL are mild overhead but useful for debugging.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers effect, blast radius, idempotency and endpoint for a 4-parameter mutation with no output schema. A brief note on what the caller gets back (the restored event object or which events were restored) would close the remaining gap.

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 parameter docs are already extensive (company scoping, 403/404 disclosure rules, idempotency-key semantics). The description adds only the grouping meaning of event_id via the shared-deleted_at rule, so the baseline of 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?

States a specific verb and resource ('Reverses a previous discard, bringing a payment event back into the default list') and ties it to the counterpart discard operation, so an agent can tell it apart from beel_discard_payment_event, beel_resolve_payment_event and the list 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?

Makes clear this is the undo of a discard and scopes the effect to events discarded in the same operation; the exclusion of earlier/later discards is a useful boundary. It stops short of naming the sibling tools (beel_discard_payment_event, beel_list_payment_events) as alternatives or stating prerequisites such as the event having to currently be discarded.

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