Skip to main content
Glama
Sign In

ARM Verify — Entity Intelligence API

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

screen_sanctions

Screen a company or person against consolidated government sanctions lists and a politically-exposed-person dataset. RETURNS JSON with: screening_result (one of "MATCH", "POSSIBLE_MATCH", "CLEAR"), risk_level ("CRITICAL" for a confirmed match, "HIGH" for a possible match, "LOW" when clear), recommendation ("DO_NOT_PROCEED", "ENHANCED_DUE_DILIGENCE" or "PROCEED"), matches (array, each with list, matched_name, confidence as a percentage string such as "100%", type and id), pep_screening (separate PEP verdict with its own matches), sanctions_lists_checked, total_entries_screened, data_freshness (ISO timestamp of the last refresh), screening_date, and evidence (reference_id, screened_at, matching method and thresholds, one row per list with its result and last refresh, the 5 closest names even below the threshold, and a one-sentence conclusion). SOURCES: OFAC SDN (US Treasury), UN Security Council Consolidated List, EU Financial Sanctions List, and the UK FCDO UK Sanctions List (UKSL) — approximately 32,600 designations in total, plus roughly 1,000,000 PEP names from OpenSanctions. All lists are re-downloaded from the official government endpoints daily at 03:00 UTC. USE WHEN you must clear a counterparty before payment, onboarding, or any transaction with sanctions exposure. BILLING: with an API key each call is charged $4.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
countryNoOptional ISO 3166-1 alpha-2 country code of incorporation, residence or principal operation, uppercase. Examples: "RU", "IR", "GB", "AE". Recorded on the screening report for audit purposes; screening itself runs against every list regardless of country, and it does not change the risk score. Omit if unknown — the report then shows country as null.
thresholdNoMatch confidence threshold 0.5-1.0. Default 0.75. Lower values catch more potential matches; higher values reduce false positives. MATCH requires >=0.90 regardless of threshold.
entity_nameYesFull name of the company or individual to screen. Examples: "Rosneft", "Gazprom PJSC", "Vladimir Putin". Matching is token-based and case-insensitive, and also searches recorded aliases and a.k.a. names.
entity_typeNoWhether the subject is a legal entity or a natural person. Accepts exactly "company" or "individual". Defaults to "company" when omitted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / country / description
      Previous value: -"ISO 3166-1 alpha-2 country code of incorporation, residence or principal operation, uppercase. Examples: \"RU\", \"IR\", \"GB\", \"AE\". Recorded on the screening report for audit purposes; screening itself runs against every list regardless of country."New value: +"Optional ISO 3166-1 alpha-2 country code of incorporation, residence or principal operation, uppercase. Examples: \"RU\", \"IR\", \"GB\", \"AE\". Recorded on the screening report for audit purposes; screening itself runs against every list regardless of country, and it does not change the risk score. Omit if unknown — the report then shows country as null."
    • changedInput schema / required
      Previous value: -[
-  "entity_name",
-  "country"
-]New value: +[
+  "entity_name"
+]
  2. Changed1 schema field changed
    • addedInput schema / properties / threshold
      Added value: +{
+  "description": "Match confidence threshold 0.5-1.0. Default 0.75. Lower values catch more potential matches; higher values reduce false positives. MATCH requires >=0.90 regardless of threshold.",
+  "maximum": 1,
+  "minimum": 0.5,
+  "type": "number"
+}
  3. Changed3 schema fields changed
    • changedInput schema / properties / country / description
      Previous value: -"Country of incorporation or operation"New value: +"ISO 3166-1 alpha-2 country code of incorporation, residence or principal operation, uppercase. Examples: \"RU\", \"IR\", \"GB\", \"AE\". Recorded on the screening report for audit purposes; screening itself runs against every list regardless of country."
    • changedInput schema / properties / entity_name / description
      Previous value: -"Entity name to screen"New value: +"Full name of the company or individual to screen. Examples: \"Rosneft\", \"Gazprom PJSC\", \"Vladimir Putin\". Matching is token-based and case-insensitive, and also searches recorded aliases and a.k.a. names."
    • changedInput schema / properties / entity_type / description
      Previous value: -"Type of entity"New value: +"Whether the subject is a legal entity or a natural person. Accepts exactly \"company\" or \"individual\". Defaults to \"company\" when omitted."
  4. Changed3 schema fields changed
    • addedInput schema / properties / country / description
      Added value: +"Country of incorporation or operation"
    • addedInput schema / properties / entity_name / description
      Added value: +"Entity name to screen"
    • addedInput schema / properties / entity_type / description
      Added value: +"Type of entity"
  5. Changed3 schema fields changed
    • removedInput schema / properties / country / description
      Removed value: -"Country of incorporation or operation"
    • removedInput schema / properties / entity_name / description
      Removed value: -"Entity name to screen"
    • removedInput schema / properties / entity_type / description
      Removed value: -"Type of entity"
  6. First observed

TDQS

A4.2/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 burden and does well: it discloses the exact cost ($4.00 per call, refused on low balance, bank portal sessions exempt), data provenance and daily 03:00 UTC refresh, the four source lists and their sizes, and the full return shape including evidence. It never explicitly states the call has no side effects / is a read-only computation, which is the one behavioural trait left implicit.

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?

It is long, but it is front-loaded (purpose, then return shape, then sources, then when-to-use, then billing) and the return enumeration earns its space because there is no output schema. Some of the source-list sizing and evidence-field detail is more than strictly needed for tool selection.

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?

For a screening tool with no output schema and no annotations, the description covers what the agent needs: what is screened, against which lists, how fresh the data is, what the response contains, what it costs, and when to call it. Nothing material is missing.

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 coverage is 100%, so entity_name, entity_type, country and threshold are already fully documented in the schema, including defaults, ranges and the >=0.90 MATCH rule. The description adds no parameter-level syntax or format detail beyond that, so the baseline 3 applies.

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 (screen) and resource (company or person against government sanctions lists plus a PEP dataset), and the sibling set (map_ownership, score_risk, verify_entity) is clearly not what this does — none of them screen against sanctions lists. The purpose is unambiguous from the first sentence.

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?

"USE WHEN you must clear a counterparty before payment, onboarding, or any transaction with sanctions exposure" gives a concrete triggering context. It stops short of naming an alternative sibling (e.g. verify_entity) or stating when NOT to use it, so it is clear context without exclusions.

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