Skip to main content
Glama

Screening lookup

screening_lookup
Read-onlyIdempotent

Screenings run for the caller's team, covering organizations and countries, and natural persons only in workspaces where person data is switched on (elsewhere a person screening answers not_found and the person filter an empty page); each row names its team (team_id, team_name; both null on a workspace wide screening every team reads). Without screening_id this lists screening runs newest first, filterable by subject_type (entity, country or person), by the subject's ids (node_id for a company from search_companies, entity_id for a registry institution from company_profile, iso3 for a country), or by subject name; paged with limit (default 20, maximum 100) and offset, and the response carries the exact total. With screening_id it returns that one run in full. First comes official_lists, a deterministic comparison of the subject with each official sanctions list it names, made when the run is read and not on the screening day, one status per list (listed only on an identifier the list itself states, name match awaiting review, name match reviewed, no entry found, or not checked with the reason; a name match is never a hit, names match exactly so other spellings are not found, and a list that was not checked never reads as clear). Each entry of an entity, vessel or aircraft carries published_fields, the fields its list publishes on it, verbatim, each with the path where the list states it; the fields that can state a natural person (free text, other parties, contact lines) are served only in workspaces where person data is switched on, elsewhere they are withheld and published_note says so. Then the adverse media verdicts per category with rationale and review state, the drafted summary, grounded findings with their press quotes, and the sources behind them. A person screening returns official_lists and its grounded findings with their sources and nothing else, never a verdict, an assessment, a drafted summary or any score, rating or ranking of the person. Findings quote reported coverage, not established fact.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
iso3NoFilter by the screened country's ISO alpha-3 code.
limitNoPage size, default 20, maximum 100.
offsetNoRows to skip, default 0.
node_idNoFilter by the subject's graph node id.
subjectNoFilter by subject name, matched on its normalized form.
entity_idNoFilter by the subject's registry entity id.
screening_idNoA screening id from the list; when present the other arguments are not used.
subject_typeNoFilter the list by subject kind.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / entity_id / maximum
      Added value: +2147483647
    • addedInput schema / properties / node_id / maximum
      Added value: +2147483647
    • addedInput schema / properties / offset / maximum
      Added value: +9223372036854776000
    • addedInput schema / properties / screening_id / maximum
      Added value: +2147483647
  2. Changed1 schema field changed
    • changedInput schema / properties / subject_type / enum
      Previous value: -[
      -  "entity",
      -  "country"
      -]New value: +[
      +  "entity",
      +  "country",
      +  "person"
      +]
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already cover the read-only, idempotent, non-destructive safety profile, yet the description adds substantial behavioral context: person screenings answer not_found where person data is off, official_lists are computed at read time not screening day, name matches are never hits and exact-match only, unchecked lists never read as clear, person fields are withheld with a published_note, and person results never carry a verdict/score/rating. This is well beyond what annotations provide.

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 scope statement is front-loaded, but the body is an unusually dense run-on with nested parentheticals and semicolon-joined clauses that make it hard to parse quickly. Most content earns its place, but the prose could be cut and broken into structured points without losing information.

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 carries the return-value burden and does so: it describes official_lists and one status per list, published_fields with their paths, adverse media verdicts with rationale and review state, the drafted summary, grounded findings with press quotes, and sources. For a complex tool with 8 params and no output schema, this is complete enough to call correctly.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it maps node_id to companies from search_companies, entity_id to registry institutions from company_profile, and iso3 to countries, and clarifies the screening_id precedence rule. It does not add format or syntax detail beyond the schema for the paging parameters, so it is not a full 5.

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 a precise verb+resource (list screening runs, or return one run in full) and clearly distinguishes the two modes by the presence or absence of screening_id. It also carves out its niche against siblings like sanctions_person_candidates and entity_risk_profile by naming what it covers (official_lists, adverse media verdicts, findings). An agent can identify the tool without opening the schema.

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?

It gives clear when-to-use context for each mode: without screening_id it lists runs (with filter options), with screening_id it returns a single run and ignores other args. It also states the person-data prerequisite that governs whether person screenings and person fields are available. It does not explicitly route the agent to named alternatives among siblings, 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources