Geonames

Resolve Entity

resolve_entity

Read-onlyIdempotent

"What's the ticker for…" / "find the CIK for…" / "what's the LEI for…" / "what's the RxCUI for…" / "look up the ID for…" / "what is X's official identifier" / "who owns X" / "is X a subsidiary of Y" — resolve a user-spoken NAME to the canonical/official identifiers other tools require as input. Use FIRST whenever you have a name but need an ID. SUPPORTED TYPES: "company" (cross-source identity spine: 10-digit CIK + ticker + company_name from SEC EDGAR, legal-entity LEI from GLEIF with parent/ultimate-parent/children ownership when the LEI resolves, and security FIGI from OpenFIGI — by exact ticker map when a ticker is implied, and otherwise by name search, so NON-EQUITY instruments that never have a ticker (municipal and corporate bonds, notes, authority debt) DO resolve here; when a name matches more than one instrument it asserts nothing and returns figi_candidates to pick from, which is the correct answer to an issuer name that does not identify a single bond; every identifier is labelled with the source that established it, and an identifier that could NOT be resolved is stated explicitly under unresolved rather than omitted — accepts ticker, CIK, ISIN, or company name as input; an ISIN like "CH0038863350" resolves to the LEGAL ENTITY that issued the security via the GLEIF ISIN-to-LEI mapping, covering non-US issuers EDGAR cannot reach), "drug" (returns RxCUI + ingredient + brand from RxNorm + pipeworx://rxnorm/concept/{rxcui} citation; accepts brand or generic name). LEI/FIGI enrichment degrades gracefully — if GLEIF or OpenFIGI is unavailable, the EDGAR identifiers still return. Each call cascades through several lookup endpoints internally — using resolve_entity replaces 2-3 manual lookups.

Input Schema

TableJSON Schema

Name	Required	Description
`type`	Yes	Entity type: "company" or "drug".
`value`	Yes	For company: ticker (AAPL), CIK (0000320193), or name. For drug: brand or generic name (e.g., "ozempic", "metformin"). Pass the ENTITY NAME ONLY — for a bond that is the ISSUER exactly as printed ("NEW YORK ST DORM AUTH"), never the question's full noun phrase ("NEW YORK ST DORM AUTH revenue bonds"): the FIGI lookup matches instrument names, so trailing security-class words match nothing.
`country`	No	OPTIONAL ISO 3166-1 alpha-2 of the country whose business register you mean ("NO", "FI", "JP", "GB", "FR", "EE", "BR"). Narrows the national-register fan-out and is often the difference between the right company and a US namesake — "Apple" with country "NO" is a Norwegian company, not Apple Inc. Omitting it searches every register we can name, which is the right default when you do not know. company only; ignored for drug.

Output Schema

TableJSON Schema

Name	Required	Description
`ids`	Yes	Every identifier established: cik, ticker, company_name, lei, figi, isin, cusip, register_id, register_country. A key absent here appears in `unresolved` with a reason — never silently dropped.
`type`	Yes
`brand`	No
`notes`	No
`query`	Yes
`related`	No	Entities that collapsed INTO the match, each carrying `collapsed_by`.
`sources`	Yes	Per-identifier provenance. Every key in `ids` has a matching key here.
`resolved`	Yes	At least one identifier was established. Read `match_status` and `unresolved` for WHICH — a company can be resolved in a national register with no CIK at all.
`searched`	No	EVERY register asked, with its own as-of date and row count. A register that could not be reached carries `error` — 0 rows with an error is "we could not ask", 0 rows without one is "nothing is there", and they are different answers.
`registers`	No	The matched entity as every register that carries it — the match (flagged `matched: true`) plus anything that collapsed into it. A Companies House number AND the LEI that crosswalks to it are the SAME answer, not rivals.
`resources`	No
`candidates`	No	Rivals, best first. Populated on "ambiguous" and on "matched" alike.
`ingredient`	No
`unresolved`	Yes	Per-identifier reason an id could NOT be established — the honest twin of `ids`.
`cik_withheld`	No	A CIK that came back from a FUZZY SEC name match and is NOT asserted, because the spine matched a stronger non-US candidate. The number is here so a caller who wanted the US filer can still use it; what changed is that we no longer claim it IS the answer. See `unresolved.cik` for the reason.
`match_status`	No	The headline to branch on. "ambiguous" is an ANSWER, not a failure: two companies matched the name equally well and both are in `candidates`. "no_match" means every register in `searched` was asked and none carried it. "incomplete" means one of them could NOT be asked (it carries an `error` in `searched[]`), so the candidate set is short by an unknown amount and no id is asserted — distinct from "ambiguous" because a RETRY is what resolves it, not a narrower query; `fanout_incomplete` names the unreachable registers and carries, under `withheld_match`, the candidate that would have been returned on a complete fan-out.
`figi_withheld`	No	A FIGI that matched this name in OpenFIGI (`figi_match: "name_search"`) and is NOT asserted, because `match_status` is "incomplete": a name search cannot tell a company apart from a security carrying its name, and the registers that would have settled it are the ones we could not ask. A `ticker_map` FIGI is never withheld this way — it is corroborated by the resolved ticker it came from. Carried so a caller who accepts the caveat can use it; see `unresolved.figi`, and retry, since a transiently rate-limited register completes on the next call.
`match_scoring`	No	The margin rule's own inputs, so a caller can see WHY it fell where it did.
`sec_alternatives`	No	EDGAR's own discarded near-misses on a name match, surfaced instead of dropped.
`fanout_incomplete`	No	Present IFF at least one register in `searched[]` carried an `error` — set even when `match_status` stayed "ambiguous". `withheld_match` is the candidate this call declined to ASSERT because a register was missing, carried rather than discarded so a caller who accepts the caveat can still use it.
`match_explanation`	No	Plain words. Always present when the spine ran, and required on "ambiguous" and "no_match".

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 1, 2026

addedInput schema / examples

Added value: +[
+  {
+    "type": "company",
+    "value": "AAPL"
+  }
+]

Changed1 schema field changedSep 1, 2026

changedInput schema / properties / value / description

Previous value: -"For company: ticker (AAPL), CIK (0000320193), or name. For drug: brand or generic name (e.g., \"ozempic\", \"metformin\")."New value: +"For company: ticker (AAPL), CIK (0000320193), or name. For drug: brand or generic name (e.g., \"ozempic\", \"metformin\"). Pass the ENTITY NAME ONLY — for a bond that is the ISSUER exactly as printed (\"NEW YORK ST DORM AUTH\"), never the question's full noun phrase (\"NEW YORK ST DORM AUTH revenue bonds\"): the FIGI lookup matches instrument names, so trailing security-class words match nothing."

First observedJun 26, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With readOnly/openWorld/idempotent annotations already covering the safety profile, the description still adds real behavioral context: graceful degradation when GLEIF or OpenFIGI is unavailable, that unresolved identifiers are surfaced under `unresolved` rather than omitted, that ambiguous instrument names assert nothing and return `figi_candidates`, and that each call cascades through several endpoints. It doesn't discuss latency/rate limits, but the additions are substantive.

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

Conciseness3/5

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

Most content earns its place for a genuinely complex multi-source tool, but the presentation is a wall of nested parentheticals that is hard to parse, and the critical routing rule ('Use FIRST') is buried after eight example questions. Front-loading the purpose and constraints would markedly improve scannability.

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 tool that cascades across EDGAR, GLEIF, OpenFIGI and RxNorm, the description covers supported entity types, identifier sources, ambiguity handling, degradation, and the optional country narrowing. Output schema exists, so return values need not be re-explained.

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 already 100%, but the description goes beyond it: it adds ISIN ('CH0038863350') as a valid company input, which the schema omits, and clarifies the semantic split between the 'company' and 'drug' types. These additions measurably exceed the baseline 3 for fully documented schemas.

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 names a precise verb+resource — resolve a user-spoken NAME to canonical/official identifiers that other tools require as input — and enumerates the concrete identifier types (CIK, ticker, LEI, FIGI, RxCUI). An agent can tell it apart from lookups like company_facts or entity_profile without opening a schema, and the example phrasings anchor the intent.

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?

It gives a strong routing rule — 'Use FIRST whenever you have a name but need an ID' — plus the question patterns that should trigger it and notes that it replaces 2-3 manual lookups. It does not explicitly name an alternative sibling or state when not to use it, so it falls short of the 5 bar.

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

All Geonames tools Inspect

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.