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, stored when the run ran (basis screening; an older run reads its own record, basis not_stored, each list not checked at the time, with a recheck as its own block, basis recheck), one status per list (listed only on an identifier the list itself states, name match awaiting review, name match reviewed, a name match since delisted, no entry found naming its check, 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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "screening_lookup"
  }
}

Input 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. Changed1 schema field changed
    • addedInput schema / properties / iso3 / pattern
      Added value: +"^[A-Za-z]{3}$"
  2. 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
  3. Changed1 schema field changed
    • changedInput schema / properties / subject_type / enum
      Previous value: -[
      -  "entity",
      -  "country"
      -]New value: +[
      +  "entity",
      +  "country",
      +  "person"
      +]
  4. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare readOnly/idempotent/non-destructive/closed-world; the description adds substantially more: person-data gating and withholding of natural-person fields with published_note, the basis values (screening, not_stored, recheck) and how an older run reads its own record, the six possible per-list statuses including 'not checked with the reason', and the explicit caveat that a name match is never a hit and an unchecked list never reads as clear. It also discloses that a person screening returns only official_lists and grounded findings, never a verdict or score, and that findings quote reported coverage rather than established fact.

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?

Information-dense and reasonably front-loaded (scope first, then list mode, then detail mode, then response shape), and nearly every clause carries real semantics. However it is delivered as a few very long run-on sentences with nested parentheses, making the response-shape section hard to parse, and it repeats schema-stated facts like the limit default and maximum and the offset parameter.

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 and a genuinely complex return payload, the description carries the full burden and does so: it orders the response (official_lists first, then adverse media verdicts, drafted summary, grounded findings, sources), explains per-entry published_fields with their paths, and states what a person screening omits. An agent can predict the shape of the result before calling.

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; the description earns above that by giving provenance for the id filters (node_id from search_companies, entity_id from company_profile, iso3 for a country), which tells an agent where to obtain valid values. It also clarifies that subject is matched on a normalized form and that screening_id disables the other arguments. Some content (limit default 20 / max 100, offset) merely restates the schema.

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?

Opens by naming the resource and its scope ('Screenings run for the caller's team, covering organizations and countries, and natural persons only where person data is switched on'), then splits the two modes explicitly: without screening_id it lists runs newest-first, with screening_id it returns one run in full. That verb+resource+mode framing lets an agent tell it apart from siblings like sanctions_person_candidates or entity_risk_profile without opening a 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?

Gives concrete selection conditions for every filter (subject_type, node_id for a company, entity_id for a registry institution, iso3 for a country, subject name) and states that screening_id supersedes the other arguments. It also flags the person-data precondition and the resulting not_found / empty-page behavior, which is real when-to-use guidance. It stops short of naming a sibling tool to use instead when this one is the wrong choice (e.g. versus sanctions_person_candidates), so it is not a full 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