Gleif

Get Lei

get_lei

Read-onlyIdempotent

Fetch the full Level 1 LEI record for a legal entity. Returns legal name, registered address, headquarters address, entity category, legal form, registration authority, LEI registration status (ISSUED / LAPSED / RETIRED / ...), jurisdiction, parent LEI (if any), and timestamps. Accepts a company NAME as well as a 20-character LEI — a name is resolved against the registry here and the match is echoed back as resolved_from_name. Answers "is this company's LEI still active or has it lapsed" and "where is this entity registered".

Input Schema

Name	Required	Description	Default
`lei`	Yes	20-character LEI code (e.g. "HWUPKR0MPOU8FGXBT394") OR the company NAME (e.g. "Wirecard AG") — a name is resolved here automatically and the match is echoed back as resolved_from_name. Pass the name whenever that is what you were given; do not construct an LEI. A guessed 20-character code that happens to exist belongs to SOME OTHER COMPANY, and the record comes back looking perfectly valid — asking about Wirecard AG with a made-up code returned Baader Bank's registration, with nothing in the response to show it was the wrong entity.

Output Schema

Name	Required	Description
`bic`	Yes	Bank Identifier Codes
`lei`	Yes	20-character LEI code
`isins`	Yes	ISIN codes
`category`	Yes	Entity category
`gleif_url`	Yes	Direct link to GLEIF record
`legal_form`	Yes	Legal form ID or description
`legal_name`	Yes	Official legal entity name
`last_update`	Yes	ISO date of last update
`other_names`	Yes	Alternative names for the entity
`jurisdiction`	Yes	ISO jurisdiction code
`managing_lou`	Yes	Managing Local Operating Unit
`next_renewal`	Yes	ISO date of next renewal
`entity_status`	Yes	Entity status (ACTIVE, LAPSED, etc.)
`legal_address`	Yes	Legal address of entity
`registered_as`	No	The company's own id in its national business register (e.g. Companies House number 00041424, Norwegian orgnr 923609016), whitespace stripped so it joins. Null when GLEIF publishes no id, and withheld for sole proprietors. Pair it with registration_authority: an id is only unique within its register.
`registration_status`	Yes	Registration status
`headquarters_address`	Yes	Headquarters address of entity
`initial_registration`	Yes	ISO date of initial registration
`registration_authority`	No	GLEIF Registration Authority code for the register that registered_as belongs to: RA000585 = UK Companies House, RA000189 = INSEE Sirene, RA000413 = Japan NTA, RA000472 = Brønnøysund. RA999999 is GLEIF's "other / not applicable" sentinel and comes with no registered_as.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedAug 23, 2026

changedInput schema / examples

Previous value: -[
-  {
-    "lei": "5493001KJTIIGC8Y1R12"
-  }
-]New value: +[
+  {
+    "lei": "Wirecard AG"
+  },
+  {
+    "lei": "5493001KJTIIGC8Y1R12"
+  }
+]

changedInput schema / properties / lei / description

Previous value: -"20-character LEI code"New value: +"20-character LEI code (e.g. \"HWUPKR0MPOU8FGXBT394\") OR the company NAME (e.g. \"Wirecard AG\") — a name is resolved here automatically and the match is echoed back as resolved_from_name. Pass the name whenever that is what you were given; do not construct an LEI. A guessed 20-character code that happens to exist belongs to SOME OTHER COMPANY, and the record comes back looking perfectly valid — asking about Wirecard AG with a made-up code returned Baader Bank's registration, with nothing in the response to show it was the wrong entity."

Changed2 schema fields changedMay 22, 2026

addedInput schema / examples

Added value: +[
+  {
+    "lei": "5493001KJTIIGC8Y1R12"
+  }
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "bic": {
+      "description": "Bank Identifier Codes",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "category": {
+      "description": "Entity category",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "entity_status": {
+      "description": "Entity status (ACTIVE, LAPSED, etc.)",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "gleif_url": {
+      "description": "Direct link to GLEIF record",
+      "type": "string"
+    },
+    "headquarters_address": {
+      "description": "Headquarters address of entity",
+      "properties": {
+        "city": {
+          "description": "City name",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "country": {
+          "description": "ISO country code",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "lines": {
+          "description": "Address lines",
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "postal_code": {
+          "description": "Postal code",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "region": {
+          "description": "Region or state",
+          "type": [
+            "string",
+            "null"
+          ]
+        }
+      },
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "initial_registration": {
+      "description": "ISO date of initial registration",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "isins": {
+      "description": "ISIN codes",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "jurisdiction": {
+      "description": "ISO jurisdiction code",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "last_update": {
+      "description": "ISO date of last update",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "legal_address": {
+      "description": "Legal address of entity",
+      "properties": {
+        "city": {
+          "description": "City name",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "country": {
+          "description": "ISO country code",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "lines": {
+          "description": "Address lines",
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "postal_code": {
+          "description": "Postal code",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "region": {
+          "description": "Region or state",
+          "type": [
+            "string",
+            "null"
+          ]
+        }
+      },
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "legal_form": {
+      "description": "Legal form ID or description",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "legal_name": {
+      "description": "Official legal entity name",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "lei": {
+      "description": "20-character LEI code",
+      "type": "string"
+    },
+    "managing_lou": {
+      "description": "Managing Local Operating Unit",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "next_renewal": {
+      "description": "ISO date of next renewal",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "other_names": {
+      "description": "Alternative names for the entity",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "registration_status": {
+      "description": "Registration status",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "lei",
+    "legal_name",
+    "other_names",
+    "jurisdiction",
+    "category",
+    "legal_form",
+    "entity_status",
+    "registration_status",
+    "initial_registration",
+    "last_update",
+    "next_renewal",
+    "managing_lou",
+    "legal_address",
+    "headquarters_address",
+    "bic",
+    "isins",
+    "gleif_url"
+  ],
+  "type": "object"
+}

First observedMay 11, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover read-only, idempotent, non-destructive, open-world, so the bar is lower, and the description still adds real behavioral context: name resolution happens server-side and is echoed as resolved_from_name, and a fabricated 20-character code will silently return a different company's valid-looking record. That last warning is exactly the kind of non-obvious failure mode an agent needs.

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 operation and return payload, then the usage question framing. The field enumeration is a long run-on list that partially duplicates the output schema, but every sentence still carries usable information.

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 a 1-parameter schema fully documented, an output schema present, and annotations covering the safety profile, the description fills the remaining gaps: input flexibility, silent-wrong-entity risk, and the practical questions it answers. Nothing an agent needs to invoke 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?

Schema coverage is 100% and the property description already carries the name-vs-code guidance, so baseline would be 3. The tool description reinforces the dual-input semantics and adds the concrete Wirecard/Baader Bank failure example, giving the parameter meaning beyond its type declaration, though it largely restates 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 and resource ('Fetch the full Level 1 LEI record for a legal entity') and enumerates the exact fields returned, so an agent can distinguish it from sibling lookups like search_lei, get_lei_relationships, or company_facts without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear triggering contexts — 'is this company's LEI still active or has it lapsed' and 'where is this entity registered' — and clarifies that a name may be passed instead of a code. It does not name a sibling alternative (e.g. search_lei) for partial/fuzzy lookups, so it stops short of full routing guidance.

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

All Gleif 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.