Skip to main content
Glama
Hei33enberg

WhiteIntel MCP Server

by Hei33enberg

search_entities

Search the full WhiteIntel corpus by company or person name to retrieve entity IDs with jurisdiction, type, and risk filters. Returns cited source provenance for ownership, sanctions, and offshore exposure investigations.

Instructions

Search every node in the live WhiteIntel corpus — companies AND people — by name, across all fused sources. This is the lexical search and it always covers the FULL corpus, so it is the fallback whenever semantic_search comes back thin. Returns entity ids you then pass to get_entity or trace_ownership_path. Each hit's source says whether it came from the resolved corpus or a live registry passthrough — it does NOT name the originating registry. For that provenance call get_entity, whose entity.registry_profile names the source register when we hold one — measured 2026-08-11 it was populated on 22 of 32 sampled entities, so expect null sometimes and fall back to linked_records[].registry and connections[].source — or get_dossier, which cites per-record source URLs. Use juris to scope to a country (e.g. gb, ky, us, cy). Reach into the non-UK sources is verified, not assumed: a name search for 'PETROLEO BRASILEIRO' returned FR (siren), BR (lei and br-cnpj) and US (cusip) rows in one response, 2026-08-11.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qYesEntity name or fragment.
riskNoOptional: filter by risk level.
typeNoOptional: filter by entity kind.
jurisNoOptional: filter by jurisdiction code (e.g. gb, ky, us).
limitNoMax results (default 20).
Behavior5/5

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

Discloses that the source field indicates resolved vs live passthrough, does not name the originating registry, suggests get_entity for that, and notes the fallback options. Also provides a concrete example with verified non-UK sources, showing transparency about data coverage.

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

Conciseness2/5

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

The description is overly verbose, containing a long digression about provenance, specific measurement dates, and an example. While the initial sentence is clear, the subsequent details could be streamlined to improve conciseness without losing essential information.

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?

Given the tool's complexity and many siblings, the description covers the primary use case, fallback behavior, result handling, and a key parameter. It could mention potential errors or the exact output format, but it is largely complete for a search tool.

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 description only adds extra context for the juris parameter (scoping to a country) and does not elaborate on q, risk, type, or limit. Since the schema already provides descriptions for all parameters (coverage 100%), the added value is limited, so a baseline of 3 is appropriate.

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?

Clearly states it searches all nodes (companies AND people) by name across all fused sources, and distinguishes it from semantic_search by calling it the fallback lexical search.

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?

Explicitly instructs when to use it (fallback when semantic_search returns thin results), how to use the returned IDs (pass to get_entity or trace_ownership_path), and mentions the juris parameter for scoping.

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