Skip to main content
Glama
sebastienrousseau

acmt001-mcp

by sebastienrousseau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Verify a LEI against the live GLEIF register

verify_lei_online
Read-onlyIdempotent

Verify a Legal Entity Identifier against the live GLEIF register to confirm it is registered and retrieve the entity's legal name, status, country, and registration details.

Instructions

Verify a LEI against the live GLEIF register (reaches the network).

Unlike ``validate_identifier``, which checks an LEI's format and check
digits entirely offline, this tool performs a live HTTP GET against the
public GLEIF REST API (``api.gleif.org``) to confirm the LEI is actually
registered and to return the registered entity's details. It therefore
requires network access and is marked open-world.

Requires the optional ``online`` extra (``pip install acmt001-mcp[online]``)
for the ``httpx`` HTTP client; without it a graceful ``{"error": ...}`` is
returned rather than raising.

Returns a dict with the ``lei``, registered ``legal_name``, entity
``status``, ``country``, and registration ``registration_status``,
``initial_registration_date``, ``last_update_date`` and
``next_renewal_date``. On failure returns ``{"error": ...}``: an
``LEI not found`` error for an unregistered LEI (HTTP 404), or a
``GLEIF API unavailable`` error for any other non-200 response or a
transport/connection error.

Args:
    lei_code: A 20-character ISO 17442 Legal Entity Identifier.

Input Schema

NameRequiredDescriptionDefault
lei_codeYesA 20-character ISO 17442 Legal Entity Identifier to look up in the live GLEIF register, e.g. '5493001KJTIIGC8Y1R12'. Use validate_identifier(kind='lei', ...) first for a purely offline check-digit/format check.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.0.6

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only, open-world and idempotent, but the description adds substantive context beyond them: the optional `online` extra and httpx dependency, network requirement, graceful `{"error": ...}` fallback instead of raising, and the specific 404 vs. non-200/transport failure mapping.

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 purpose and the key contrast, then dependency and error behavior; well structured. The trailing Args block largely repeats the parameter description already present in the schema, a minor redundancy rather than bloat.

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?

There is no output schema, yet the description enumerates the return dict fields (lei, legal_name, status, country, registration_status, dates) and the two failure modes. An agent has everything needed to call it and interpret the result.

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?

Only one parameter with 100% schema coverage, so the schema already documents format and example. The description restates the 20-character ISO 17442 requirement but adds no syntax or semantics beyond the schema, which is the expected baseline for a single fully-covered parameter.

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 (verify), resource (LEI), and scope (against the live GLEIF register), and immediately flags the network-reaching nature. It explicitly contrasts itself with the sibling validate_identifier so an agent can disambiguate 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 Guidelines5/5

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

Gives an explicit when/when-not: use validate_identifier for an entirely offline format/check-digit test, use this tool for live registration confirmation against the GLEIF API. The alternative and the selecting condition are both named, including a pointer in the parameter description.

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

Deploy Server

Other Tools