banking-intelligence

country_export_controls

Look up export control restrictions for a specific country.

Returns embargo status, sanctioned programs, control reasons, and restriction details across jurisdictions (US EAR, EU, UN, etc.) for the given country. Response also includes a payment_jurisdiction_note explaining when each listed restriction actually applies to a payment (US controls only bind when there's a US nexus, etc.).

IMPORTANT: Each jurisdiction's controls only bind a payment when the payment has a nexus to that jurisdiction. Use the jurisdiction filter when you know the payment's actual jurisdictional touchpoints (sender country, clearing currency, intermediary banks). For a CHF/EUR payment with no US bank in the chain, US export controls are informational only — do NOT cite them as compliance blockers without confirming a US nexus.

Args: country_code: ISO 3166-1 alpha-2 country code (e.g. "RU", "CN", "DE"). jurisdiction: Optional filter by jurisdiction (e.g. "US", "EU"). When omitted, returns restrictions from all jurisdictions.

Examples: country_export_controls("RU") # Russia — heavily embargoed country_export_controls("CN") # China — partial restrictions country_export_controls("DE") # Germany — minimal controls country_export_controls("RU", "US") # Russia, US jurisdiction only

Use case: 'What export restrictions apply to shipping to Russia?'

Input Schema

TableJSON Schema

Name	Required	Description	Default
`country_code`	Yes
`jurisdiction`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: returns restriction details across jurisdictions, highlights the jurisdiction nexus nuance and payment_jurisdiction_note. 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.

Conciseness5/5

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

Well-structured with purpose, important note, Args, Examples, Use case. Every sentence adds value. No redundancy.

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 complexity of export controls and presence of output schema, the description covers all aspects: parameters, usage caveats, examples, and context. No gaps.

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 description coverage is 0%, but description compensates by explaining country_code as ISO 3166-1 alpha-2 and jurisdiction as optional filter with default behavior. Examples clarify usage. Could mention jurisdiction allowed values explicitly.

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?

Description clearly states it looks up export control restrictions for a specific country, listing specific outputs (embargo status, sanctioned programs, etc.). Distinguished from sibling tools like sanctions_screen or export_controls_screen by focusing on country-level controls.

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?

Provides explicit guidance on when to use the jurisdiction filter and a critical note about binding jurisdiction. Includes examples and a use case. Could explicitly mention alternative tools for individual/entity screening but overall clear.

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

All banking-intelligence tools Inspect

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.3/5.0

Disambiguation4/5

Most tools have distinct purposes, but some overlapping areas (goods_classify vs hs_code_lookup vs eccn_lookup; fx_rate vs fx_rate_history vs fx_volatility) require close reading of descriptions to select correctly. The detailed descriptions help, but the shear number of lookup tools creates mild ambiguity.

Naming Consistency3/5

Names mix verb-first (track_payment, mcp_verify) and noun-first patterns (iban_validate, fx_rate, ssi_lookup), with some phrase-like names (banks_using_correspondent, is_business_day_check). While readable, there is no single consistent convention.

Tool Count3/5

33 tools is heavy, but the server's broad scope (payments, FX, sanctions, export controls, company registries, SWIFT) justifies most of them. A few marginal tools (mcp_register, mcp_verify, company_search_result) add bulk without core value.

Completeness5/5

The tool set covers the payment lifecycle end-to-end: tracking, settlement, FX, compliance, sanctions, and company due diligence. There are no obvious dead ends; the tools chain together via next_steps and search_id flows.

Resources

Need Help?