banking-intelligence

company_search_company

EXPERIMENTAL — Search company registries for a company with its officers and shareholders.

Find company registrations across worldwide registries, including directors, officers, and beneficial owners (PSC/shareholders). Every entity found is automatically screened against sanctions lists.

You MUST specify at least one jurisdiction. "ALL" is not supported. Available jurisdictions: AM, AT, AU, BR, CA, CH, CZ, DE, DK, EE, FI, FR, IE, IL, IS, LT, LV, NL, NO, PL, SG, UK, XX. Call company_registries() for the live list — this one can go stale.

XX is GLEIF LEI, a GLOBAL registry rather than a country. Reach for it whenever the company sits outside the national registries above — a supplier in Hong Kong, mainland China, the US or the UAE. Hits carry an LEI, a registered address and a search.gleif.org URL the user can open.

A jurisdiction NOT on that list is dropped silently by the backend: you get total_results 0 with status "completed" and no error. That means the company was never searched for — it is NOT evidence that it is unregistered or fake, and saying so to someone checking a counterparty before wiring money is the most damaging thing this tool can do. Check jurisdictions_not_searched and coverage_warning in the response before you report an empty result.

Args: name: Company name to search for. jurisdictions: Country codes to search (required, e.g. ["UK"]). "ALL" is not supported — specify individual countries. include_sanctions_check: Auto-screen results against sanctions DB (default: true). include_officers: Include directors and officers (default: true). include_shareholders: Include PSC/beneficial owners (default: true). include_only_active: Filter to active companies only (default: false). api_key: Your Ohmyfin API key (prod-...). Can also be passed via KEY header or Authorization: Bearer header.

Examples: company_search_company("Equinor", jurisdictions=["NO"]) company_search_company("Acme Corp", jurisdictions=["UK", "DE"], include_only_active=True)

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes
`api_key`	No
`jurisdictions`	Yes
`include_officers`	No
`include_only_active`	No
`include_shareholders`	No
`include_sanctions_check`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations, the description thoroughly discloses behavior: it is marked EXPERIMENTAL, auto-screens against sanctions, and explains the silent-drop behavior with total_results 0 and status 'completed' when a jurisdiction is not on the list. It also clarifies the meaning of an empty result and tells the user to check `jurisdictions_not_searched` and `coverage_warning`, adding significant behavioral insight.

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

Conciseness4/5

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

The description is long but well-structured with clear sections (overview, jurisdiction constraints, warning, args, examples). The opening sentence and the following sentence are somewhat repetitive ('Search company registries' vs 'Find company registrations'), but the extra detail about beneficial owners and sanctions screening justifies the length. It is mostly front-loaded and each paragraph serves a distinct purpose.

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?

For a complex 7-parameter tool without annotations, the description covers: jurisdiction list and limitations, exception for XX (GLEIF LEI), silent failure semantics, sanctions screening, all parameter semantics, API key alternatives, and examples. Return values are covered by the output schema, so the description is complete for selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides zero descriptions for all 7 parameters, but the description's Args section explains every parameter, including types, defaults, and constraints. For example, it clarifies that jurisdictions must be specified individually, "ALL" is not supported, and provides meaning for include_officers, include_shareholders, etc., fully compensating for the schema's lack of detail.

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 'Search company registries for a company with its officers and shareholders' — a specific verb plus clear resource. It further clarifies 'Find company registrations across worldwide registries, including directors, officers, and beneficial owners (PSC/shareholders)', which clearly distinguishes it from siblings like company_search_person and company_registries.

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?

Provides explicit usage conditions: 'You MUST specify at least one jurisdiction. "ALL" is not supported', directs to 'Call company_registries() for the live list — this one can go stale', and offers specific guidance for the XX registry ('Reach for it whenever the company sits outside the national registries above'). It also warns about silent jurisdiction drops, which is critical usage context.

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?