Skip to main content
Glama
Sign In

ARM Verify — Entity Intelligence API

by app.railway.up.brilliant-illumination-production-9bda
OverviewDiscussionsAdmin

map_ownership

Trace the corporate ownership chain above a company and identify the natural persons who ultimately control it. RETURNS JSON with: ownership_chain (array of parent entities, each with name, relationship, jurisdiction and is_ubo_candidate), natural_persons (array of identified beneficial owners, each with name, nationality and natures_of_control such as "ownership-of-shares-75-to-100-percent"), lei of the subject entity, complexity ("SIMPLE", "COMPLEX" or "UNKNOWN"), data_confidence ("HIGH", "MEDIUM" or "LOW") and notes describing the chain depth found. SOURCES: GLEIF Relationship API for LEI parent-child records, Companies House PSC (People with Significant Control) Register for UK entities, and the OpenCorporates corporate network. USE WHEN beneficial-ownership disclosure is required under AML or KYC rules, or to detect ownership by a sanctioned parent. BILLING: with an API key each call is charged $12.00 from the key's credits, exactly as POST /verify (refused when the balance is too low); bank portal sessions are not charged.

Input Schema

NameRequiredDescriptionDefault
depthNoRequested ownership-chain depth, 1 to 3 (1 = immediate parent only, 3 = up to three levels up). Example: 2. Accepted for forward compatibility but NOT yet enforced — the current implementation returns the full chain it can discover from the available sources regardless of this value.
entity_nameYesFull registered company name of the subsidiary or subject company whose owners you want. Example: "Volkswagen AG".
jurisdictionYesISO 3166-1 alpha-2 country code of incorporation, uppercase. Examples: "GB", "DE", "US", "NL". UK entities ("GB") return the richest data because the PSC Register is queried in addition to GLEIF.
registration_numberNoOptional national company number. Strongly recommended for UK entities, where it makes the PSC Register lookup exact instead of name-based. Example: "00445790" (GB, 8 digits). Omit if unknown.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / depth / description
      Previous value: -"Ownership chain depth (1-3)"New value: +"Requested ownership-chain depth, 1 to 3 (1 = immediate parent only, 3 = up to three levels up). Example: 2. Accepted for forward compatibility but NOT yet enforced — the current implementation returns the full chain it can discover from the available sources regardless of this value."
    • changedInput schema / properties / depth / type
      Previous value: -"number"New value: +"integer"
    • changedInput schema / properties / entity_name / description
      Previous value: -"Company name"New value: +"Full registered company name of the subsidiary or subject company whose owners you want. Example: \"Volkswagen AG\"."
    • changedInput schema / properties / jurisdiction / description
      Previous value: -"ISO 2-letter country code (e.g. GB, DE, US)"New value: +"ISO 3166-1 alpha-2 country code of incorporation, uppercase. Examples: \"GB\", \"DE\", \"US\", \"NL\". UK entities (\"GB\") return the richest data because the PSC Register is queried in addition to GLEIF."
    • changedInput schema / properties / registration_number / description
      Previous value: -"Company registration number — improves UK PSC lookup accuracy"New value: +"Optional national company number. Strongly recommended for UK entities, where it makes the PSC Register lookup exact instead of name-based. Example: \"00445790\" (GB, 8 digits). Omit if unknown."
  2. Changed4 schema fields changed
    • addedInput schema / properties / depth / description
      Added value: +"Ownership chain depth (1-3)"
    • addedInput schema / properties / entity_name / description
      Added value: +"Company name"
    • addedInput schema / properties / jurisdiction / description
      Added value: +"ISO 2-letter country code (e.g. GB, DE, US)"
    • addedInput schema / properties / registration_number / description
      Added value: +"Company registration number — improves UK PSC lookup accuracy"
  3. Changed4 schema fields changed
    • removedInput schema / properties / depth / description
      Removed value: -"Ownership chain depth (1-3)"
    • removedInput schema / properties / entity_name / description
      Removed value: -"Company name"
    • removedInput schema / properties / jurisdiction / description
      Removed value: -"ISO 2-letter country code (e.g. GB, DE, US)"
    • removedInput schema / properties / registration_number / description
      Removed value: -"Company registration number — improves UK PSC lookup accuracy"
  4. Changed2 schema fields changed
    • changedInput schema / properties / jurisdiction / description
      Previous value: -"ISO 2-letter country code"New value: +"ISO 2-letter country code (e.g. GB, DE, US)"
    • addedInput schema / properties / registration_number
      Added value: +{
+  "description": "Company registration number — improves UK PSC lookup accuracy",
+  "type": "string"
+}
  5. First observed

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the billing model ($12.00 per call, refused when balance is too low, bank portal sessions free), the three data sources consulted, and the output's confidence/complexity signals. It omits rate limits and error/coverage-failure behavior, leaving a minor gap.

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?

Front-loaded with the core purpose, then organized under clear RETURNS/SOURCES/USE WHEN/BILLING markers. It is dense and somewhat long, but each block (output shape, sources, billing) earns its place given the absent output schema.

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?

No output schema exists, so the description must — and does — enumerate the return structure in detail (ownership_chain, natural_persons, natures_of_control, lei, complexity, data_confidence, notes). For a high-complexity ownership-tracing tool it is nearly complete, missing only explicit coverage limitations and auth/prerequisite notes.

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?

Schema description coverage is 100%, so all four parameters are already documented with examples, ranges and notes. The description adds no parameter-level detail beyond the schema, so the baseline 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?

States a specific verb and resource ('Trace the corporate ownership chain above a company') plus the end goal ('identify the natural persons who ultimately control it'). This is clearly distinct from the screening/verification siblings, so an agent can route to it without ambiguity.

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

Usage Guidelines4/5

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

Gives explicit triggering conditions: 'USE WHEN beneficial-ownership disclosure is required under AML or KYC rules, or to detect ownership by a sanctioned parent.' No named alternatives or when-not guidance against verify_entity/screen_sanctions, so it stops short of a 5.

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

All ARM Verify — Entity Intelligence API toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources