Skip to main content
Glama
Sign In

Global FinReg

by com.globalfinreg
OverviewDiscussionsAdmin

Get LEI registration price

get_registration_quote
Idempotent

Returns the price of registering a draft LEI application for 1, 3 or 5 years: net amount, VAT, total and currency, the payment methods (card, invoice) and any unpaid order the user already started. The limited POA must be signed first, or (download, email) on its way. The price is in the account's currency: if the user hasn't said which currency they want to pay in, ask them first and change it with set_currency. If vatNote says VAT could be taken off, ask the user for the entity's EU VAT number and pass vatCountry and vatNumber. Always show the user this price and get their agreement before calling create_registration_order.

Input Schema

NameRequiredDescriptionDefault
leiIdYesThe id (GUID) of the LEI application, from start_lei_registration or list_my_leis.
yearsNoRegistration period in years: 1, 3 or 5. Longer periods have a lower price per year.
vatNumberNoOptional: 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.
vatCountryNoOptional: 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • 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"
+}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say readOnlyHint=false, idempotentHint=true, openWorldHint=true. The description adds real behavioral context beyond them: the quote depends on POA signing state, reflects the account's currency setting, may return an already-started unpaid order, and surfaces a vatNote conditional that drives a follow-up VAT lookup.

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 return content and dense with decision-relevant instructions, with no filler. The sentence 'The limited POA must be signed first, or (download, email) on its way' is garbled and costs some clarity.

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, yet the description enumerates the returned fields and even an edge-case field (vatNote) and side data (existing unpaid order). Combined with schema documentation of all four parameters, an agent has everything needed to call and interpret it.

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; the description adds value by explaining the conditional trigger for vatCountry/vatNumber ('if vatNote says VAT could be taken off') and the requirement to reuse the same VAT pair on the order tool. It does not add much about the leiId or years semantics beyond the schema.

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 ('Returns the price of registering a draft LEI application') and enumerates the returned breakdown (net, VAT, total, currency, payment methods, existing unpaid order). It is clearly distinguishable from siblings like get_renewal_quote and get_prices by scoping to LEI registration.

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 sequencing and alternatives: POA must be signed first, ask the user for currency and use set_currency if unstated, request vatCountry/vatNumber when vatNote indicates VAT removal, and confirm the price with the user before calling create_registration_order. Both when-to-use and when-not-to-proceed are covered.

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

All Global FinReg toolsInspect
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