Skip to main content
Glama
Sign In

Global FinReg

by com.globalfinreg
OverviewDiscussionsAdmin

Apply for a new LEI

start_lei_registration
Idempotent

Starts an application for a new LEI in the user's account, saved as a draft. First check with search_lei_by_company_name that the entity has no LEI yet (if it has one with another issuer, use start_lei_transfer). application is the LEI application as JSON in the request body format of POST /api/Lei, documented at /agentapi: the legal entity (legal name, business registry number, legal form, legal and headquarters addresses), its parents and the contact. Global FinReg needs a limited power of attorney (limited POA) signed for the entity to register it; ask the user how they want to deal with it (poaMethod) before calling, with the same options as a transfer POA: 'sign' - the user signs it online themselves, if they are a director or board member (returns signingUrl); 'email' - GFR emails a signing link to the signer, by default the user; 'download' - returns the POA PDF to print, sign and upload with upload_signed_limited_poa. The answer says whether supporting documents are needed (documentsNeeded) and what to do next. Calling again for the same entity returns the application already started.

Input Schema

NameRequiredDescriptionDefault
poaMethodYes'sign', 'email' or 'download', as the user chose.
signerRoleNoFor 'sign': the user's role in the entity, 'director' or 'board_member'.
applicationYesThe LEI application as a JSON object, in the request body format of POST /api/Lei (see /agentapi). Contact.SigningAuthority is set from poaMethod. DirectParentEntity and UltimateParentEntity are required: ask the user whether the entity has a parent company; for none, send both as {"Disclosure": false, "NonDisclosureReason": "2"} (owned by individuals) or "1" (no known owner).
signerEmailNoFor 'email': the signer's email address. Default: the user's own.
signerPhoneNoFor 'email': the signer's phone number.
signerLastNameNoFor 'email': the signer's last name (default the user's, when the user signs).
signerPositionNoFor 'email': the signer's position in the entity, e.g. CEO.
signerFirstNameNoFor 'email': the signer's first name (default the user's, when the user signs).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true, openWorldHint=true), it states that the application is saved as a draft, that the poaMethod='sign' path returns a signingUrl, that 'download' needs a later upload_signed_limited_poa, and that calling again returns the existing application. This is behavioral context annotations cannot express.

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?

It front-loads the core action and the POA prerequisite early, and every sentence carries information. It is a long, run-on block though, so the POA option list could be easier to scan if separated.

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 an 8-parameter mutation with no output schema, the description covers the return signals ('documentsNeeded', what to do next, signingUrl) and the multi-step POA flow, leaving no obvious gap in what an agent needs to call it correctly.

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 base is 3, but the description adds real meaning: it ties the poaMethod choices ('sign', 'email', 'download') to their consequences and names the required parent-entity branches for 'application'. Minor gap: it doesn't re-note the signer* fields, but those are already well documented in 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?

A specific verb and resource ('Starts an application for a new LEI in the user's account, saved as a draft') plus an explicit boundary against start_lei_transfer when the entity already has an LEI with another issuer. An agent can separate this tool from its siblings from the first sentence alone.

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?

It gives an explicit pre-check (search_lei_by_company_name), a rule for the alternative (if it has one with another issuer, use start_lei_transfer), and an explicit instruction to ask the user about poaMethod before calling. When-to-use and when-to-use-something-else are both stated.

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