Skip to main content
Glama
mambalabsdev

Public Company Reporting Window Finder

Resolve Company

resolve_company
Idempotent

Resolve a domain, ticker, ISIN, LEI, CIK, or company name to a listed company identity, returning legal name, exchange, country, sector, and provenance.

Instructions

Resolve a domain, ticker, ISIN, LEI, CIK or company name to a listed company identity. Returns 44 fields per input: legal name, primary ticker, ISIN, LEI, CIK, domain, primary exchange, country, currency, sector, security type, public float band, shares outstanding, and the provenance of each. Every input returns exactly one row, including the ones that match nothing, which come back with match_method set to no_match and every other field null. Read matched_on to see which identifier produced the row. Use this when you hold identifiers and need the listed identity behind them; use qualify_company for a yes or no on listed status, get_reporting_timing for dates, and build_company_universe when you hold filters rather than identifiers. The filter inputs (exchange_codes, country_codes, regions, sectors, and the rest) narrow which matched rows come back. Charged per company row returned, including a no_match row, because the lookup ran either way. Requires an APIFY_TOKEN and consumes Apify credits. Read only.

Input Schema

NameRequiredDescriptionDefault
ciksNoSEC Central Index Keys, with or without leading zeros.
leisNo20 character Legal Entity Identifiers.
isinsNo12 character ISINs.
regionsNoShorthand for a set of venues and countries: us, uk, eu. Widens an explicit exchange or country filter rather than replacing it.
sectorsNoSEC SIC descriptions, e.g. Pharmaceutical Preparations. Populated on roughly 65 percent of the publishable universe.
tickersNoExchange tickers, e.g. NWLG. Matched against the primary ticker and every venue listing.
cadencesNoquarterly, semiannual, annual, unknown.
company_namesNoLegal or trading names. Matched on a normalized name. Former names are not available: the alias table carries tickers and ISINs only.
country_codesNoISO 3166-1 alpha-2, e.g. US, GB, FR.
company_domainNoA single bare domain, e.g. stripe.com. The Clay column shape. Used by resolve, qualify and timing.
exchange_codesNoISO 10383 MICs. 18 venues are covered.
security_typesNoordinary_shares, depositary_receipt, preferred_shares.
company_domainsNoMany domains at once. Used by resolve, qualify and timing.
public_float_bandsNomicro, small, mid, large, mega, unknown. Size runs on public float because market capitalization is not populated anywhere in this dataset.
us_registrant_onlyNoKeep only companies carrying an SEC CIK.
exclude_share_alikeNoDrop rows derived from CC BY-SA sources, whose share alike condition may not suit a closed product.
exclude_blank_checksNoDrop pre deal SPACs. Separate from the operating company filter: a blank check shell is flagged as an operating company and passes every ordinary firmographic filter.
fiscal_year_end_monthsNoIntegers 1 to 12. Fiscal year end is effectively a United States field in this dataset.
foreign_private_issuerNoFilter on foreign private issuer status.
operating_companies_onlyNoDrop funds, trusts and other non operating entities. Sent as a string for Clay compatibility.
exclude_name_only_matchesNoDrop rows whose identity link rests on a name and country agreeing rather than on an identifier. Use this wherever a wrong identity link matters.
min_provenance_confidenceNoSet to high to exclude rows whose source terms were never read.
exclude_december_fiscal_year_endNoKeep only companies whose fiscal year ends in a month other than December, the accounts whose budget cycle is out of phase with a calendar quarter.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.2
    • removedInput schema / additionalProperties
      Removed value: -false
  2. First observedv1.0.0

TDQS

A4.2/5.0
Behavior2/5

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

The description adds genuinely valuable behavior beyond the annotations: per-row billing including no_match rows, an exactly-one-row guarantee, no_match semantics, and the APIFY_TOKEN requirement. However, it closes with 'Read only' while the annotation declares readOnlyHint: false, so the safety claim an agent would rely on is contradicted by the structured field. That conflict prevents a higher score despite the otherwise rich disclosure.

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?

Purpose is front-loaded in sentence one, followed by output shape, edge-case behavior, sibling routing, filter semantics, and pricing. Each sentence carries distinct information, but the block is long and could be tightened; nothing is filler, yet it is denser than it needs to be for a tool description.

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 23-parameter tool with no output schema and no required parameters, the description covers what an agent needs: input identifiers, the 44-field return shape, the no_match outcome, how to read provenance, filter behavior, auth requirements, and cost model. Nothing material is left for the agent to infer.

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% and the per-parameter descriptions are unusually strong, so the baseline is 3. The description still adds a real semantic not present in the schema: the filter inputs (exchange_codes, country_codes, regions, sectors, etc.) narrow which matched rows return rather than acting as selectors, and it explains how to interpret match_method/matched_on. That is meaningful added meaning over the schema.

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 first sentence gives a precise verb (resolve) plus the exact set of accepted identifier types (domain, ticker, ISIN, LEI, CIK, name) and the resource (a listed company identity). It is immediately distinguishable from qualify_company (yes/no listed status) and build_company_universe (filter-driven). No ambiguity about what comes back.

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?

Explicitly states the selecting condition ('when you hold identifiers and need the listed identity behind them') and then names three alternatives with their own conditions: qualify_company for a yes/no, get_reporting_timing for dates, build_company_universe for filters. This is textbook when-to-use/when-not-to-use routing.

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