Skip to main content
Glama
Hei33enberg

WhiteIntel MCP Server

by Hei33enberg

trace_ownership_path

Traces the ownership graph upward from a root entity to reveal the chain connecting it to the ultimate beneficial owner. Check depth_capped to distinguish intermediate holders from the true UBO.

Instructions

Walk the ownership graph upward from a root entity and return the ordered hops connecting it to the ultimate beneficial owner. Use this to answer 'who ultimately controls X?'. Get the root id from search_entities. THE HOP AT THE TOP OF THE LIST IS NOT NECESSARILY THE ULTIMATE OWNER, AND max_depth IS A REQUEST, NOT A PROMISE. Measured 2026-08-11 anonymously: max_depth=6 came back as max_depth: 2, depth_capped: true, plan: 'free' — the walk stopped two hops up and the payload said so only in those two fields. So before you name a UBO, compare hop_count with the RETURNED max_depth and check depth_capped: if the walk was capped and the topmost owner still has owners, you have found an intermediate holder, not the beneficial owner. A paid API key walks deeper. Shape: a single flat hops array (each hop from/fromName/to/toName/role/share/source), not one array per branch. as_observed is a standing caveat: edges carry the date we OBSERVED them in a registry, not a validity period — we hold no ownership end dates, so a link shown here may already have ended.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rootYesRoot entity id to trace from.
max_depthNoMax hops to request (default 6). The plan lowers it — anonymous callers measured at 2 — so trust the response's `max_depth` / `depth_capped`, not this value.
Behavior5/5

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

Despite no annotations, the description reveals critical behavior: max_depth is 'a REQUEST, not a PROMISE,' top hop is not necessarily UBO, and includes a measured example of depth capping (max_depth=6 returned as max_depth:2, depth_capped:true). It also discloses the standing caveat on `as_observed` dates, covering data-validity limitations.

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?

The description is long but every sentence carries unique information: purpose, use case, root source, critical warnings, response shape, and caveats. It is front-loaded with the main action, but the density makes it slightly less concise than shorter equivalents.

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?

With no output schema, the description provides the full response shape (flat `hops` array with fields from/fromName/to/toName/role/share/source), key response fields (`hop_count`, `max_depth`, `depth_capped`), and interpretation guidance. It covers edge cases and data caveats, making it fully contextual.

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?

The schema already covers both parameters thoroughly (100% coverage), so baseline is 3. The description adds a concrete measured example and the instruction to fetch root from search_entities, enriching semantics but not fundamentally changing the baseline.

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?

Description opens with 'Walk the ownership graph upward from a root entity and return the ordered hops' – a specific verb+resource+output. It further clarifies the use case with 'who ultimately controls X?' and distinguishes from general graph tools like graph_path.

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 states 'Use this to answer ''who ultimately controls X?''' and instructs 'Get the root id from search_entities.' It also provides detailed guidance on handling depth capping and verifying UBO, effectively telling the agent when to trust the result.

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