Skip to main content
Glama
Hei33enberg

WhiteIntel MCP Server

by Hei33enberg

resolve

Batch-resolve company names or identifiers to canonical entity IDs in one call, with exact or name confidence. Unmatched rows return null. Enrich lists, then feed IDs into dossiers, ownership traces, or sanctions screening.

Instructions

Batch-resolve a list of company names or strong identifiers (scheme:value — lei, siren, gb-coh, uen, br-cnpj, sec, ofac, eu, un, uk, krs) to canonical WhiteIntel entity ids in ONE call. Each result carries a confidence: 'exact' (identifier match) or 'name' (top name hit); an unmatched row comes back as { match: null, confidence: null }, so check for it rather than assuming positional success. Use this to enrich a whole list — suppliers, counterparties, a portfolio — without one lookup per row. Then feed the ids into get_dossier / trace_ownership_path / get_sanctions. Up to 25 items anonymously (a 26th returns HTTP 400 with the limit spelled out), 100 with WHITEINTEL_API_KEY. TREAT confidence: 'name' AS A CANDIDATE, NOT A RESOLUTION. It is the top lexical hit and nothing more — measured 2026-08-11, the query 'Tesco' resolved to a FRENCH company literally named TESCO (fr-siren:454067281), not Tesco PLC, while 'gb-coh:00445790' resolved 'exact' to TESCO PLC. Confirm a 'name' match's jurisdiction and identifier before you attach it to a real counterparty; pass an identifier whenever you hold one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queriesYesNames or scheme:value identifiers, e.g. ["Tesco", "siren:552081317", "lei:213800...", "gb-coh:00445790"].
Behavior5/5

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

The description discloses behavior thoroughly: it explains confidence levels ('exact' vs 'name'), handling of unmatched rows (returns `{ match: null, confidence: null }`), and warns that 'name' matches are candidate hits, illustrated with a concrete Tesco example. This transparency is essential since no annotations are provided.

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

Conciseness1/5

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

The description is excessively verbose and repetitive. Key information (e.g., the Tesco example, the confidence semantics, and the limits) is stated multiple times, significantly bloating the text. It could be condensed to a few sentences without losing clarity.

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

Completeness4/5

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

The description provides comprehensive context, including usage scenarios, limits, and edge cases. However, the completeness is marred by redundancy; while all necessary details are present, the over-explanation detracts from efficiency. A more concise version would achieve the same completeness.

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

Parameters5/5

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

The description explains the 'queries' parameter in detail: it accepts a list of company names or strong identifiers in 'scheme:value' format, with examples like 'siren:552081317' and 'gb-coh:00445790'. This fully clarifies the expected input structure.

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?

The description clearly states the tool's function: batch-resolving a list of company names or strong identifiers to canonical WhiteIntel entity IDs. It also mentions the output format and confidence levels, making the purpose unambiguous.

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?

The description explicitly advises when to use the tool: 'Use this to enrich a whole list — suppliers, counterparties, a portfolio — without one lookup per row.' It also notes the batch size limits (25 anonymously, 100 with API key), providing clear operational guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Hei33enberg/WhiteIntel-OS'

If you have feedback or need assistance with the MCP directory API, please join our Discord server