BeeL MCP server

Official

Overview Schema Source Related Servers Discussions Admin

beel_create_claim_token

DestructiveIdempotent

Issues a single-use claim token and claim URL so an account holder can set a password and take ownership; reissuing invalidates the previous link.

Instructions

Issues a single-use claim_token, and the claim_url built from it, so the account's holder can set a password and take ownership.

email: send it when the account has no holder yet — the person is created by this call. Omit the body to re-issue the token for the holder the account already has. An email that differs from the existing holder's is rejected rather than replacing them.
Lifetime: tokens last 30 days, and only the last one issued is live. Issuing again invalidates the previous token, so the old link stops working the moment you ask for a new one.
Not an invitation: this hands the account itself over to its holder. To add a further person to an account that already has one, invite them with POST /v1/accounts/{account_id}/invitations.
Entitlement: requires manage_accounts.

BeeL API endpoint: POST /v1/accounts/{account_id}/claim-tokens (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": {
      "account_id": "<account_id>"
    },
    "name": "beel_create_claim_token"
  }
}

Input Schema

Name	Required	Description
`body`	No
`account_id`	Yes	Identifier (UUID) of an account you provisioned. An account you did not provision answers exactly like one that does not exist, so its existence is never disclosed.
`idempotency_key`	No	Optional 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.

Changed1 schema field changedv0.10.0Nov 5, 2026
- addedInput schema / properties / body / type
```
Added value: +"object"
```

Changed2 schema fields changedv0.9.0Oct 1, 2026

changedInput schema / $defs / Language / description

Previous value: -"Supported languages"New value: +"Supported languages: `es` Spanish, `en` English, `ca` Catalan.\n"

addedInput schema / properties / account_id / description

Added value: +"Identifier (UUID) of an account you provisioned. An account you did not provision answers exactly like one that does not exist, so its existence is never disclosed."

Changed3 schema fields changedv0.5.0Aug 30, 2026
- addedInput schema / $defs / CreateClaimTokenRequest / additionalProperties
```
Added value: +false
```
- removedInput schema / $defs / Language / example
```
Removed value: -"es"
```
- addedInput schema / additionalProperties
```
Added value: +false
```
First observedv0.3.1Aug 25, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well past the annotations: 30-day token lifetime, single-live-token semantics, the fact that re-issuing silently kills the previous link, and the required `manage_accounts` entitlement. It also discloses the destructive consequence that the annotations only flag abstractly (destructiveHint=true), and the mismatch rejection behaviour rather than implying silent replacement.

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?

Front-loads the one-line purpose, then three labelled bullets that each carry a distinct decision-relevant fact (body semantics, lifetime/invalidation, alternative endpoint, entitlement). No filler, and the endpoint line is a compact pointer rather than prose.

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 mutating, non-idempotent-looking operation with no output schema, the description still tells the agent what it produces (`claim_token` and `claim_url`), how long it lives, what it invalidates, what permissions it needs, and which sibling to use instead. Nothing needed to call it correctly is missing.

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

Parameters4/5

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

Adds real meaning for `body.email` (create-vs-reissue branching, mismatch rejection) and for retry semantics, on top of a schema that is already 67% documented. It never mentions the `language` parameter, which the schema covers but the top-level description leaves entirely to the nested definition.

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 (issues a single-use `claim_token` plus the derived `claim_url`) and immediately names the outcome it enables: the holder sets a password and takes ownership. It also distinguishes itself from the nearest sibling in the same sentence family by explicitly ruling out the invitation flow.

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?

Gives explicit branching conditions: send `email` when the account has no holder, omit the body to re-issue for an existing holder, and use `POST /v1/accounts/{account_id}/invitations` instead when a holder already exists. It also states the rejection condition (an email differing from the current holder's), so the agent knows what not to attempt.

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

Deploy Server