Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Public Company Reporting Window Finder when does Apple report earnings and what's the outreach window?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for the Mamba Labs Public Company Earnings Dates and Reporting Window Finder actor on Apify.
Give it a domain, ticker, ISIN, LEI or CIK and it tells you when that public company reports, and when to reach out around it: fiscal year end, reporting cadence, the next reporting date, days to event, and the open and close of an outreach window you define.
Timing rows cover US companies only. Identity, venue and classification resolve worldwide across the publishable universe. Reporting dates come from US SEC filing history and exist for US companies alone. A non US company resolves fully and returns a stated
timing_unavailable_reasonrather than a guessed date, and is still charged as a timing row because the lookup ran.
Tool | Takes | Returns |
| identifiers | identity and venue, 44 fields |
| identifiers | a listed status verdict |
| identifiers | fiscal year end, cadence, next event, the outreach window, 75 fields |
| filters | a company list |
| filters | reporting load per week or month |
You never pass mode. Each tool sets it, and each tool exposes only the inputs its mode actually uses.
build_company_universe and get_reporting_season build a list from filters and do not accept company identifiers. Set limit explicitly on both: it defaults to 1000 and you are charged per row returned.
Related MCP server: SEC EDGAR MCP Server
{
"mcpServers": {
"mamba-public-company-reporting-window-finder": {
"command": "npx",
"args": ["-y", "@mambalabsdev/mcp-public-company-reporting-window-finder"],
"env": { "APIFY_TOKEN": "your-apify-token" }
}
}
}Get a token at console.apify.com/account/integrations.
Dates are predicted, not announced. next_event_is_estimate is true for a date derived from filing history. confidence_band sits at 0.80 and 0.50, computed on the weakest link in the chain, so confidence_effective is the minimum of the event and cadence confidences rather than an average.
window_status is the field to filter on. It is open, not_yet, closed_passed or no_event against today. no_event is the state a company lands in when there is no reporting event to build a window from.
Unknown cadence is refused, not guessed. A company whose filing history is too short or irregular returns a null cadence with a reason instead of an invented date.
A row that resolves nothing is still billed. An identifier that matches no public company returns match_method of no_match with every other field null. That is a real answer and the lookup ran to produce it.
Pay per event on Apify, charged for rows returned rather than rows filtered out.
Event | Price |
Company resolved | $0.006 per row |
Timing row returned | $0.012 per row |
Reporting season aggregate | $0.05 per row |
Actor start | $0.00005 per run |
Volume discounts of 5, 10 and 15 percent apply on the Apify Bronze, Silver and Gold plans. A timing row is never additionally charged as a resolved company.
Browse the full suite on Apify.
MIT
Build a list of listed companies from filters rather than from identifiers you already hold. Filter by exchange, country, region, sector, security type, public float band, fiscal year end month, reporting cadence, operating status and foreign private issuer status. Returns 44 fields per company, the same shape resolve_company returns. At least one filter is required, so a bare call cannot pull the whole universe. This tool does NOT accept company identifiers: use resolve_company, qualify_company or get_reporting_timing for specific companies. SET limit EXPLICITLY. It defaults to 1000 and you are charged per company row returned, so an unbounded call is an expensive call. Truncation is always reported, never silent. Requires an APIFY_TOKEN and consumes Apify credits. Read only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum rows for universe and season. Truncation is always reported, never silent. | |
| regions | No | Shorthand for a set of venues and countries: us, uk, eu. Widens an explicit exchange or country filter rather than replacing it. | |
| sectors | No | SEC SIC descriptions, e.g. Pharmaceutical Preparations. Populated on roughly 65 percent of the publishable universe. | |
| cadences | No | quarterly, semiannual, annual, unknown. | |
| country_codes | No | ISO 3166-1 alpha-2, e.g. US, GB, FR. | |
| exchange_codes | No | ISO 10383 MICs. 18 venues are covered. | |
| security_types | No | ordinary_shares, depositary_receipt, preferred_shares. | |
| public_float_bands | No | micro, small, mid, large, mega, unknown. Size runs on public float because market capitalization is not populated anywhere in this dataset. | |
| us_registrant_only | No | Keep only companies carrying an SEC CIK. | |
| exclude_share_alike | No | Drop rows derived from CC BY-SA sources, whose share alike condition may not suit a closed product. | |
| exclude_blank_checks | No | Drop 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_months | No | Integers 1 to 12. Fiscal year end is effectively a United States field in this dataset. | |
| foreign_private_issuer | No | Filter on foreign private issuer status. | |
| operating_companies_only | No | Drop funds, trusts and other non operating entities. Sent as a string for Clay compatibility. | |
| exclude_name_only_matches | No | Drop 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_confidence | No | Set to high to exclude rows whose source terms were never read. | |
| exclude_december_fiscal_year_end | No | Keep 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations (which already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint). It discloses: minimum one filter required, default limit of 1000 rows, per-row charging, truncation reporting behavior (never silent), APIFY_TOKEN requirement, and Apify credit consumption. This fully characterizes operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the key purpose, followed by essential usage constraints and behavioral details. Every sentence adds distinct value—no fluff or repetition. It efficiently covers purpose, alternatives, cost implications, and special notes in under 150 words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the high parameter count (17) and no output schema, the description is remarkably complete. It notes the output structure (44 fields, same shape as resolve_company), explains truncation reporting, and covers all key behavioral constraints. The annotations further support completeness by indicating idempotent and read-only behavior. No obvious gaps remain for an agent to fail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema description coverage is 100%, the description adds substantial context beyond the schema. For example, it states that regions widen rather than replace filters, public_float_bands are based on public float because market cap is unavailable, fiscal_year_end_months is primarily a US field, and security_types are specifically enum values. These enrichments justify a top score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a list of listed companies using filters, not identifiers. It uses a specific verb ('Build') and resource ('list of listed companies'), and explicitly distinguishes from sibling tools by noting it does not accept company identifiers and directing users to resolve_company, qualify_company, or get_reporting_timing for specific companies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (filter-based universe building) and when not to (company identifier lookups). It names alternative tools (resolve_company, qualify_company, get_reporting_timing) and includes a critical usage warning about setting the limit explicitly to control costs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show how reporting load is distributed over time, so you can find the busy weeks and the quiet ones. Returns aggregate rows per bucket, not per company: period start and end, event count, company count, estimated share and mean confidence. Bucket by week or month with season_group_by, and optionally split by sector, country or exchange with season_split_by. The window defaults to today through 180 days out; set season_from and season_to for another. At least one filter is required and company identifiers are not accepted. Charged per aggregate row returned, which is far fewer rows than the companies behind them. Requires an APIFY_TOKEN and consumes Apify credits. Read only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum rows for universe and season. Truncation is always reported, never silent. | |
| regions | No | Shorthand for a set of venues and countries: us, uk, eu. Widens an explicit exchange or country filter rather than replacing it. | |
| sectors | No | SEC SIC descriptions, e.g. Pharmaceutical Preparations. Populated on roughly 65 percent of the publishable universe. | |
| cadences | No | quarterly, semiannual, annual, unknown. | |
| season_to | No | season mode. ISO date. Defaults to 180 days from today. | |
| event_types | No | full_year_results, half_year_results, quarterly_results, trading_update, annual_report_publication, sustainability_report_publication, agm, proxy_filing, capital_markets_day. | |
| season_from | No | season mode. ISO date. Defaults to today. | |
| country_codes | No | ISO 3166-1 alpha-2, e.g. US, GB, FR. | |
| exchange_codes | No | ISO 10383 MICs. 18 venues are covered. | |
| security_types | No | ordinary_shares, depositary_receipt, preferred_shares. | |
| season_group_by | No | season mode. Bucket size. | |
| season_split_by | No | season mode. Optional second dimension. | |
| public_float_bands | No | micro, small, mid, large, mega, unknown. Size runs on public float because market capitalization is not populated anywhere in this dataset. | |
| us_registrant_only | No | Keep only companies carrying an SEC CIK. | |
| exclude_share_alike | No | Drop rows derived from CC BY-SA sources, whose share alike condition may not suit a closed product. | |
| exclude_blank_checks | No | Drop 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_months | No | Integers 1 to 12. Fiscal year end is effectively a United States field in this dataset. | |
| foreign_private_issuer | No | Filter on foreign private issuer status. | |
| operating_companies_only | No | Drop funds, trusts and other non operating entities. Sent as a string for Clay compatibility. | |
| exclude_name_only_matches | No | Drop 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_confidence | No | Set to high to exclude rows whose source terms were never read. | |
| exclude_december_fiscal_year_end | No | Keep 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and non-destructive hint. The description adds valuable context: charging model (per aggregate row), authentication requirements (APIFY_TOKEN, Apify credits), and data source restrictions (CC BY-SA exclusion, blank check handling). This goes beyond annotations with concrete behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is comprehensive at ~150 words without being verbose. It front-loads the main purpose and return structure, then explains parameters, then pricing, then auth. Some redundancy exists (e.g., 'Read only' at end repeats annotations), but overall well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 22 parameters, 100% schema coverage, and no output schema, the description adequately explains how to use the tool for its main purpose (bucketed reporting season analysis). It covers filter constraints, pricing, authentication, and data limitations. However, it does not describe return format or pagination (though 'Truncation is always reported' is hinted in limit description).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value for key parameters (season_group_by, season_split_by) by explaining their role in bucketing and splitting, and notes default windows. However, many parameters have clear schema descriptions already (e.g., regions, sectors), and the tool's narrative does not significantly augment them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to show reporting load distribution over time, distinguishing it from siblings like get_reporting_timing which likely focuses on individual company timing. It specifies returns aggregate rows per bucket, not per company, which aligns with readOnlyHint and openWorldHint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that at least one filter is required and company identifiers are not accepted, providing basic usage guidance. However, it lacks explicit when-to-use vs alternatives: for example, when to use get_reporting_season vs build_company_universe for bulk data needs. No exclusion criteria or prerequisite context beyond the required filter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find when a public company next reports, and when to reach out around it. Returns 75 fields per input: fiscal year end, derived reporting cadence and its confidence, the next reporting event with its type, period and date, days to event, and the open and close of an outreach window you define with window_lead_days and window_lag_days, which default to 70 and 42. window_status is one of open, not_yet, closed_passed or no_event and is the field to filter on. Dates are PREDICTED from filing history, not announced: read next_event_is_estimate and confidence_band, whose thresholds sit at 0.80 and 0.50. TIMING ROWS COVER US COMPANIES ONLY. A non US company resolves fully for identity and returns a stated timing_unavailable_reason rather than a guessed date, and is still charged as a timing row because the work ran. Charged per timing row returned, never additionally as a resolved company. Requires an APIFY_TOKEN and consumes Apify credits. Read only.
| Name | Required | Description | Default |
|---|---|---|---|
| ciks | No | SEC Central Index Keys, with or without leading zeros. | |
| leis | No | 20 character Legal Entity Identifiers. | |
| isins | No | 12 character ISINs. | |
| regions | No | Shorthand for a set of venues and countries: us, uk, eu. Widens an explicit exchange or country filter rather than replacing it. | |
| sectors | No | SEC SIC descriptions, e.g. Pharmaceutical Preparations. Populated on roughly 65 percent of the publishable universe. | |
| tickers | No | Exchange tickers, e.g. NWLG. Matched against the primary ticker and every venue listing. | |
| cadences | No | quarterly, semiannual, annual, unknown. | |
| event_types | No | full_year_results, half_year_results, quarterly_results, trading_update, annual_report_publication, sustainability_report_publication, agm, proxy_filing, capital_markets_day. | |
| company_names | No | Legal or trading names. Matched on a normalized name. Former names are not available: the alias table carries tickers and ISINs only. | |
| country_codes | No | ISO 3166-1 alpha-2, e.g. US, GB, FR. | |
| company_domain | No | A single bare domain, e.g. stripe.com. The Clay column shape. Used by resolve, qualify and timing. | |
| exchange_codes | No | ISO 10383 MICs. 18 venues are covered. | |
| security_types | No | ordinary_shares, depositary_receipt, preferred_shares. | |
| company_domains | No | Many domains at once. Used by resolve, qualify and timing. | |
| window_lag_days | No | How many days before the event the outreach window closes. Default 42. Must be less than the lead. | |
| window_statuses | No | Keep only rows in these window states: open, not_yet, closed_passed, no_event. | |
| window_lead_days | No | How many days before the event the outreach window opens. Default 70. | |
| max_days_to_event | No | Drop rows whose next event is further away than this. A cost control. | |
| public_float_bands | No | micro, small, mid, large, mega, unknown. Size runs on public float because market capitalization is not populated anywhere in this dataset. | |
| us_registrant_only | No | Keep only companies carrying an SEC CIK. | |
| exclude_share_alike | No | Drop rows derived from CC BY-SA sources, whose share alike condition may not suit a closed product. | |
| exclude_blank_checks | No | Drop 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_months | No | Integers 1 to 12. Fiscal year end is effectively a United States field in this dataset. | |
| foreign_private_issuer | No | Filter on foreign private issuer status. | |
| min_cadence_confidence | No | 0 to 1. Rows whose cadence confidence falls below this return a null timing block with a stated reason rather than a guess. Quarterly cadence averages 0.94, annual 0.40, semiannual 0.21. | |
| operating_companies_only | No | Drop funds, trusts and other non operating entities. Sent as a string for Clay compatibility. | |
| exclude_name_only_matches | No | Drop 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_confidence | No | Set to high to exclude rows whose source terms were never read. | |
| include_constrained_period | No | Emit the period in which a listed company is constrained in what it can announce, derived from the same window numbers. Useful for campaign and announcement timing. | |
| exclude_december_fiscal_year_end | No | Keep 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description richly supplements the readOnlyHint/idempotentHint annotations by explaining that dates are predicted, confidence thresholds, non-US resolution behavior, per-row charging, APIFY_TOKEN requirement, and consumption of credits. It adds substantial behavioral context without contradicting any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but organized around the purpose, output fields, limitations, and cost. Almost every sentence adds information, though the final 'Read only' is redundant with the readOnlyHint annotation, and the all-caps emphasis is unnecessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 30-parameter tool with no output schema, the description covers the essential output fields, predicted-date caveats, US-only scope, non-US fallback, and pricing. It does not enumerate all 75 output fields, but it names the most important ones and gives enough context for an agent to invoke and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds value beyond the schema by giving defaults for window_lead_days/window_lag_days, enumerating window_status values, and explaining confidence thresholds, which helps select key parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds when a public company next reports and an outreach window around that event, with a specific verb and resource. However, it does not explicitly differentiate from the sibling get_reporting_season, so the distinction is implicit rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: US-only coverage, non-US behavior and charging, and points at window_status as the field to filter on. It does not explicitly say when to prefer this over resolve_company, qualify_company, or get_reporting_season, but the described use case is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answer whether a company is publicly listed. Takes the same identifiers as resolve_company and returns a listed status verdict per input. Set listed_only to keep only the companies proven to be listed, or suppress_listed to remove them, which is what you want when selling only into private companies. By default an unmatched company returns is_listed null rather than false, because a non match may mean the company is private OR that the dataset does not hold its domain; set assume_unmatched_is_private to true to opt into reading a non match as private. Charged per company row returned. Requires an APIFY_TOKEN and consumes Apify credits. Read only.
| Name | Required | Description | Default |
|---|---|---|---|
| ciks | No | SEC Central Index Keys, with or without leading zeros. | |
| leis | No | 20 character Legal Entity Identifiers. | |
| isins | No | 12 character ISINs. | |
| regions | No | Shorthand for a set of venues and countries: us, uk, eu. Widens an explicit exchange or country filter rather than replacing it. | |
| sectors | No | SEC SIC descriptions, e.g. Pharmaceutical Preparations. Populated on roughly 65 percent of the publishable universe. | |
| tickers | No | Exchange tickers, e.g. NWLG. Matched against the primary ticker and every venue listing. | |
| cadences | No | quarterly, semiannual, annual, unknown. | |
| listed_only | No | qualify mode. Keep only rows proven to be publicly listed. | |
| company_names | No | Legal or trading names. Matched on a normalized name. Former names are not available: the alias table carries tickers and ISINs only. | |
| country_codes | No | ISO 3166-1 alpha-2, e.g. US, GB, FR. | |
| company_domain | No | A single bare domain, e.g. stripe.com. The Clay column shape. Used by resolve, qualify and timing. | |
| exchange_codes | No | ISO 10383 MICs. 18 venues are covered. | |
| security_types | No | ordinary_shares, depositary_receipt, preferred_shares. | |
| company_domains | No | Many domains at once. Used by resolve, qualify and timing. | |
| suppress_listed | No | qualify mode. Remove companies proven to be publicly listed, for anyone selling only into private companies. It removes what we can prove is listed; it does not warrant that the remainder is private. | |
| public_float_bands | No | micro, small, mid, large, mega, unknown. Size runs on public float because market capitalization is not populated anywhere in this dataset. | |
| us_registrant_only | No | Keep only companies carrying an SEC CIK. | |
| exclude_share_alike | No | Drop rows derived from CC BY-SA sources, whose share alike condition may not suit a closed product. | |
| exclude_blank_checks | No | Drop 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_months | No | Integers 1 to 12. Fiscal year end is effectively a United States field in this dataset. | |
| foreign_private_issuer | No | Filter on foreign private issuer status. | |
| operating_companies_only | No | Drop funds, trusts and other non operating entities. Sent as a string for Clay compatibility. | |
| exclude_name_only_matches | No | Drop 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_confidence | No | Set to high to exclude rows whose source terms were never read. | |
| assume_unmatched_is_private | No | qualify mode. By default an unmatched company returns is_listed null, because a non match may mean the company is private OR that we do not hold its domain. Set true to opt into reading a non match as private, which sets is_listed false. | |
| exclude_december_fiscal_year_end | No | Keep 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond the annotations: the default null vs false for unmatched companies, the opt-in behavior with assume_unmatched_is_private, the cost model ('Charged per company row returned'), and authentication requirements ('Requires an APIFY_TOKEN'). The annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, and the description adds valuable context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and uses five sentences to cover purpose, identifiers, mode parameters, unmatched behavior, and cost/auth. Every sentence is informative and earns its place. Given the tool's complexity (26 parameters), this is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool having 26 parameters, the description only explains the three mode parameters and the unmatched behavior. The role of the other 23 parameters (sectors, regions, exchange_codes, etc.) is not mentioned. The description does not clarify how these filter parameters relate to the 'qualify' action, leaving a significant gap in context for an agent. No output schema is provided, and the description only vaguely mentions 'returns a listed status verdict per input' without specifying the return shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaning by explaining the three 'qualify mode' parameters (listed_only, suppress_listed, assume_unmatched_is_private) in the context of the tool's objective, and clarifies the default behavior for unmatched inputs. This provides extra guidance beyond the individual parameter descriptions in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Answer whether a company is publicly listed.' which is a specific verb+resource. It distinguishes from the sibling 'resolve_company' by stating it returns a 'listed status verdict' and uses the same identifiers. This clearly conveys the unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the listed_only and suppress_listed modes ('when selling only into private companies'), and explains the default behavior of unmatched companies. It references the sibling resolve_company for identifiers, giving context for usage. However, it does not explicitly state when not to use this tool or compare to other siblings, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| ciks | No | SEC Central Index Keys, with or without leading zeros. | |
| leis | No | 20 character Legal Entity Identifiers. | |
| isins | No | 12 character ISINs. | |
| regions | No | Shorthand for a set of venues and countries: us, uk, eu. Widens an explicit exchange or country filter rather than replacing it. | |
| sectors | No | SEC SIC descriptions, e.g. Pharmaceutical Preparations. Populated on roughly 65 percent of the publishable universe. | |
| tickers | No | Exchange tickers, e.g. NWLG. Matched against the primary ticker and every venue listing. | |
| cadences | No | quarterly, semiannual, annual, unknown. | |
| company_names | No | Legal or trading names. Matched on a normalized name. Former names are not available: the alias table carries tickers and ISINs only. | |
| country_codes | No | ISO 3166-1 alpha-2, e.g. US, GB, FR. | |
| company_domain | No | A single bare domain, e.g. stripe.com. The Clay column shape. Used by resolve, qualify and timing. | |
| exchange_codes | No | ISO 10383 MICs. 18 venues are covered. | |
| security_types | No | ordinary_shares, depositary_receipt, preferred_shares. | |
| company_domains | No | Many domains at once. Used by resolve, qualify and timing. | |
| public_float_bands | No | micro, small, mid, large, mega, unknown. Size runs on public float because market capitalization is not populated anywhere in this dataset. | |
| us_registrant_only | No | Keep only companies carrying an SEC CIK. | |
| exclude_share_alike | No | Drop rows derived from CC BY-SA sources, whose share alike condition may not suit a closed product. | |
| exclude_blank_checks | No | Drop 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_months | No | Integers 1 to 12. Fiscal year end is effectively a United States field in this dataset. | |
| foreign_private_issuer | No | Filter on foreign private issuer status. | |
| operating_companies_only | No | Drop funds, trusts and other non operating entities. Sent as a string for Clay compatibility. | |
| exclude_name_only_matches | No | Drop 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_confidence | No | Set to high to exclude rows whose source terms were never read. | |
| exclude_december_fiscal_year_end | No | Keep 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: charging per row (including no_match), Apify token/credit consumption, match_method and matched_on fields, and limitations (former names not available). It also explicitly states 'Read only' aligning with readOnlyHint. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about six sentences, front-loading purpose and return fields. It includes important details (charging, no_match rows) without being overly verbose. Minor redundancy: 'Read only' is stated despite annotation, but it's acceptable. Efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (23 parameters, no output schema), the description covers essential aspects: what identifiers are accepted, return format (44 fields including match_method), behavior on no-match, charging model, and prerequisites (APIFY_TOKEN). It compensates well for the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description does not add new parameter-level information beyond what the schema provides, except for high-level context about what the tool resolves. Hence baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves identifiers (domain, ticker, ISIN, LEI, CIK, company name) to a listed company identity, listing many returned fields. It is specific about the verb and resource, and the name 'resolve_company' aligns well. While it doesn't explicitly differentiate from siblings like 'qualify_company', the distinct purpose is obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not mention when to use this tool versus its siblings (qualify_company, get_reporting_timing, etc.). It provides context on charging and behavior (e.g., always returns one row) but lacks guidance on selecting alternatives or excluding certain use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0build_company_universeget_reporting_seasonget_reporting_timingqualify_companyresolve_companyEach tool has a clearly distinct purpose: resolve_company handles identity resolution, qualify_company returns listed status, get_reporting_timing provides next reporting dates, build_company_universe creates filtered lists, and get_reporting_season offers aggregate load. No overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (resolve_company, qualify_company, get_reporting_timing, build_company_universe, get_reporting_season), making them predictable and easy to parse.
With 5 tools, the server is well-scoped. It covers identity resolution, qualification, timing, universe building, and season overview without unnecessary bloat or gaps.
The tool set covers the full lifecycle for the stated domain: resolving companies, checking listed status, getting timing, building custom universes, and viewing aggregate seasons. No obvious missing operations for the purpose of finding reporting windows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Institutional-grade financial data: earnings, estimates, guidance, stock prices, macro indicators.
SEC filings, earnings transcripts, guidance signals & macro calendar for S&P 500. 11 MCP tools.
SEC filing intelligence for AI agents. Financials, screening, peer comparison for 5,000+ companies.
SEC filings, insider trades, and earnings data
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mambalabsdev/mcp-public-company-reporting-window-finder'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
