This server provides comprehensive tools to look up, validate, search, and analyze Legal Entity Identifiers (LEIs) using the official GLEIF database (2.8M+ entities across 200+ jurisdictions), supporting KYC, compliance, due diligence, and financial analysis.
Core LEI Lookup & Validation
Look up a specific LEI: Retrieve full entity details (legal name, address, jurisdiction, status, managing LOU, renewal dates)
Validate an LEI: Check format, ISO 17442 check digits, and registration status
Batch LEI lookup: Query up to 100 LEIs in a single request
Search
Search by name: Find companies using fuzzy matching and pagination
Autocomplete: Get name suggestions from a prefix (min 2 characters)
Search by BIC/SWIFT: Find a bank's LEI from its BIC/SWIFT code
Search by ISIN: Find a security issuer's LEI from an ISIN code
Search by country: List entities registered in a specific country using ISO 2-letter codes
Corporate Ownership & Relationships
Get relationships: Explore direct parent, ultimate parent, subsidiaries, fund manager, umbrella fund, and sub-fund structures
Get reporting exceptions: Understand why parent/ownership data may be missing (e.g., NON_CONSOLIDATING, NATURAL_PERSONS)
LEI Issuers (LOUs)
List all LEI issuers: Directory of all Local Operating Units worldwide
Get LEI issuer details: Retrieve detailed info about a specific LOU
The server also includes local caching, graceful error handling with retries, and built-in rate limiting to stay within GLEIF API quotas.
Verify any company's legal identity in one question. Look up LEI codes, validate counterparties, and trace corporate ownership structures using the official GLEIF database. Covers 2.8M+ entities across 200+ jurisdictions.
12 tools for LEI lookup, entity search, BIC/SWIFT cross-referencing, corporate ownership, and batch validation. Works with Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, and other MCP-compatible tools.
KYC & Onboarding: Verify counterparty identities before signing contracts
Compliance Checks: Validate LEIs for MiFID II, EMIR, or DORA reporting
Due Diligence: Research corporate ownership chains and ultimate parents
Financial Analysis: Cross-reference securities (ISIN) and banks (BIC/SWIFT) with their legal entities
Data Enrichment: Batch-process company lists to add LEI data
Related MCP server: npi-verify
The Legal Entity Identifier (LEI) is a 20-character alphanumeric code that uniquely identifies legal entities participating in financial transactions worldwide. It's mandated by 200+ regulations including MiFID II, EMIR, Dodd-Frank, and DORA.
LEI Format (ISO 17442):
Characters 1-4: LOU (Local Operating Unit) prefix
Characters 5-18: Entity-specific identifier
Characters 19-20: Check digits (mod 97 validation)
Example: HWUPKR0MPOU8FGXBT394 (Apple Inc.)
LEI Lookup: Get full entity details by LEI code
Batch Lookup: Look up multiple LEIs in a single request (up to 100)
Entity Search: Find companies by name with fuzzy matching and pagination
LEI Validation: Verify format, check digits (ISO 17442), and registration status
BIC/SWIFT Lookup: Find bank LEIs from BIC codes
ISIN Lookup: Find security issuer LEIs from ISIN codes
Country Browse: List entities by jurisdiction
Corporate Ownership: Parent companies, subsidiaries, ultimate parents
Fund Relationships: Fund managers, umbrella funds, sub-funds
Reporting Exceptions: Level 2 data exceptions with reasons
LEI Issuers: List and details of all Local Operating Units (LOUs)
Fast Responses: Results are cached locally, so repeat queries return instantly
No API Key Needed: Works out of the box with GLEIF's public API
Handles Errors Gracefully: Automatic retries on timeouts or temporary failures
Stays Within Limits: Built-in rate limiting prevents hitting GLEIF's quotas
Pre-built binaries for all platforms on the releases page:
Platform | Binary |
macOS (Apple Silicon) |
|
macOS (Intel) |
|
Linux (x64) |
|
Linux (ARM64) |
|
Windows (x64) |
|
# macOS/Linux - download and make executable
chmod +x gleif-mcp-server-darwin-arm64Requires Go 1.25+:
git clone https://github.com/olgasafonova/gleif-mcp-server.git
cd gleif-mcp-server
go build -o gleif-mcp-server .go install github.com/olgasafonova/gleif-mcp-server@latestQuickest start: Using Claude Desktop? Just add the config below and restart. Using an IDE like Cursor? Same idea, different config file. Pick your tool below.
Go to the releases page and download the binary for your system:
Mac (Apple Silicon M1/M2/M3/M4): gleif-mcp-server-darwin-arm64
Mac (Intel): gleif-mcp-server-darwin-amd64
Windows: gleif-mcp-server-windows-amd64.exe
macOS blocks downloaded files. Open Terminal and run:
chmod +x ~/Downloads/gleif-mcp-server-darwin-arm64
xattr -d com.apple.quarantine ~/Downloads/gleif-mcp-server-darwin-arm64Mac: Open Finder, press Cmd + Shift + G, paste this path:
~/Library/Application Support/Claude/Windows: Press Win + R, paste this path:
%APPDATA%\ClaudeOpen claude_desktop_config.json. If it doesn't exist, create it.
Mac (replace YOUR_USERNAME with your actual username):
{
"mcpServers": {
"gleif": {
"command": "/Users/YOUR_USERNAME/Downloads/gleif-mcp-server-darwin-arm64"
}
}
}Windows (replace YOUR_USERNAME - note the double backslashes):
{
"mcpServers": {
"gleif": {
"command": "C:\\Users\\YOUR_USERNAME\\Downloads\\gleif-mcp-server-windows-amd64.exe"
}
}
}To find your username: Mac - open Terminal and type whoami. Windows - look at C:\Users\.
Quit completely (Cmd + Q on Mac) and reopen.
Type in Claude Desktop:
Look up Apple's LEI using GLEIFYou should see Claude call the GLEIF tool and return company data.
# Add the server
claude mcp add gleif /path/to/gleif-mcp-server
# Or with scope for all projects
claude mcp add --scope user gleif /path/to/gleif-mcp-serverAdd to .cursor/mcp.json in your project or ~/.cursor/mcp.json for global config:
{
"mcpServers": {
"gleif": {
"command": "/path/to/gleif-mcp-server"
}
}
}Add to .continue/config.json:
{
"experimental": {
"modelContextProtocolServers": [
{
"name": "gleif",
"transport": {
"type": "stdio",
"command": "/path/to/gleif-mcp-server"
}
}
]
}
}Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"gleif": {
"command": "/path/to/gleif-mcp-server"
}
}
}Add via Cline's MCP settings or in .vscode/cline_mcp_settings.json:
{
"mcpServers": {
"gleif": {
"command": "/path/to/gleif-mcp-server",
"args": []
}
}
}Add to ~/.antigravity/mcp.json:
{
"mcpServers": {
"gleif": {
"command": "/path/to/gleif-mcp-server"
}
}
}Not working? Tell us what made it hard — even one sentence helps.
Tool | Description | Parameters |
| Get full details for a specific LEI |
|
| Check format, check digits, and status |
|
| Look up multiple LEIs at once |
|
Tool | Description | Parameters |
| Search by company name |
|
| Find LEI from BIC/SWIFT |
|
| Find issuer LEI from ISIN |
|
| List entities by country |
|
| Entity name suggestions |
|
Tool | Description | Parameters |
| Get corporate/fund relationships |
|
Tool | Description | Parameters |
| Get details about an LOU |
|
| List all LOUs worldwide | None |
Tool | Description | Parameters |
| Get Level 2 reporting exceptions |
|
Prompt: "Look up LEI HWUPKR0MPOU8FGXBT394"
Returns: Full entity details for Apple Inc. including legal name, headquarters address, jurisdiction (US-CA), entity status, registration status, managing LOU, and next renewal date.
Prompt: "Search for Deutsche Bank, show page 2"
Tool call:
{
"name": "search_entity",
"arguments": {
"query": "Deutsche Bank",
"limit": 20,
"page": 2,
"fuzzy": true
}
}Returns: List of matching entities with pagination info (total results, current page, has more).
Prompt: "Look up these LEIs: HWUPKR0MPOU8FGXBT394, 5493006MHB84DD0ZWV18, 549300GKFG0RYRRQ1414"
Returns: Summary of all three entities with LEI, legal name, country, city, and status.
Prompt: "Find the LEI for BIC DEUTDEFF"
Returns: Deutsche Bank AG's LEI record with full details.
Prompt: "Who issued ISIN US0378331005?"
Returns: Apple Inc. (the issuer of AAPL stock).
Prompt: "Who is the ultimate parent of this subsidiary?"
Tool call:
{
"name": "get_relationships",
"arguments": {
"lei": "549300GKFG0RYRRQ1414",
"type": "ultimate-parent"
}
}Prompt: "Is LEI HWUPKR0MPOU8FGXBT394 valid?"
Returns:
{
"lei": "HWUPKR0MPOU8FGXBT394",
"valid": true,
"status": "ISSUED",
"entityStatus": "ACTIVE",
"nextRenewal": "2025-08-15"
}Prompt: "Why is parent info missing for this company?"
Tool call:
{
"name": "get_reporting_exceptions",
"arguments": {
"lei": "5493006MHB84DD0ZWV18"
}
}Returns: Exception categories and reasons (e.g., NON_CONSOLIDATING, NATURAL_PERSONS).
Prompt: "Show me all LEI issuers"
Returns: Complete list of LOUs (Local Operating Units) with name, country, status, and number of sponsored LEIs.
All tools return JSON with relevant fields. Example entity record:
{
"lei": "HWUPKR0MPOU8FGXBT394",
"legalName": "Apple Inc.",
"country": "US",
"city": "Cupertino",
"status": "ACTIVE",
"regStatus": "ISSUED"
}Search results include pagination:
{
"count": 20,
"results": [...],
"pagination": {
"currentPage": 1,
"perPage": 20,
"total": 156,
"lastPage": 8
},
"hasMore": true
}The server returns structured errors:
Error Code | Description | Retryable |
| LEI/entity not in GLEIF database | No |
| Invalid LEI/BIC/ISIN format | No |
| GLEIF API rate limit exceeded | Yes |
| Request timed out | Yes |
| GLEIF API error | Depends on status |
| Connection failed | Yes |
Example error response:
{
"code": "not_found",
"message": "LEI not found in GLEIF database",
"statusCode": 404,
"retryable": false
}gleif-mcp-server/
├── main.go # Entry point, MCP server setup
├── internal/gleif/
│ ├── client.go # GLEIF API client with caching & rate limiting
│ ├── client_test.go # Client and validation tests
│ ├── cache.go # LRU cache with TTL
│ ├── types.go # Data structures for API responses
│ └── errors.go # Structured error types
└── tools/
├── definitions.go # Tool metadata and parameter specs
├── handlers.go # MCP tool implementations
└── handlers_test.go # Handler tests with mock serverFor developers who want the specifics:
Setting | Value |
Cache duration | 15 minutes |
Cache capacity | 1000 entities, 500 searches |
Rate limit | 50 req/min (GLEIF allows 60) |
Retry strategy | 3 attempts with exponential backoff |
Connection pool | 100 max idle, 10 per host |
This server wraps the public GLEIF API:
Base URL: https://api.gleif.org/api/v1
Authentication: None required
Rate Limit: 60 requests/minute
Documentation: https://www.gleif.org/en/lei-data/gleif-api
Check the binary has execute permissions: chmod +x gleif-mcp-server
Verify the path in your MCP config is absolute, not relative
The server automatically handles rate limiting with retries
If persistent, reduce concurrent requests or wait a few minutes
The GLEIF database updates daily; recently issued LEIs may not appear immediately
Verify the LEI format (exactly 20 alphanumeric characters)
First requests may be slower (cache warming)
GLEIF API occasionally has latency spikes; retries handle this automatically
Restart Claude Desktop after editing config
Check JSON syntax in config file
Verify the binary path exists and is executable
# Run tests
go test ./...
# Run tests with coverage
go test -coverprofile=coverage.out ./...
go tool cover -html=coverage.out
# Run tests with race detector
go test -race ./...
# Build
go build -o gleif-mcp-server .Contributions welcome. Please open an issue first to discuss proposed changes.
MIT License - see LICENSE for details.
Check out my other MCP servers:
Server | Description | Stars |
Connect AI to any MediaWiki wiki. Search, read, edit wiki content. | ||
Control Miro whiteboards with AI. Boards, diagrams, mindmaps, and more. | ||
Access Nordic business registries. Look up companies across Norway, Denmark, Finland, Sweden. | ||
Talk to your ProductPlan roadmaps. Query OKRs, ideas, launches. | ||
Nordic grocery deal hunting. Find offers, plan meals, track spending. |
GLEIF for the public LEI API
Model Context Protocol for the MCP specification
Get entity name suggestions from a prefix (min 2 characters). USE WHEN: "suggest companies starting with X", "autocomplete company name", user is typing a name and needs quick suggestions. For full search results with pagination, use search_entity instead. Returns name suggestions with LEI and legal name for each match. FAILS WHEN: prefix is shorter than 2 characters. Falls back to fuzzy search automatically if the autocomplete endpoint is unavailable.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max suggestions (default 10) | |
| prefix | Yes | Name prefix to complete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. Description adds that it returns name suggestions with LEI and legal name, and mentions automatic fallback to fuzzy search if autocomplete endpoint is unavailable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, then usage guidelines, then fallback behavior. No redundancy, every sentence adds unique information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description covers purpose, usage, failure conditions, fallback, and return content (name suggestions with LEI and legal name). Complete for a read-only autocomplete tool with 2 params.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds minimal extra meaning beyond the schema's parameter descriptions. It reaffirms the minLength=2 constraint for prefix but does not introduce new semantic details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool's purpose: get entity name suggestions from a prefix (min 2 characters). Distinguishes from sibling search_entity by emphasizing quick suggestions vs full search with pagination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides USE WHEN examples (e.g., 'suggest companies starting with X') and when to use search_entity instead. Also states failure condition (prefix < 2 chars).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up multiple LEI records in one request (max 100). USE WHEN: "look up these LEIs", "batch lookup", user provides 2+ LEI codes. Faster than calling lei_lookup repeatedly. FAILS WHEN: list is empty (provide at least one LEI), more than 100 LEIs (split into multiple calls), any individual LEI has invalid format (fix that specific LEI; the error message includes its position).
| Name | Required | Description | Default |
|---|---|---|---|
| leis | Yes | Comma-separated LEI codes (max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds constraints (max 100) and failure behaviors, including that error messages include position of invalid LEI. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two clear sentences plus structured USE WHEN/FAILS WHEN sections. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter tool without output schema, the description covers purpose, usage guidance, and failure conditions. Minor gap: does not describe response format, but annotations and context signals compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes 'leis' as comma-separated LEI codes with max 100. Description adds context that error includes position, and reinforces the batch nature. Since schema coverage is 100%, baseline is 3, but extra context justifies 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool looks up multiple LEI records in one request, with a max of 100. It distinguishes from sibling lei_lookup by specifying batch operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'USE WHEN' conditions with example user requests, and 'FAILS WHEN' conditions for empty list, over 100 LEIs, and invalid format. Also notes performance benefit over repeated calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details about a specific LEI issuer (Local Operating Unit / LOU) by ID. USE WHEN: "details on this LOU", "issuer info". Returns issuer name, country, status, website, and count of sponsored LEIs. For all issuers worldwide, use list_lei_issuers. FAILS WHEN: issuer ID not found (use list_lei_issuers to get valid IDs).
| Name | Required | Description | Default |
|---|---|---|---|
| issuer_id | Yes | LEI issuer ID (4-32 alphanumeric characters) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. Description adds useful behavioral context: lists return fields (name, country, status, website, count of sponsored LEIs) and failure behavior with a recovery suggestion. Adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a distinct purpose: function, usage cues, failure handling. Front-loaded and no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description lists key return fields. Provides failure handling advice. For a simple read tool with one parameter, this is mostly complete, though exact output structure is not detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed constraints and description. The description only says 'by ID' which adds no new meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get details about a specific LEI issuer (Local Operating Unit / LOU) by ID', using a specific verb and resource. It distinguishes from sibling tool list_lei_issuers by directly contrasting use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'USE WHEN' examples and warns about failure when ID is not found, offering the alternative to use list_lei_issuers. This gives clear when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get corporate ownership and fund relationships for an entity.
USE WHEN: "who owns X?", "parent company", "subsidiaries", "fund manager"
Types: direct-parent, ultimate-parent, children, fund-manager, umbrella-fund, sub-funds. Returns relationship records with related entity LEI, legal name, relationship type, and status.
FAILS WHEN: LEI format invalid (must be 20 alphanumeric chars), no relationships of requested type exist (entity may have no parent; check get_reporting_exceptions for why ownership data is missing).
| Name | Required | Description | Default |
|---|---|---|---|
| lei | Yes | LEI code | |
| type | No | Relationship type | direct-parent |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent. The description adds value by detailing the LEI format requirement, failure scenarios, and output fields, going beyond the safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, USE WHEN, type list, output, FAILS WHEN). It is concise with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Though no output schema exists, the description fully explains the return format and failure conditions. For a read-only tool, this provides sufficient context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the description adds context about the output (entity LEI, legal name, relationship type, status) and a summary of relationship types, helping agents use parameters effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves corporate ownership and fund relationships, lists specific relationship types, and describes the output format. This differentiates it from sibling tools like get_reporting_exceptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit USE WHEN examples ('who owns X?', 'parent company') and FAILS WHEN conditions (invalid LEI, no relationships). It also references an alternative sibling (get_reporting_exceptions) for missing ownership data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explains why parent/ownership data may be missing for an entity. USE WHEN: "why no parent info?", "reporting exceptions", "missing ownership data". Returns list of Level 2 exceptions, each with type (NON_CONSOLIDATING, NO_KNOWN_PERSON, NATURAL_PERSONS, NON_PUBLIC), category, and reference entity. Empty list when entity has no exceptions (parent data is complete). FAILS WHEN: LEI format invalid (must be 20 alphanumeric chars).
| Name | Required | Description | Default |
|---|---|---|---|
| lei | Yes | LEI code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds value by detailing return structure (list of exceptions with type, category, reference entity), empty list behavior, and failure condition. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, use cases, return info, failure condition. No redundancy, front-loaded key info. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description fully explains return format and behavior. Covers both success and failure cases, making it complete for a read-only, single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with comprehensive regex pattern for LEI. Description does not add new parameter details beyond what schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool 'explains why parent/ownership data may be missing for an entity', specifying verb and resource. It distinguishes from sibling tools like get_relationships or lei_lookup by focusing on exceptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'USE WHEN' phrases with example queries like 'why no parent info?', giving clear context. Does not explicitly list alternatives but implies usage. Also notes failure condition for invalid LEI format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details for a specific LEI code (legal name, address, jurisdiction, status, managing LOU, renewal dates). USE WHEN: "look up LEI", "LEI details", "who is HWUPKR0MPOU8FGXBT394?" For validating format and status only, use validate_lei. For multiple LEIs at once, use batch_lei_lookup. FAILS WHEN: LEI is not exactly 20 alphanumeric characters (fix format and retry), LEI not found in GLEIF database (entity may not have an LEI; try search_entity by name instead).
| Name | Required | Description | Default |
|---|---|---|---|
| lei | Yes | 20-character LEI code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly and idempotent. Description adds failure conditions (invalid format, LEI not found) and suggests retry strategies, providing behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: 4 sentences that front-load purpose, then provide usage instructions and failure modes. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with one parameter and clear annotations, the description covers purpose, usage alternatives, and failure recovery comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the sole parameter entirely (100% coverage) with pattern, examples, and length constraints. Description adds no additional semantic value for the parameter, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get full details for a specific LEI code' and lists specific data fields (legal name, address, jurisdiction, status, etc.). It distinguishes from siblings like validate_lei and batch_lei_lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides 'USE WHEN' examples and 'FAILS WHEN' conditions, including format validation and database lookup failure. Alternatives like validate_lei, batch_lei_lookup, and search_entity are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all LEI issuers (Local Operating Units / LOUs) worldwide. USE WHEN: "show all LOUs", "which organizations issue LEIs?", "LEI issuer directory". Returns all issuers with name, country, status, and sponsored LEI count. For one specific issuer, use get_lei_issuer.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is clear. The description adds value by specifying the return fields (name, country, status, sponsored LEI count), which is useful without an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a distinct purpose: purpose, usage cues, and sibling differentiation. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description explains purpose, usage, and return structure. Combined with annotations, it provides complete guidance for a simple list-all tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema coverage is 100% trivially. The description does not need to elaborate on parameters, but it could mention that no inputs are required. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all LEI issuers (LOUs) worldwide, with a specific verb ('list') and resource ('LEI issuers'). It distinguishes from the sibling 'get_lei_issuer' by noting the scope difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage triggers are provided ('USE WHEN' examples), and it directly instructs when to use the sibling tool for one specific issuer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a bank's LEI from its BIC/SWIFT code (8 or 11 characters). USE WHEN: "find LEI from BIC", "BIC to LEI", "SWIFT code lookup", user provides a BIC code. Returns matching entity with LEI, legal name, country, and registration status. FAILS WHEN: BIC is not 8 or 11 characters (fix input), no entity mapped to this BIC (not all banks have LEIs; try search_entity with the bank name instead).
| Name | Required | Description | Default |
|---|---|---|---|
| bic | Yes | BIC/SWIFT code (8 or 11 chars) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. Description adds that it returns specific fields (LEI, legal name, country, registration status) and details failure conditions, providing additional behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with purpose, then usage, then failure conditions. Every sentence adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema) and rich annotations, the description covers purpose, parameter, failure modes, usage context, and alternatives, making it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with pattern and examples. Description adds practical context about required length (8 or 11 characters) and reinforces the parameter constraint, increasing understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find' and the resource 'bank's LEI from its BIC/SWIFT code', specifies the input length (8 or 11 characters), and distinguishes from siblings by mentioning failure conditions and alternative 'search_entity'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use examples ('find LEI from BIC', 'BIC to LEI', etc.), when not to use (BIC length incorrect, no entity mapped), and suggests an alternative tool (search_entity).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List entities registered in a specific country. USE WHEN: "companies in Germany", "LEIs from US", "entities in country X". Pass ISO 2-letter code (US, GB, DE). Returns entity list with LEI, legal name, and status for each. Paginated. FAILS WHEN: country code is not a 2-letter ISO 3166-1 alpha-2 code (use "US" not "USA", "GB" not "UK").
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 20) | |
| country | Yes | 2-letter ISO country code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds value by stating 'Paginated' and specifying the return format ('entity list with LEI, legal name, and status for each'). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (5 sentences) with a front-loaded purpose, clear USE WHEN and FAILS WHEN sections, and no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes the return format (entity list with LEI, legal name, status) and mentions pagination. It covers failure conditions and usage patterns, making it complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description reinforces the country parameter with examples ('US, GB, DE') and a failure condition, and mentions pagination (implicitly covering limit). Adds nuance beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('entities registered in a specific country'), immediately clarifying the tool's function. It distinguishes from siblings like 'search_by_bic' and 'search_by_isin' by focusing on country-based filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit example queries ('companies in Germany', 'LEIs from US', 'entities in country X') and a clear failure condition ('FAILS WHEN: country code is not a 2-letter ISO 3166-1 alpha-2 code'), guiding the agent on correct use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the issuer's LEI from a securities ISIN code (12 characters). USE WHEN: "who issued ISIN US0378331005?", "ISIN to LEI", user provides an ISIN. Returns issuer entity with LEI, legal name, country, and registration status. FAILS WHEN: ISIN is not 12 characters (fix input), no issuer found for this ISIN (some securities lack LEI mapping).
| Name | Required | Description | Default |
|---|---|---|---|
| isin | Yes | 12-character ISIN code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations: it details the return content (LEI, legal name, country, registration status) and failure modes, while annotations already confirm read-only and idempotent behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loading the main purpose, then usage guidance, return info, and failure conditions. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool, the description is complete: it explains the action, when to use, what is returned, and common failures. No output schema exists, but return details are given.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the 'isin' parameter (pattern, length, example). The description reinforces the 12-character requirement and adds failure context, providing marginal additional semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find', the resource 'issuer's LEI', and the specific input 'securities ISIN code (12 characters)'. It provides concrete usage examples and implicitly differentiates from sibling tools like 'search_by_bic' or 'lei_lookup'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage scenarios ('USE WHEN') and failure conditions ('FAILS WHEN'), guiding the agent on when to invoke this tool and what to expect in case of issues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for legal entities by name with fuzzy matching and pagination. For quick name suggestions, use autocomplete instead.
USE WHEN: "find company X", "search for X", "look up company X"
FAILS WHEN: no results found (try autocomplete for name suggestions, or check spelling; fuzzy matching is on by default).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| fuzzy | No | Use fuzzy matching (default true) | |
| limit | No | Max results per page (default 20) | |
| query | Yes | Company name to search |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and idempotent. The description adds that fuzzy matching is enabled by default and pagination is supported, along with failure behavior. This supplements the annotations well without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, well-structured sentences covering purpose, usage scenarios, and failure handling. No extraneous information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While usage and failure are well-covered, there is no description of the output/return structure. Given no output schema, this is a notable omission. Also, no mention of other sibling tools like lei_lookup or search_by_bic that might be relevant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description does not add significant new meaning beyond the schema (e.g., it states fuzzy is default, which matches schema default). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and resource 'legal entities', with specific features like fuzzy matching and pagination. It explicitly differentiates from sibling 'autocomplete' by directing users to use autocomplete for quick name suggestions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit USE WHEN examples ('find company X', 'search for X') and FAILS WHEN conditions, including fallback advice to try autocomplete or check spelling. This gives clear context for when to invoke this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if an LEI code is valid and active. USE WHEN: "is this LEI valid?", "verify LEI", "check LEI format". Performs format (20 chars), check digit (ISO 17442), and database status checks. For full entity details, use lei_lookup instead. NOTE: Never returns an error for invalid LEIs; returns valid=false with a reason message instead. Safe to call on untrusted input.
| Name | Required | Description | Default |
|---|---|---|---|
| lei | Yes | LEI code to validate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes validation steps (format, check digit, database status) and error behavior (no error, returns valid=false with reason). Annotations already indicate read-only and idempotent, but description adds valuable context about untrusted input safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly written sentences: purpose, usage cues, behavioral note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully adequate for a simple validation tool: describes purpose, behavior, usage guidance, and safety. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only parameter 'lei' is well-described in schema (100% coverage), with description reinforcing its purpose but not adding substantial new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it checks if an LEI code is valid and active, lists example user queries, and distinguishes from sibling tool lei_lookup for full details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'USE WHEN' with example queries and guidance to use lei_lookup for entity details, providing clear context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct operation: autocomplete vs search_entity, lei_lookup vs validate_lei, get_lei_issuer vs list_lei_issuers, etc. No overlapping purposes.
Most tools follow verb_noun snake_case (e.g., batch_lei_lookup, get_relationships). The only minor deviation is 'autocomplete' as a single verb, but the pattern is otherwise consistent.
12 tools cover LEI lookup, search, validation, batch, relationships, exceptions, issuers, and cross-references. Well-scoped for the domain.
The surface includes core operations (lookup, search, validation), batch processing, relationship analysis, exceptions, issuer info, and multiple identifier cross-references. No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
GLEIF MCP — Global Legal Entity Identifier Foundation (free, no auth)
Hosted MCP server for real-world data: business registries, sanctions, companies, domains, crypto.
Remote MCP server to enrich company profiles with structured B2B data and confidence scores.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/olgasafonova/gleif-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
