Global FinReg

Order LEI renewal

create_renewal_order

Orders the renewal of one of the user's LEIs. This commits the user to paying, so only call it after showing the user the price from get_renewal_quote and getting their explicit agreement. paymentMethod 'card' returns paymentUrl, Global FinReg's renewal page for the LEI: give it to the user, who signs in to their Global FinReg account and pays by card there (never ask for card details); the renewal is processed once paid. paymentMethod 'invoice' confirms the renewal straight away and returns the invoice PDF for the user to pay by bank transfer.

Input Schema

Name	Required	Description
`leiId`	Yes	The id (GUID) of the LEI, from list_my_leis or list_leis_due_for_renewal.
`years`	Yes	Renewal period in years: 1, 3 or 5, as quoted.
`vatNumber`	No	Optional: the entity's EU VAT number, e.g. BE0123456789. It is checked with the EU's VIES service, and only a valid number is used. Pass the same vatCountry and vatNumber to the order tool as to the quote.
`vatCountry`	No	Optional: the 2-letter code of the EU country that issued the entity's VAT number, e.g. BE. Give it with vatNumber when the quote adds VAT and the entity has an EU VAT number; leave both out to use the VAT number already stored for this LEI.
`expectedTotal`	Yes	The total from get_renewal_quote that the user agreed to. The order is refused if the price has changed.
`paymentMethod`	Yes	'card' (pay online by card) or 'invoice' (pay by bank transfer).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 28, 2026

addedInput schema / properties / vatCountry

Added value: +{
+  "default": null,
+  "description": "Optional: the 2-letter code of the EU country that issued the entity's VAT number, e.g. BE. Give it with vatNumber when the quote adds VAT and the entity has an EU VAT number; leave both out to use the VAT number already stored for this LEI.",
+  "type": "string"
+}

addedInput schema / properties / vatNumber

Added value: +{
+  "default": null,
+  "description": "Optional: the entity's EU VAT number, e.g. BE0123456789. It is checked with the EU's VIES service, and only a valid number is used. Pass the same vatCountry and vatNumber to the order tool as to the quote.",
+  "type": "string"
+}

AddedOct 21, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations flag a non-read-only, non-idempotent, open-world mutation, and the description adds the crucial commitments an agent must know: this commits the user to paying, card payment is completed on Global FinReg's page (never collect card details), and invoice confirms the renewal immediately. These are consequential side effects not visible in 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?

Front-loaded with the committing nature of the call and the prerequisite check, then the two payment paths. Three dense sentences, each carrying distinct operational information; nothing redundant.

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 no output schema, the description supplies the return values that matter (paymentUrl, invoice PDF), the confirmation semantics, and the safety rule about card details. Nothing an agent needs to call this mutation correctly is missing.

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

Parameters5/5

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

Beyond the 100%-covered schema, the description explains the behavioral consequence of each paymentMethod: 'card' returns a paymentUrl the user signs into and pays at (never ask for card details), while 'invoice' confirms immediately and returns a PDF. That is meaning the schema's terse enum values do not convey.

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+resource ('Orders the renewal of one of the user's LEIs') and immediately distinguishes itself from the quote step and from sibling order tools like create_registration_order by naming get_renewal_quote as the required predecessor.

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?

Explicit when-to-use: only after showing the user the price from get_renewal_quote and obtaining explicit agreement. It also branches the two paymentMethod paths with what each does, leaving no ambiguity about invocation conditions.

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

All Global FinReg tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?