Global FinReg

Order LEI registration

create_registration_order

Orders the registration of a draft LEI application, paid like a renewal. This commits the user to paying, so only call it after showing the user the price from get_registration_quote and getting their explicit agreement. paymentMethod 'card' returns paymentUrl, Global FinReg's payment page for the application: give it to the user, who signs in to their Global FinReg account and pays by card there (never ask for card details); the application is processed once paid. paymentMethod 'invoice' confirms the order 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 application, from start_lei_registration or list_my_leis.
`years`	Yes	Registration 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_registration_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

A4.6/5.0

Behavior4/5

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

Annotations only declare the generic write/openWorld/non-idempotent profile; the description adds the real behavioral facts — irreversible financial commitment, that 'card' returns a paymentUrl for the user to sign in at Global FinReg (never collect card details), that 'invoice' confirms immediately and returns a PDF. Strong added value beyond annotations, though it doesn't mention failure/refusal handling beyond the price-change case.

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 commitment warning, then the payment branches; every sentence carries information. The single dense paragraph is slightly run-on, which costs a point versus a cleanly segmented version.

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?

No output schema exists, and the description covers the return values for both payment methods (paymentUrl, invoice PDF), the precondition, and the refusal condition on price change. Nothing an agent needs to call this risky write 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?

Schema coverage is 100% so the baseline is 3, but the description adds meaning the schema doesn't: it explains what paymentMethod 'card' versus 'invoice' actually does. It says less about years, vatNumber/vatCountry and expectedTotal, relying on the schema, which is acceptable at full coverage.

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 ('Orders the registration of a draft LEI application') and immediately distinguishes the pricing model from the sibling create_renewal_order ('paid like a renewal'). An agent can tell it apart from quote/status siblings without opening the schema.

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 an explicit precondition chain: only call after showing the price from get_registration_quote and getting explicit agreement, because it commits the user to paying. It also explains the two paymentMethod branches and what each produces, so the agent knows which variant to pick.

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?