Skip to main content
Glama
B2A Fulfillment Factory

B2A Fulfillment Factory

by ceadigital

gleif_lei_kyb

Read-only

Verify corporate legal identity and jurisdiction against GLEIF LEI records for KYB checks.

Instructions

Global Legal Entity Identifier (GLEIF) corporate KYB and jurisdiction verification.

Input Schema

NameRequiredDescriptionDefault
nameYesCorporate legal entity name (e.g. 'Coinbase')

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.5/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered externally. The description adds nothing beyond that: no note on coverage gaps (not all companies have an LEI), no indication of what the response contains, and no caveats about fuzzy name matching or multiple candidate entities.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single compact sentence with no filler, which is good, but the brevity comes at the cost of under-specification rather than genuine efficiency. Leading with a verb phrase describing the lookup would use the same space far better.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read tool with no output schema, the description should say roughly what comes back (LEI code, legal jurisdiction, entity status) and what happens on no-match. Neither is present, leaving an agent unable to predict or validate the result. Annotations cover safety but not outcome expectations.

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?

Only one parameter, and the schema documents it at 100% coverage with type and an example ('Coinbase'). The description adds no additional meaning about how the name is matched (exact vs fuzzy) or how ambiguity is handled, so the baseline of 3 applies.

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

Purpose3/5

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

Names a specific resource (GLEIF Legal Entity Identifier) and a purpose (corporate KYB and jurisdiction verification), which distinguishes it from siblings like sec_edgar_cik_lookup or fdic_bank_health. However, it is a noun phrase with no verb — an agent must infer that it accepts a company name and looks up its LEI record. The acronym-heavy 'KYB' phrasing further blurs the concrete action.

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

Usage Guidelines2/5

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

No when-to-use guidance, no exclusions, and no comparison to the many sibling lookup tools that also resolve corporate entities (SEC CIK, FDIC bank health). An agent gets no signal about when GLEIF is the right registry versus those alternatives, or what to do when an entity has no LEI.

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