Skip to main content
Glama
Hei33enberg

WhiteIntel MCP Server

by Hei33enberg

graph_neighbourhood

Maps ownership and control links around an entity in both directions, showing who it controls, who controls it, and their neighbors within a bounded number of hops.

Instructions

Return every ownership/control edge within a bounded number of hops of one entity, in BOTH directions: who it controls, who controls it, and their neighbours. Use it to answer 'what sits around this company?' — the wider view that trace_ownership_path (upward only) does not give. Hard-capped in the database: depth 3, 300 edges, and at most 25 edges followed per entity per direction per hop. READ THE DEPTH FIELDS IN THE RESPONSE — DO NOT ASSUME YOU GOT THE DEPTH YOU ASKED FOR. There is no field called depth any more, and that rename is deliberate: the old depth was the CLAMPED REQUEST, never the depth walked, and it was being read as a promise. The response now carries depth_requested (what your plan allowed), depth_walked (measured off the returned edges' own hop numbers — the only depth that is actually proven), depth_capped, and completeness. Measured 2026-08-11 on an anonymous caller: depth=3 requested returned depth=2 with depth_capped=true, because the free plan caps every walk at 2 hops. Any sentence you write about what is or is not around this entity must be scoped to the RETURNED depth. EDGE COUNTS FELL BY UP TO 2.7x ON 2026-08-11 AND NOTHING WAS LOST — read this before you treat it as the corpus shrinking. Until that date the walk emitted the same edge two and three times at depth 2 or more, edge_count counted the duplicated list, and the duplicates were charged against your edges budget. Measured on identical requests before and after the fix: 72 -> 27, 29 -> 13, and at the maximum budget 300 rows holding 285 real edges -> 300 rows holding 300. So a call you made yesterday and repeat today can return far fewer edges for the same subject: the smaller number is the true one, and your budget now buys real edges. One consequence worth knowing: at depth 1 a root can drop from 4 edges to 2, because the registry genuinely holds rows that are identical in every field this endpoint returns and the response has no way to represent the difference. That is also a correction, not a loss. truncated: true plus a plain-language truncation_note does work and does mean the edge budget ran out (verified with edges=10); that is NORMAL for hub entities (the corpus holds single nodes with more than 22,000 edges) and means the picture is partial, not wrong. Each edge carries origin: 'registry' (observed in a source registry) or 'derived'/'curated'/'asserted' (inferred by WhiteIntel). Get the root id from search_entities or resolve.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rootYesRoot entity uuid.
depthNoHops to walk (default 2). A REQUEST, not a guarantee — the plan caps it (anonymous callers measured at 2 hops) and the response's `depth_walked` is the authority — it is measured from the edges that came back, not echoed from your request.
edgesNoEdge budget (default 120). Lower it for a legible picture, raise it for completeness.
Behavior5/5

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

No annotations are provided, so the description carries full weight. It discloses hard caps, depth clamping, deduplication changes, truncation behavior, edge-count expectations, and a warning not to trust requested depth. This is far more transparent than typical tool descriptions.

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?

The description is front-loaded with the core purpose and sibling distinction, which is helpful. However, it becomes quite long and mixes historical measurements, explicit troubleshooting notes, and warnings in a way that requires careful parsing; a tighter summary would improve scanability without losing key caveats.

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?

Without an output schema, the description provides important response semantics: depth_requested, depth_walked, depth_capped, completeness, truncation, edge_count, and edge origin. It also covers edge cases around hubs and duplicate records, making the tool safe to invoke even under complex conditions.

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 input schema already covers 100% of parameters, so the baseline is 3. The description adds meaningful semantic context for the `depth` and `edges` parameters (request vs actual depth, budget and deduplication) and points to source endpoints for `root`.

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 states explicitly that it returns ownership/control edges within a bounded number of hops in both directions, with entity neighbours. It also distinguishes itself from the sibling `trace_ownership_path` by noting that tool is upward-only, making the tool's purpose and scope 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?

It gives a clear use case: 'what sits around this company?' and explicitly contrasts the wider neighbourhood view with `trace_ownership_path` (upward only). It also tells the agent how to obtain the root id via `search_entities` or `resolve`, so invocation prerequisites are clear.

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