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

TableJSON 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

TableJSON 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
`registration_status`	Yes	Registration status
`headquarters_address`	Yes	Headquarters address of entity
`initial_registration`	Yes	ISO date of initial registration

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

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/5.0

Behavior4/5

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

The annotations already communicate read-only, idempotent, and non-destructive behavior. The description goes beyond that by exposing a non-obvious failure mode: a fabricated LEI can resolve to a different, valid-looking record and be echoed back as resolved_from_name. This is genuinely valuable behavioral context and does not contradict the annotations.

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?

The description is front-loaded with the action and resource, followed by the most important behavioral caveat and then the user-facing questions it answers. It is a little dense due to the long list of return fields, but no sentence is wasted.

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?

The one required parameter is fully documented, the riskier edge cases around entity-name resolution are explicitly described, and the annotations plus the stated output fields give an agent the full context needed to invoke the tool correctly. An output schema is present, so describing the return value structure is not necessary.

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

Parameters3/5

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

The only parameter has a rich schema description that already explains the LEI-or-name behavior, the resolved_from_name echo, and the warning about constructing LEIs. The tool description adds little over the schema for parameter semantics, so the baseline score for high schema coverage is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Fetch the full Level 1 LEI record') and the resource (a legal entity), then lists the returned fields. It implicitly distinguishes itself from relationship-oriented siblings like get_lei_relationships, but it does not explicitly name alternatives.

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?

The description provides a strong, concrete usage rule: pass a company name when given a name, do not construct an LEI, and note that bad guesses return real-looking records for the wrong company. It frames the target questions but does not explicitly describe when to prefer this tool over search_lei, resolve_entity, or get_lei_relationships, so exclusions are absent.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.