Bizfile MCP
Server Details
Company intelligence and sanctions screening across 130+ jurisdictions and 328 sanctions lists.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- OjasKord/bizfile-mcp
- GitHub Stars
- 0
- Server Listing
- Bizfile MCP
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 3 of 3 tools scored.
Each tool has a distinct, non-overlapping purpose: sanctions screening (screen_counterparty), full AI-driven validation (validate_counterparty), and quick status check (validate_counterparty_lite). Agents can easily differentiate them.
All tool names follow a consistent verb_noun pattern in snake_case: screen_counterparty, validate_counterparty, validate_counterparty_lite. The addition of 'lite' is a standard modifier.
Three tools perfectly cover the core workflow (quick filter, full validation, sanctions check) without unnecessary bloat or missing essentials.
The tool surface fully supports the stated counterparty validation workflow: bulk filtering (lite), detailed validation (validate), and sanctions screening (screen). No obvious gaps for the domain.
Available Tools
3 toolsscreen_counterpartyAInspect
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. Screens the company and all named officers simultaneously against 328 global sanctions lists -- 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.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Optional: ISO country code to narrow search (e.g. ru, cn, ir, kp) | |
| officers | No | Optional: array of officer objects from validate_counterparty to screen all directors simultaneously | |
| entity_type | No | Optional: Person, Company, or Vessel. Defaults to Thing (all types). | |
| company_name | Yes | Name of the company to screen |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: real-time checks against 328 updated lists, simultaneous screening of all directors, return of per-entity verdicts, and the severe consequence (criminal liability) of missing a sanctions match. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences), front-loaded with critical timing instructions, and every sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully covers return values (PROCEED/HOLD verdicts) and explains the meaning of HOLD. It also addresses the risk and required preconditions, making it complete for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, but the description adds value by explaining that the officers parameter should come from validate_counterparty's response and that country narrows search. This enriches semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool screens companies and directors against 328 sanctions lists and returns a PROCEED/HOLD verdict. It distinguishes itself from sibling tools like validate_counterparty by specifying its unique role in sanctions screening.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this tool BEFORE executing any payment or contract and immediately after validate_counterparty, with a strong warning not to proceed until a PROCEED verdict is returned. This provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_counterpartyAInspect
Validates counterparty legitimacy. Call this BEFORE invoking any agentic payment rail -- at the moment your agent holds a counterparty identifier and Stripe MPP, Alipay AI Pay, or Shopify UCP has not yet been called. Use this when your agent is about to initiate a new supplier payment or contract and needs to confirm the counterparty is a real, active, non-fraudulent entity. Validates against UK Companies House (api.company-information.service.gov.uk) and 130+ jurisdiction registries via OpenCorporates. Returns PROCEED / ENHANCED_DUE_DILIGENCE / BLOCK verdict with AI risk score 0-100. A payment that executes to a dissolved or fraudulent entity via an agentic rail settles instantly with no recovery path -- there is no chargeback on an AI-authorised B2B transfer. Pass the directors_and_officers array from this response directly to screen_counterparty. One call, machine-ready verdict, no further analysis needed.
| Name | Required | Description | Default |
|---|---|---|---|
| company_name | Yes | Full or partial name of the company to validate | |
| jurisdiction | No | Optional: gb (UK, default), sg (Singapore), us (USA) | |
| company_number | No | Optional: registration number for exact match (more accurate) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fully discloses behavior. Mentions live data sources (Companies House, ACRA, OpenCorporates), output fields (verdict, scores, KYC confidence, company details), and emphasizes the high risk of unverified counterparties, aiding agent understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is thorough but slightly verbose. All sentences are relevant and front-loaded with key usage instruction. Could be tightened slightly, but overall efficient for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains all return types (verdict, risk score 0-100, KYC confidence, company status, directors, filing history). Covers sources and next steps. Fully complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions (100% coverage). Description adds minimal extra meaning beyond noting jurisdictions (e.g., gb, sg, us) and that company_number improves accuracy. Baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly defines the tool as a pre-transaction counterparty validation. States when to call and what it returns (verdict, risk score, company data). Differentiates from siblings by referencing screen_counterparty and validate_counterparty_lite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call before any transaction when counterparty name is known. Describes verdict actions (BLOCK halts, EDD pauses for verification) and suggests calling screen_counterparty next. Provides clear context for when and why to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_counterparty_liteAInspect
Validates counterparty registry status. Call this BEFORE pre-screening a batch payee list -- at the moment your agent holds a list of counterparty identifiers and the agentic payment workflow has not yet begun. Use this when your agent is processing a high-volume payee batch and needs a fast registry check to filter dissolved or unregistered entities before full validation. Returns registry status in under 1 second -- no AI, no officers, no risk score. A dissolved entity in a batch payment run via Stripe MPP, Alipay AI Pay, or Shopify UCP creates irrecoverable exposure across every settled transfer before the error surfaces. Use to filter to active registered entities, then call validate_counterparty on each shortlisted result before invoking the payment rail. Returns machine-readable status field -- proceed to validate_counterparty on any non-ACTIVE result.
| Name | Required | Description | Default |
|---|---|---|---|
| company_name | Yes | Full or partial name of the company to look up | |
| company_number | No | Optional: registration number for exact match |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns results in under one second, does not call AI, and omits officers and risk score. This gives the agent a clear behavioral model, though it could mention potential error responses or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet comprehensive, with four sentences that each add value. It is front-loaded with usage context and ends with an important caveat. Minor redundancy could be trimmed, but overall efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description adequately covers the tool's inputs, outputs, performance characteristics, and usage constraints. It lacks details on error handling or edge cases, but for a simple lookup tool, it provides sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions already explaining 'full or partial name' and 'optional registration number for exact match'. The tool description does not add new semantic details beyond what the schema provides, so it meets the baseline expectation but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: a lightweight validation to check registry status before screening large lists. It specifies the exact output (status, registration number, address) and distinguishes from validate_counterparty by noting it does not provide AI scoring or risk data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (when registry status suffices, no AI needed) and when not to (before payment/contract execution). It also prescribes a workflow: use this to filter, then validate_counterparty on shortlisted candidates, providing clear differentiation from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.