Skip to main content
Glama

Bizfile MCP

by io.github.OjasKord

screen_counterparty

Checks counterparty sanctions status. Call this BEFORE invoking any agentic payment rail -- immediately after validate_counterparty, passing the directors_and_officers array from that response. Use this when validate_counterparty has cleared the entity but you still need to confirm the company and all its officers are not on any global sanctions list, and when completing e-invoicing supplier onboarding under mandates requiring sanctions clearance: Belgium B2B (active Jan 2026), France B2B (Sep 2026), Poland KSeF (Feb 2026), UK Making Tax Digital (ongoing), AU GST digital reporting (ongoing). Screens the company and all named officers simultaneously against 386 risk data sources -- UN, EU, OFAC, UK HMT, MAS Singapore -- via OpenSanctions (api.opensanctions.org), updated daily. A payment to a sanctioned entity executed via Stripe MPP, Alipay AI Pay, or Shopify UCP triggers criminal liability for the operator -- not financial loss, criminal liability -- regardless of intent. Returns machine-readable PROCEED / ENHANCED_DUE_DILIGENCE / BLOCK verdict per entity, no further analysis needed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countryNoOptional: ISO country code to narrow search (e.g. ru, cn, ir, kp)
officersNoOptional: array of officer objects from validate_counterparty to screen all directors simultaneously
entity_typeNoOptional: Person, Company, or Vessel. Defaults to Thing (all types).
company_nameYesName of the company to screen

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
edd_countNo
checked_atYes
source_urlYes
_disclaimerNo
block_countNo
company_nameNo
lists_checkedNo
overall_summaryNo
overall_verdictYes
entities_screenedNo
screening_resultsYes
trade_finance_noteNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "_disclaimer": {
+      "type": "string"
+    },
+    "block_count": {
+      "type": "integer"
+    },
+    "checked_at": {
+      "format": "date-time",
+      "type": "string"
+    },
+    "company_name": {
+      "type": "string"
+    },
+    "edd_count": {
+      "type": "integer"
+    },
+    "entities_screened": {
+      "type": "integer"
+    },
+    "lists_checked": {
+      "type": "integer"
+    },
+    "overall_summary": {
+      "type": "string"
+    },
+    "overall_verdict": {
+      "enum": [
+        "PROCEED",
+        "ENHANCED_DUE_DILIGENCE",
+        "BLOCK"
+      ],
+      "type": "string"
+    },
+    "screening_results": {
+      "items": {
+        "properties": {
+          "entity": {
+            "type": "string"
+          },
+          "match_found": {
+            "type": "boolean"
+          },
+          "role": {
+            "type": "string"
+          },
+          "sanctioned": {
+            "type": "boolean"
+          },
+          "summary": {
+            "type": "string"
+          },
+          "verdict": {
+            "enum": [
+              "PROCEED",
+              "ENHANCED_DUE_DILIGENCE",
+              "BLOCK",
+              "UNABLE_TO_SCREEN"
+            ],
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "source_url": {
+      "type": "string"
+    },
+    "trade_finance_note": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "overall_verdict",
+    "screening_results",
+    "source_url",
+    "checked_at"
+  ],
+  "type": "object"
+}
  2. Added

TDQS

A4.7/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. It discloses data sources (386 sources via OpenSanctions), update frequency, and return verdict format. It does not explicitly state it is non-mutating, but the verb 'checks' and 'screens' clearly imply a read-only operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Despite length, every sentence earns its place: purpose, usage ordering, legal mandates, data sources, and return values are all covered without redundancy. It is front-loaded with the core function and maintains a clear flow.

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?

Given the output schema exists, the description still explains return values directly. It covers preconditions (after validate_counterparty), all relevant use cases, compliance specifics, and operational consequences. No critical context is missing for correct invocation.

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%, providing a baseline of 3. The description adds valuable guidance on the 'officers' parameter, specifying it should come from validate_counterparty's response, and mentions the 'country' parameter for narrow search. This goes beyond schema text.

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 opens with a specific verb and resource: 'Checks counterparty sanctions status.' It clearly distinguishes from siblings by stating it is a follow-up to validate_counterparty, focusing on sanctions screening rather than general counterparty validation.

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?

Explicit sequencing is given: 'Call this BEFORE invoking any agentic payment rail -- immediately after validate_counterparty.' It also lists concrete use cases (e.g., e-invoicing mandates) and specifies when to prefer it over other tools.

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

All Bizfile MCP toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: validate_counterparty performs full legitimacy checks including officers and AI risk scoring, validate_counterparty_lite is a fast pre-filter for batch processing, and screen_counterparty handles sanctions screening. The usage contexts are explicitly differentiated in the descriptions, leaving no ambiguity about when to invoke each.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: screen_counterparty, validate_counterparty, validate_counterparty_lite. The 'lite' suffix clearly indicates a lighter variant of validate_counterparty, maintaining a predictable and intuitive naming convention.

Tool Count4/5

With 3 tools, the server is appropriately scoped for its focused domain of counterparty validation and sanctions screening. Each tool covers a distinct step in the workflow without unnecessary redundancy, though the set could arguably be expanded with additional monitoring or detailed reporting tools.

Completeness4/5

The toolset covers the essential lifecycle: fast pre-screening (lite), full validation, and sanctions screening. It supports a typical vendor onboarding flow. Minor gaps exist, such as no tool for ongoing monitoring or retrieving detailed sanctions data, but the core workflow is adequately covered.

Resources