Skip to main content
Glama

banking-intelligence

by ai.ohmyfin
OverviewDiscussionsAdmin

Company Registry Search: Person (Experimental)

company_search_person

EXPERIMENTAL — Search company registries for a person's directorships, officer roles, and shareholdings.

Searches worldwide company registries to find where a person holds director, officer, or shareholder positions. Every person and company 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. Use it for anyone connected to a company outside the national registries above.

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 person was never searched for — it is NOT evidence they hold no roles. Check jurisdictions_not_searched and coverage_warning in the response before you report an empty result to the user.

Examples: company_search_person("John Smith", jurisdictions=["UK", "NO"]) company_search_person("Jane Doe", jurisdictions=["DE"])

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesPerson name to search for.
api_keyNoYour Ohmyfin API key (prod-...). Optional here: it can be sent instead as a KEY header or an Authorization: Bearer header. What the tool requires of the key is in its description.
jurisdictionsYesRegistry codes to search, at least one (e.g. ["UK", "NO"]). "ALL" is not supported. The UK registry is "UK", not "GB"; "XX" is GLEIF LEI (global). company_registries() returns the live list.
include_inactive_rolesNoInclude resigned and ceased roles (default true).
include_sanctions_checkNoScreen every person and company found against sanctions lists (default true).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / api_key / description
      Added value: +"Your Ohmyfin API key (prod-...). Optional here: it can be sent instead as a KEY header or an Authorization: Bearer header. What the tool requires of the key is in its description."
    • addedInput schema / properties / include_inactive_roles / description
      Added value: +"Include resigned and ceased roles (default true)."
    • addedInput schema / properties / include_sanctions_check / description
      Added value: +"Screen every person and company found against sanctions lists (default true)."
    • addedInput schema / properties / jurisdictions / description
      Added value: +"Registry codes to search, at least one (e.g. [\"UK\", \"NO\"]). \"ALL\" is not supported. The UK registry is \"UK\", not \"GB\"; \"XX\" is GLEIF LEI (global). company_registries() returns the live list."
    • addedInput schema / properties / name / description
      Added value: +"Person name to search for."
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Adds substantial behavior beyond the annotations: automatic sanctions screening, the silent-drop failure mode, and the recommendation to inspect jurisdictions_not_searched and coverage_warning. However, the api_key schema explicitly defers key requirements to 'its description,' and the description never explains them, and nothing accounts for the non-readOnly/non-idempotent annotations on what is presented as a lookup.

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?

Front-loaded with the capability and the hard constraint, and the examples at the end are useful rather than filler. The inline jurisdiction list is long and somewhat duplicative given the pointer to company_registries(), but it is defensible as a stale-prone fallback.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-required-param search with an output schema, the description covers invocation constraints and the main failure mode well. The one real hole is API-key requirement detail, which the schema explicitly delegates to this description but it never provides.

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 baseline is 3, but the description supplies meaning the schema does not: the consequence of an unsupported code, the distinction between national registries and the global GLEIF entry, and the empty-result interpretation. The include_inactive_roles and include_sanctions_check defaults are only restated from the schema, not extended.

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?

States a specific verb and resource ('Search company registries for a person's directorships, officer roles, and shareholdings') and scopes it to person-level results, which clearly separates it from the sibling company_search_company. Nothing is left ambiguous about what is being found or whose roles are returned.

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?

Gives explicit usage constraints: at least one jurisdiction required, 'ALL' unsupported, the exact supported code list, the instruction to call company_registries() for a live list, and what XX/GLEIF is for. It also names the failure condition (off-list jurisdiction is silently dropped) and tells the agent not to treat that as a negative finding.

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

All banking-intelligence toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources