signals
Server Details
Deduplicated, entity-resolved funding rounds, acquisitions, and exec moves as MCP tools.
- Status
- Healthy
- Uptime
- 99.9% over 65 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 13 tools
Most tools target distinct resources, but company_hiring vs hiring_signals and company_timeline vs the individual event lists (funding_events, acquisitions, exec_moves, hiring_signals) have genuinely blurry boundaries since the timeline aggregates the same data. Descriptions help differentiate ('current snapshot' vs 'list of signals'), but an agent could still misselect between the per-company and the list-oriented tools.
Two clear families exist: bare plural/entity nouns (acquisitions, companies, exec_moves, funding_events, investors) and verb_noun watchlist operations (create_watchlist, add_to_watchlist, get_watchlist, list_watchlists, remove_from_watchlist). The watchlist group is perfectly consistent, but the data-retrieval group drops the verb entirely and mixes in odd compounds like company_hiring and company_timeline. Readable but not a single predictable convention.
13 tools for a company-intelligence server spanning six event types plus a five-tool watchlist CRUD set is well-scoped, with each tool earning its place. Slightly heavy on watchlist operations relative to data tools, but nothing is redundant.
Covers the core signals domain: company, investor, funding, M&A, exec move, and hiring surfaces plus watchlist create/read/add/remove. Minor gaps remain — no delete or rename watchlist, and no way to search people/contacts directly despite exec_moves referencing individuals — but agents can work around these.
Available Tools
13 toolsacquisitionsARead-onlyInspect
List acquisition and merger events ordered by announcement date, newest first. Filter by payment type, deal amount range, merger flag, or a company that is the acquirer or target. Costs one credit per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum records to return (1-100). Each returned record costs one credit. | |
| since | No | Return records announced on or after this date (YYYY-MM-DD) or ISO-8601 timestamp. | |
| until | No | Return records announced on or before this date (YYYY-MM-DD, inclusive) or ISO-8601 timestamp. | |
| cursor | No | Opaque pagination cursor returned as pagination.nextCursor on the previous page. | |
| domain | No | Company domain, e.g. stripe.com. Matches the company's primary domain or any domain it redirected from; a full URL works too. | |
| isMerger | No | Filter to mergers (true) or acquisitions (false). | |
| companyId | No | Return only events where this company is the acquirer or target. | |
| countries | No | Headquarters country codes (ISO alpha-2, OR). Pass "unknown" to include companies with no country on file. | |
| naicsCode | No | NAICS 2022 code for the target (acquired) company. Matches the code and everything beneath it, so "51" also returns 5132 and 5173. Sector ranges work: "31-33" returns all manufacturing. Any 2- to 6-digit code is accepted; codes deeper than we classify (e.g. 541511) match at their deepest classified parent (5415). | |
| verticals | No | Target company sector filters (OR). Canonical values: ai, fintech, saas, devtools, healthcare, climate, robotics, cybersecurity, logistics, commerce, data, crypto, media, education, marketing, telecom, realestate, hardware, gaming, space. | |
| paymentType | No | Payment type filters. Canonical values: cash, stock, mixed, undisclosed. | |
| includeTotal | No | Also return pagination.total, the number of records matching these filters across all pages. Costs no credits. | |
| maxAmountUsd | No | Maximum deal amount in USD. | |
| minAmountUsd | No | Minimum deal amount in USD. | |
| industryGroups | No | Company industry groups (OR). LinkedIn industry labels, matched case-insensitively; older LinkedIn names and short forms like "software" map to the current label. Pass "unknown" for companies with no industry on file. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation already declares readOnlyHint=true, so safety profile is covered. The description adds the essential cost model ('Costs one credit per returned record'), which is not in the annotations and materially affects how an agent should size page limits and use includeTotal.
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?
Two tight sentences: the first establishes resource, ordering, and filters; the second states the cost. Nothing wasted and the ordering constraint is front-loaded.
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 15-param list tool with full schema coverage and no output schema, the description covers purpose, ordering, filters, and the cost model. Minor gaps are pagination behavior (cursor/nextCursor) and there being no default limit mentioned, but the schema handles those.
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 carries full parameter meaning. The description only lists filter categories, adding no syntax, format, or default detail beyond the schema. Baseline 3 applies.
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?
States a specific verb (List), resource (acquisition and merger events), and the default ordering (announcement date, newest first). Distinguishes itself from siblings like funding_events and companies by scoping to M&A events.
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?
Implied usage is clear from filters listed ('Filter by payment type, deal amount range, merger flag, or a company that is the acquirer or target'), but no explicit when-to-use-vs-alternatives guidance and no exclusion conditions are stated. The sibling funding_events isn't referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
add_to_watchlistAInspect
Add companies (domain, name, LinkedIn URL, or id) to a watchlist. Returns a per-item result of added, already_present, or unresolved. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Watchlist id. | |
| companies | Yes | Company identifiers: domain, name, LinkedIn URL, or Datahyena id. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses meaningful behavior beyond the annotations: it returns a per-item result with states 'added', 'already_present', or 'unresolved', which conveys partial success semantics and idempotency-like behavior. Annotations only provide false hints, so this output detail adds significant value, though auth/permissions or mutation effects are not discussed.
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 two concise sentences: the first states the action and accepted inputs, the second explains the return format. Every sentence earns its place with no redundant filler.
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 tool's moderate complexity (2 required params, no output schema), the description covers the core behavior, accepted input forms, and the return result format. It is sufficient for an agent to select and invoke the tool correctly.
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 both parameters thoroughly. The description mostly restates the accepted company identifier types already present in the schema, adding no new parameter-level meaning.
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 uses a specific verb ('Add') with a clear resource ('companies... to a watchlist') and enumerates accepted identifier types (domain, name, LinkedIn URL, or id). This distinguishes it from sibling tools like remove_from_watchlist, create_watchlist, get_watchlist, and list_watchlists.
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 implies when to use the tool: when adding companies to an existing watchlist. However, it does not explicitly state when not to use it or mention alternatives such as remove_from_watchlist for removal operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
companiesARead-onlyInspect
Search and filter company records by keyword, exact domain, HQ country, industry group, NAICS code, employee-count bucket, or founded-year range. Costs one credit per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum records to return (1-100). Each returned record costs one credit. | |
| since | No | Return companies created/updated on or after this date (YYYY-MM-DD) or ISO-8601 timestamp. | |
| cursor | No | Opaque pagination cursor returned as pagination.nextCursor on the previous page. | |
| domain | No | Exact company domain. | |
| search | No | Keyword search over name, domain, and description. | |
| countries | No | Headquarters country codes (ISO alpha-2, OR). Pass "unknown" to include companies with no country on file. | |
| naicsCode | No | NAICS 2022 code. Matches the code and everything beneath it, so "51" also returns 5132 and 5173. Sector ranges work: "31-33" returns all manufacturing. Pass "unknown" for unclassified companies. Any 2- to 6-digit code is accepted; codes deeper than we classify (e.g. 541511) match at their deepest classified parent (5415). | |
| includeTotal | No | Also return pagination.total, the number of records matching these filters across all pages. Costs no credits. | |
| foundedYearMax | No | Maximum founded year. | |
| foundedYearMin | No | Minimum founded year. | |
| industryGroups | No | Company industry groups (OR). LinkedIn industry labels, matched case-insensitively; older LinkedIn names and short forms like "software" map to the current label. Pass "unknown" for companies with no industry on file. | |
| employeeCountBuckets | No | LinkedIn employee count buckets (OR), e.g. 51-200. Pass "unknown" for no headcount. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely useful non-annotated context: the one-credit-per-returned-record billing model, which directly affects how aggressively an agent should page. It omits auth requirements and rate-limit 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?
Two sentences with zero filler. The filter capabilities come first and the cost constraint, the most decision-relevant behavioral fact, is front-loaded in the second sentence.
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?
There is no output schema, so the description carries the burden of describing what a returned record contains, and it never says. Cost and pagination cursor semantics are only partially covered (cursor exists in the schema), and the record shape, sorting, and stability of results are unaddressed for a 12-parameter search tool.
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 all 12 parameters thoroughly (including NAICS prefix matching and 'unknown' sentinels). The description only restates the filter categories at a high level and adds no syntax or format detail beyond the schema, so the baseline 3 applies.
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?
States a specific verb pair (search and filter) plus the resource (company records) and enumerates the filter dimensions, so the agent knows exactly what it gets. It does not distinguish itself from siblings like acquisitions or funding_events, but those operate on different resources, so the risk of confusion is low.
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?
Usage is only implied: an agent can infer it should call this when it needs company records, but there is no explicit when-to-use, when-not-to, or named alternative. Sibling tools are not referenced at all, leaving routing decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
company_hiringARead-onlyInspect
Return each company's hiring picture right now: open roles by role family and function, leadership and founding roles, tools its roles name, a hiring stance (building go-to-market, building leadership, scaling engineering, frozen, ...) and its hiring signals from the last 90 days. Takes up to 25 companies by domain, LinkedIn URL, id or name. Costs one credit per profile returned. A company we have not read yet comes back as building and is read straight away; ask again in a few minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| companies | Yes | Up to 25 companies, each a domain (stripe.com), a LinkedIn company URL, a Datahyena company id, or a name. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare it a non-destructive read; the description adds genuinely new behavior: cost of one credit per profile, the 25-company cap, and the important caveat that an unread company returns as 'building' and is populated asynchronously so the caller should re-ask in a few minutes. That is exactly the kind of timing/rate context annotations cannot convey.
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?
Three dense sentences, front-loaded with the return payload before the input/cost caveats, and no filler. Slightly lengthy but every clause carries information.
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?
With no output schema, the description carries the burden of explaining return values and does so thoroughly, plus it covers the async-read edge case and cost. An agent has everything needed to call and interpret this correctly.
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% and the single parameter is fully documented, so baseline is 3. The description restates the accepted identifier formats (domain, LinkedIn URL, id, name), which mostly duplicates the schema rather than adding syntax or validation nuance.
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?
States a specific verb and resource ('Return each company's hiring picture') and enumerates exactly what is returned: open roles by role family, leadership/founding roles, tools, hiring stance, and 90-day signals. This clearly separates it from the generic `companies` sibling.
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?
Gives a clear context for use (current hiring snapshot for up to 25 companies) plus operational guidance about credits and re-querying fresh companies. It does not explicitly name alternatives such as `hiring_signals` or `companies`, so the when-not-to-use case is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
company_timelineARead-onlyInspect
Return one company's timeline: firmographics, investors, and a chronological list of funding rounds, acquisitions, executive moves and hiring signals. Resolve the company by id, domain, name, or LinkedIn URL. Pick event kinds with include (default all). Costs one credit for the company plus one per pulled event; nothing is charged if no company matches.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Datahyena company id. | |
| name | No | Company name. | |
| domain | No | Company domain, e.g. legora.com. | |
| include | No | Which event kinds to include (default all). Each pulled event costs one credit. | |
| linkedinUrl | No | Company LinkedIn URL or handle. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds genuinely new behavioral context beyond that: a credit cost model (one per company plus one per pulled event) and the fact that no charge applies when no company matches — material for an agent deciding whether to call.
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?
Three tight sentences, front-loaded with the return contents, then resolution, then filtering and cost. No filler and every clause carries information.
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?
With no output schema, the description usefully enumerates what comes back, and it covers resolution, filtering defaults, and billing. It omits pagination/result-size behavior and does not clarify what counts as a "hiring signal," but for a read-only tool with zero required params this is close to complete.
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 restates the four resolution inputs already documented in the schema and adds the include default ("default all") and the per-event cost tied to that parameter, which is marginally useful but not substantial beyond structured data.
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 gives a specific verb and resource ("Return one company's timeline") and enumerates the exact payload: firmographics, investors, funding rounds, acquisitions, exec moves, hiring signals. It does not explicitly contrast itself with siblings like funding_events or exec_moves, so the agent must infer that this is the composite/aggregate view.
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?
It explains how to invoke the tool (resolve by id, domain, name, or LinkedIn URL; narrow event kinds with include), which is real procedural guidance. However, it never states when to prefer this aggregate timeline over the single-event siblings (funding_events, acquisitions, exec_moves, hiring_signals), leaving the routing decision implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_watchlistBInspect
Create a named account watchlist. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Watchlist name. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false) already indicate this is a write operation, and the description's 'Create' aligns with that. However, the description adds no behavioral context beyond the annotations, such as permissions, side effects, or rate limits. 'Free' is irrelevant to behavior. With annotations present, the bar is lower, but the description adds nothing of value.
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 extremely concise (two short phrases) and front-loaded with the purpose. Every word earns its place, with no redundant or filler content. It is appropriately sized for a simple tool.
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 simple 1-parameter creation tool with annotations and no output schema, the description is adequate. It conveys the core purpose and the key qualifier 'account.' It could mention success behavior or prerequisites, but given the minimal complexity and full schema coverage, it is nearly complete. A small gap is the lack of mention that this is a distinct setup step before using add_to_watchlist, but that belongs to usage guidelines.
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% (the 'name' parameter is described as 'Watchlist name.'). The tool description does not add any additional meaning beyond what the schema provides. Baseline of 3 applies because the schema already fully documents the parameter.
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 action ('Create') and the resource ('a named account watchlist'), which is a specific verb+resource pairing. It distinguishes from sibling tools like add_to_watchlist or get_watchlist by indicating it creates the watchlist itself, though it doesn't explicitly contrast them.
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 no guidance on when to use this tool versus alternatives. It mentions 'Free' but that is not usage guidance. No exclusions or alternative tool names are given, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
exec_movesARead-onlyInspect
List executive appointment, promotion, departure, and transition events ordered by announcement date, newest first. Filter by company, person, role seniority, move type, or a time window. Costs one credit per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum records to return (1-100). Each returned record costs one credit. | |
| since | No | Return records announced on or after this date (YYYY-MM-DD) or ISO-8601 timestamp. | |
| until | No | Return records announced on or before this date (YYYY-MM-DD, inclusive) or ISO-8601 timestamp. | |
| cursor | No | Opaque pagination cursor returned as pagination.nextCursor on the previous page. | |
| domain | No | Company domain, e.g. stripe.com. Matches the company's primary domain or any domain it redirected from; a full URL works too. | |
| moveType | No | Move type filters. Canonical values: appointment, promotion, departure, transition. | |
| personId | No | Filter by person id. | |
| companyId | No | Filter by company id. | |
| countries | No | Headquarters country codes (ISO alpha-2, OR). Pass "unknown" to include companies with no country on file. | |
| naicsCode | No | NAICS 2022 code for the company. Matches the code and everything beneath it, so "51" also returns 5132 and 5173. Sector ranges work: "31-33" returns all manufacturing. Any 2- to 6-digit code is accepted; codes deeper than we classify (e.g. 541511) match at their deepest classified parent (5415). | |
| includeTotal | No | Also return pagination.total, the number of records matching these filters across all pages. Costs no credits. | |
| roleSeniority | No | Role seniority filters. Canonical values: c_level, vp_level, founder. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so safety is covered. The description adds genuinely non-obvious behavior: results are ordered newest-first by announcement date and the call costs one credit per returned record, which affects how aggressively an agent should page.
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?
Three tight sentences: what the tool returns and in what order, how to narrow it, and what it costs. The most decision-relevant facts (resource, ordering, cost) are front-loaded with no filler.
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 12-parameter, no-required-args list tool with no output schema, the description covers ordering, the filter surface, and the credit cost. The one real gap is that it says nothing about the shape of a returned move record or pagination behavior beyond the schema's cursor field, but the schema carries that burden well.
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 all 12 parameters in detail (NAICS prefix matching, country OR semantics, includeTotal cost-free behavior, cursor round-trip). The description only summarizes a subset of the filter surface (company, person, seniority, move type, time window) and omits domain/companyId distinction, countries, naicsCode, limit, cursor, and includeTotal, so it adds little beyond the baseline.
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?
States a specific verb and resource ('List executive appointment, promotion, departure, and transition events') and adds scope (ordered by announcement date, newest first). The named event types cleanly separate it from siblings like acquisitions and funding_events, so an agent can pick it without opening the schema.
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?
It enumerates the available filter dimensions (company, person, role seniority, move type, time window), which implies when the tool is useful, but it never says when to prefer it over a sibling such as company_timeline or funding_events, nor does it state any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
funding_eventsARead-onlyInspect
List funding events ordered by announcement date, newest first. Filter by round, amount range, company HQ country, industry group, or a specific company id. Costs one credit per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum records to return (1-100). Each returned record costs one credit. | |
| round | No | Funding round filters. Canonical values: pre-seed, seed, angel, series-a, series-b, series-c, series-d, series-e, series-f, series-g, series-h, series-i, growth, private-equity, extension, bridge, convertible, safe, debt, grant, pre-ipo, secondary, pipe, other. | |
| since | No | Return records announced on or after this date (YYYY-MM-DD) or ISO-8601 timestamp. | |
| until | No | Return records announced on or before this date (YYYY-MM-DD, inclusive) or ISO-8601 timestamp. | |
| cursor | No | Opaque pagination cursor returned as pagination.nextCursor on the previous page. | |
| domain | No | Company domain, e.g. stripe.com. Matches the company's primary domain or any domain it redirected from; a full URL works too. | |
| companyId | No | Return only events for this entity-resolved company id. | |
| countries | No | Headquarters country codes (ISO alpha-2, OR). Pass "unknown" to include companies with no country on file. | |
| naicsCode | No | NAICS 2022 code for the company. Matches the code and everything beneath it, so "51" also returns 5132 and 5173. Sector ranges work: "31-33" returns all manufacturing. Any 2- to 6-digit code is accepted; codes deeper than we classify (e.g. 541511) match at their deepest classified parent (5415). | |
| verticals | No | High-level sector filters (OR). Canonical values: ai, fintech, saas, devtools, healthcare, climate, robotics, cybersecurity, logistics, commerce, data, crypto, media, education, marketing, telecom, realestate, hardware, gaming, space. | |
| enrichedOnly | No | Return only rounds whose company resolved, so every result carries a domain, industry and country rather than a bare name. Leave it off for maximum coverage: some markets are reported nowhere else, and those rounds arrive with the company name alone. | |
| includeTotal | No | Also return pagination.total, the number of records matching these filters across all pages. Costs no credits. | |
| maxAmountUsd | No | Maximum funding amount in USD. | |
| minAmountUsd | No | Minimum funding amount in USD. | |
| industryGroups | No | Company industry groups (OR). LinkedIn industry labels, matched case-insensitively; older LinkedIn names and short forms like "software" map to the current label. Pass "unknown" for companies with no industry on file. | |
| employeeBuckets | No | Company employee-count buckets (OR). Canonical values: 1-10, 11-50, 51-200, 201-500, 501-1000, 1001-5000, 5001-10000, 10001+. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely non-structured behavior: the credit cost model ('one credit per returned record'), which is critical for an agent deciding on limit values. It stops short of describing pagination behavior or result shape.
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?
Two tight sentences with zero filler; the ordering behavior and filter inventory are front-loaded, and the cost caveat is placed last where it belongs. Every clause earns its place.
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 16-parameter, zero-required tool with no output schema, the description is thin: it never mentions pagination (cursor/nextCursor), the includeTotal option, or the shape of returned records. The credit model is a good addition, but an agent still has to open the schema to understand paging and totals, which the description could have surfaced.
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 carries all parameter meaning in rich detail (enums, NAICS prefix matching, country codes, enrichedOnly tradeoffs). The description only restates the filter categories at a summary level, adding no syntax or semantics beyond the schema. Baseline 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?
States a specific verb (List) and resource (funding events), plus the ordering rule (by announcement date, newest first) and the full set of filterable dimensions. It is readily distinguishable from siblings like acquisitions and exec_moves, which cover different event types.
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?
Usage is implied by the enumerated filters and the credit-cost note, so an agent can infer this is the tool for querying funding rounds. However, it never states when to prefer a sibling or how it relates to acquisitions/company_timeline, and there are no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_watchlistARead-onlyInspect
Return one watchlist with its resolved company members. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Watchlist id. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only and non-destructive nature of the tool. The description adds 'resolved company members' as a return detail but 'Free.' is vague and adds little behavioral context. 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 very short and front-loaded with the core purpose. The standalone 'Free.' sentence is ambiguous and arguably unnecessary, but overall the description avoids fluff and is easy to parse.
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 simple one-parameter read-only lookup, the description is reasonably complete with annotations covering safety. It clarifies the return content ('resolved company members'), which is useful since no output schema exists.
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 schema already documents the single parameter 'id' with description 'Watchlist id,' giving 100% coverage. The description does not add significant parameter semantics beyond implying a single watchlist is fetched.
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 function with a specific verb and resource: 'Return one watchlist with its resolved company members.' This distinguishes it from sibling tools like list_watchlists (plural) and add_to_watchlist/remove_from_watchlist (mutations).
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 implies usage for retrieving a specific watchlist by ID, but it does not explicitly mention when to use it over alternatives or provide any exclusions. The context is clear but guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hiring_signalsARead-onlyInspect
List hiring signals read from companies' own job boards, newest first: leadership openings, team build-outs, hiring surges and freezes, expansion into new countries and hard-to-fill roles. Each signal carries the roles behind it. Filter by type, function, seniority, company or a time window. Costs one credit per returned signal.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum records to return (1-100). Each returned record costs one credit. | |
| since | No | Return records announced on or after this date (YYYY-MM-DD) or ISO-8601 timestamp. | |
| until | No | Return records announced on or before this date (YYYY-MM-DD, inclusive) or ISO-8601 timestamp. | |
| cursor | No | Opaque pagination cursor returned as pagination.nextCursor on the previous page. | |
| domain | No | Company domain, e.g. stripe.com. Matches the company's primary domain or any domain it redirected from; a full URL works too. | |
| function | No | Job functions, e.g. sales or engineering. Canonical values: engineering, data, security, it, product, design, sales, marketing, customer_success, operations, finance, people, legal, research, healthcare, executive, other, all. | |
| companyId | No | Filter by company id. | |
| countries | No | Headquarters country codes (ISO alpha-2, OR). Pass "unknown" to include companies with no country on file. | |
| eventType | No | Signal types. Canonical values: leadership_opening, founding_role, role_family_scaling, technology_hiring, team_buildout, hiring_surge, hiring_freeze, location_expansion, hard_to_fill, leadership_filled. | |
| seniority | No | Seniority of a leadership opening, e.g. c_level, vp_level, head, director. | |
| activeOnly | No | Only signals whose roles are still open. | |
| roleFamily | No | Role families, e.g. sales_development, revops, security. Canonical values: sales_development, sales, sales_engineering, revops, gtm_engineering, partnerships, marketing, demand_gen, product_marketing, content_brand, customer_success, support, software_engineering, hardware_engineering, infrastructure, security, data_engineering, data_analytics, ml_ai, product_management, design, recruiting, people, finance, legal, it, operations, science, production. | |
| includeTotal | No | Also return pagination.total, the number of records matching these filters across all pages. Costs no credits. | |
| technologies | No | Technologies named in the roles, e.g. snowflake, salesforce, kubernetes. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, read-only, open-world read, so the safety profile is covered. The description adds genuinely non-annotated context: the cost model ('costs one credit per returned signal'), the ordering guarantee, the provenance of the data, and the fact that each signal carries its underlying roles. Auth requirements and rate limits remain undisclosed.
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?
Three tight sentences, front-loaded with the what-and-where, then filters, then cost. Nothing is wasted, though 'Costs one credit per returned signal' partially duplicates the limit parameter's schema description and the roles sentence sits oddly after the filter list rather than with the return description.
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 14-parameter, no-output-schema tool, the description covers source, ordering, signal taxonomy, filter dimensions, and even return structure ('each signal carries the roles behind it') plus the billing rule. It is close to sufficient; a note on pagination expectations or the interaction between activeOnly and the default time window would close the remaining gap.
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 every one of the 14 parameters, including the credit-per-record cost in 'limit'. The description's filter list mirrors the schema's own categories without adding syntax, defaults, or format guidance, so the baseline of 3 applies.
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?
States a specific verb (List) and resource (hiring signals) with unusual precision: the data source ('read from companies' own job boards'), the sort order ('newest first'), and an enumeration of the signal kinds returned. This is far beyond a tautology. It stops short of 5 because it never names or contrasts with the closest sibling, company_hiring, leaving the cross-company vs per-company distinction to inference.
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 sentence 'Filter by type, function, seniority, company or a time window' enumerates the filter axes, which is useful capability guidance, but it says nothing about when to reach for this tool over company_hiring or company_timeline, and gives no when-not conditions or prerequisites. Usage is implied rather than instructed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
investorsARead-onlyInspect
Search and filter investor records by keyword, type, HQ country, or exact domain. Costs one credit per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Investor type filters. Canonical values: vc, angel, cvc, pe, growth, accelerator, family_office, syndicate, unknown. | |
| limit | No | Maximum records to return (1-100). Each returned record costs one credit. | |
| since | No | Return investors created/updated on or after this date (YYYY-MM-DD) or ISO-8601 timestamp. | |
| cursor | No | Opaque pagination cursor returned as pagination.nextCursor on the previous page. | |
| domain | No | Exact investor domain. | |
| search | No | Keyword search over investor name and domain. | |
| countries | No | Headquarters country codes (ISO alpha-2, OR). Pass "unknown" to include companies with no country on file. | |
| investsIn | No | Only investors that have funded companies headquartered in these countries (OR), e.g. ["US"]. Filters on where an investor deploys rather than where it is registered, and is far better covered than HQ country. | |
| minRounds | No | Only investors that have participated in at least this many rounds. | |
| activeSince | No | Only investors whose most recent round was announced on or after this date (YYYY-MM-DD). | |
| minRoundUsd | No | Only investors that have participated in at least one round at or above this amount, in whole USD. Filters on behaviour rather than on a type label, which is sparse. | |
| includeTotal | No | Also return pagination.total, the number of records matching these filters across all pages. Costs no credits. | |
| hasFirmographics | No | Only investors whose domain and type we have resolved. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the read-only and non-destructive profile, and the description adds a real behavioral trait they do not: metered billing at one credit per returned record, which directly affects how the agent should set limit. It stops short of describing pagination behavior or the shape of returned records.
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?
Two sentences, zero padding, with the capability statement front-loaded and the cost constraint immediately after so the agent sees the tradeoff before it commits to a call.
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 13-parameter search tool with no output schema, the description omits what a returned 'investor record' contains and says nothing about paging beyond the schema's cursor, though it does surface the credit cost. The schema carries most of the load, leaving the description merely adequate.
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 all 13 parameters are already documented with canonical values, date formats, and OR semantics. The description only restates a subset (keyword, type, HQ country, domain) without adding syntax or format meaning, which is the correct baseline for full schema coverage.
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?
States a specific verb (search and filter) plus the resource (investor records) and enumerates the filter axes, so the agent knows exactly what it gets. It does not name any sibling or contrast itself with companies/funding_events, but no sibling is a competing investor-lookup tool, so the differentiation gap is minor.
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?
Usage is implied: reach for this when you need investor records matching keyword/type/country/domain. There is no explicit when-to-use vs alternatives and no exclusions (e.g. when to prefer funding_events over investors), so the agent must infer routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_watchlistsARead-onlyInspect
List the workspace's account watchlists with member counts. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=true and destructiveHint=false, so the description need not repeat those. It adds value by specifying the scope ('workspace's account'), that member counts are included, and the 'Free.' note, which could indicate no cost or restrictions. No contradiction with annotations exists, and the description supplements them meaningfully.
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 two short sentences with zero fluff. It front-loads the core action and outcome, and the 'Free.' addition is a concise extra. Every word earns its place, making it exceptionally efficient.
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 simple list operation with no parameters and no output schema, the description is sufficiently complete. It specifies the scope, includes a notable detail (member counts), and is supported by strong annotations. Sibling tools provide context that this is the enumeration function, so nothing essential is missing.
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?
There are zero parameters, so the schema coverage is trivially 100%. Per rubric, baseline is 4 for 0 parameters. The description doesn't need to add parameter details since there are none; it correctly focuses on the tool's behavior. No additional semantic information is required.
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 uses a specific verb ('List') and resource ('workspace's account watchlists') with a distinct outcome ('with member counts'). It clearly differentiates from siblings like get_watchlist (which likely retrieves a single watchlist) and create/remove/add tools. The purpose is unambiguous and well-scoped.
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 implies when to use (to list all watchlists in the workspace) but does not explicitly mention alternatives or exclusion criteria. Given sibling names, the context is clear enough that an agent could infer when to use this tool over get_watchlist. However, it lacks an explicit 'use this when you need all watchlists' statement, so it isn't a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_from_watchlistADestructiveIdempotentInspect
Remove companies from a watchlist. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Watchlist id. | |
| companies | Yes | Company identifiers: domain, name, LinkedIn URL, or Datahyena id. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, and the description's 'Remove' is consistent. However, the description adds no additional behavioral context such as irreversibility, permission requirements, or side effects beyond the annotation. Since annotations cover the safety profile, this is acceptable but not enhanced.
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 extremely concise: 'Remove companies from a watchlist. Free.' It contains no unnecessary words, and the structure is clean. The 'Free.' is somewhat extraneous but does not detract; overall it is highly focused.
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?
The description adequately conveys the core operation, but it does not specify what happens after the removal (e.g., return value or success/failure semantics). Since there is no output schema, this is not required, but a more complete description might mention whether the updated watchlist is returned or if errors are expected. It is sufficient for a simple destructive action but lacks a minor detail.
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 coverage is 100% with descriptions for both parameters. The description for 'companies' adds useful detail about accepted identifier formats ('domain, name, LinkedIn URL, or Datahyena id'), but the 'id' description is minimal ('Watchlist id.'). This matches the baseline for full schema coverage without significant extra value.
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 action: 'Remove companies from a watchlist.' It names the specific verb and resource, and it distinguishes from sibling tools like add_to_watchlist or create_watchlist. The purpose is unambiguous.
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 implies usage (when you need to remove companies) but does not explicitly mention when not to use it or suggest alternative tools. Unlike the HIGH example, it lacks an explicit cross-reference such as 'use add_to_watchlist instead.' The context of sibling tools makes it clear, but the description itself does not provide explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
hiring_signals1 field changed- removed
Input schema / properties / fundedWithinDaysRemoved value: -{ - "description": "Only companies that announced a funding round this many days before the signal.", - "maximum": 365, - "minimum": 1, - "type": "integer" -}
1 tool update
- Added
company_hiring
1 tool update
- Changed
hiring_signals4 fields changed- changed
Input schema / properties / eventType / descriptionPrevious value: -"Signal types. Canonical values: leadership_opening, team_buildout, hiring_surge, hiring_freeze, location_expansion, hard_to_fill, leadership_filled."New value: +"Signal types. Canonical values: leadership_opening, founding_role, role_family_scaling, technology_hiring, team_buildout, hiring_surge, hiring_freeze, location_expansion, hard_to_fill, leadership_filled." - changed
Input schema / properties / eventType / items / enumPrevious value: -[ - "leadership_opening", - "team_buildout", - "hiring_surge", - "hiring_freeze", - "location_expansion", - "hard_to_fill", - "leadership_filled" -]New value: +[ + "leadership_opening", + "founding_role", + "role_family_scaling", + "technology_hiring", + "team_buildout", + "hiring_surge", + "hiring_freeze", + "location_expansion", + "hard_to_fill", + "leadership_filled" +] - added
Input schema / properties / fundedWithinDaysAdded value: +{ + "description": "Only companies that announced a funding round this many days before the signal.", + "maximum": 365, + "minimum": 1, + "type": "integer" +} - added
Input schema / properties / roleFamilyAdded value: +{ + "description": "Role families, e.g. sales_development, revops, security. Canonical values: sales_development, sales, sales_engineering, revops, gtm_engineering, partnerships, marketing, demand_gen, product_marketing, content_brand, customer_success, support, software_engineering, hardware_engineering, infrastructure, security, data_engineering, data_analytics, ml_ai, product_management, design, recruiting, people, finance, legal, it, operations, science, production.", + "items": { + "enum": [ + "sales_development", + "sales", + "sales_engineering", + "revops", + "gtm_engineering", + "partnerships", + "marketing", + "demand_gen", + "product_marketing", + "content_brand", + "customer_success", + "support", + "software_engineering", + "hardware_engineering", + "infrastructure", + "security", + "data_engineering", + "data_analytics", + "ml_ai", + "product_management", + "design", + "recruiting", + "people", + "finance", + "legal", + "it", + "operations", + "science", + "production" + ], + "type": "string" + }, + "type": "array" +}
2 tool updates
- Changed
company_timeline1 field changed- changed
Input schema / properties / include / items / enumPrevious value: -[ - "funding", - "acquisitions", - "exec_moves" -]New value: +[ + "funding", + "acquisitions", + "exec_moves", + "hiring" +]
- Added
hiring_signals
5 tool updates
- Changed
acquisitions5 fields changed- added
Input schema / properties / domainAdded value: +{ + "description": "Company domain, e.g. stripe.com. Matches the company's primary domain or any domain it redirected from; a full URL works too.", + "maxLength": 253, + "type": "string" +} - added
Input schema / properties / includeTotalAdded value: +{ + "description": "Also return pagination.total, the number of records matching these filters across all pages. Costs no credits.", + "type": "boolean" +} - changed
Input schema / properties / industryGroups / descriptionPrevious value: -"Company industry groups (OR). Matched literally against the LinkedIn labels. Pass \"unknown\" for companies with no industry on file."New value: +"Company industry groups (OR). LinkedIn industry labels, matched case-insensitively; older LinkedIn names and short forms like \"software\" map to the current label. Pass \"unknown\" for companies with no industry on file." - changed
Input schema / properties / naicsCode / descriptionPrevious value: -"NAICS 2022 code for the target (acquired) company. Matches the code and everything beneath it, so \"51\" also returns 5132 and 5173. Sector ranges work: \"31-33\" returns all manufacturing."New value: +"NAICS 2022 code for the target (acquired) company. Matches the code and everything beneath it, so \"51\" also returns 5132 and 5173. Sector ranges work: \"31-33\" returns all manufacturing. Any 2- to 6-digit code is accepted; codes deeper than we classify (e.g. 541511) match at their deepest classified parent (5415)." - removed
Input schema / properties / naicsCode / enumRemoved value: -[ - "11", - "21", - "22", - "23", - "42", - "51", - "52", - "53", - "54", - "56", - "71", - "81", - "92", - "111", - "113", - "114", - "212", - "236", - "238", - "311", - "313", - "315", - "316", - "321", - "322", - "323", - "325", - "327", - "331", - "332", - "335", - "336", - "337", - "458", - "482", - "483", - "484", - "485", - "493", - "519", - "532", - "562", - "611", - "621", - "622", - "623", - "712", - "721", - "722", - "811", - "812", - "813", - "1114", - "2111", - "2211", - "2213", - "2361", - "2382", - "3111", - "3115", - "3116", - "3117", - "3118", - "3121", - "3122", - "3162", - "3222", - "3253", - "3254", - "3255", - "3256", - "3261", - "3272", - "3323", - "3325", - "3328", - "3331", - "3332", - "3334", - "3341", - "3342", - "3343", - "3344", - "3345", - "3351", - "3352", - "3353", - "3359", - "3361", - "3363", - "3364", - "3365", - "3366", - "3372", - "3391", - "3399", - "4231", - "4233", - "4234", - "4235", - "4236", - "4238", - "4244", - "4245", - "4246", - "4247", - "4248", - "4411", - "4441", - "4451", - "4491", - "4561", - "4571", - "4591", - "4593", - "4811", - "4851", - "4853", - "4921", - "5121", - "5122", - "5131", - "5132", - "5161", - "5162", - "5173", - "5192", - "5221", - "5231", - "5239", - "5241", - "5242", - "5311", - "5312", - "5322", - "5411", - "5412", - "5413", - "5414", - "5415", - "5416", - "5417", - "5418", - "5419", - "5511", - "5613", - "5614", - "5615", - "5616", - "5617", - "5621", - "6111", - "6113", - "6114", - "6115", - "6213", - "6214", - "6215", - "6216", - "6241", - "6242", - "6244", - "7111", - "7112", - "7115", - "7132", - "7139", - "7225", - "8111", - "8121", - "8123", - "8129", - "8131", - "8132", - "8134", - "8139", - "9211", - "9221", - "9281", - "unknown", - "31-33", - "44-45", - "48-49" -]
- Changed
companies4 fields changed- added
Input schema / properties / includeTotalAdded value: +{ + "description": "Also return pagination.total, the number of records matching these filters across all pages. Costs no credits.", + "type": "boolean" +} - changed
Input schema / properties / industryGroups / descriptionPrevious value: -"Company industry groups (OR). Matched literally against the LinkedIn labels. Pass \"unknown\" for companies with no industry on file."New value: +"Company industry groups (OR). LinkedIn industry labels, matched case-insensitively; older LinkedIn names and short forms like \"software\" map to the current label. Pass \"unknown\" for companies with no industry on file." - changed
Input schema / properties / naicsCode / descriptionPrevious value: -"NAICS 2022 code. Matches the code and everything beneath it, so \"51\" also returns 5132 and 5173. Sector ranges work: \"31-33\" returns all manufacturing. Pass \"unknown\" for unclassified companies."New value: +"NAICS 2022 code. Matches the code and everything beneath it, so \"51\" also returns 5132 and 5173. Sector ranges work: \"31-33\" returns all manufacturing. Pass \"unknown\" for unclassified companies. Any 2- to 6-digit code is accepted; codes deeper than we classify (e.g. 541511) match at their deepest classified parent (5415)." - removed
Input schema / properties / naicsCode / enumRemoved value: -[ - "11", - "21", - "22", - "23", - "42", - "51", - "52", - "53", - "54", - "56", - "71", - "81", - "92", - "111", - "113", - "114", - "212", - "236", - "238", - "311", - "313", - "315", - "316", - "321", - "322", - "323", - "325", - "327", - "331", - "332", - "335", - "336", - "337", - "458", - "482", - "483", - "484", - "485", - "493", - "519", - "532", - "562", - "611", - "621", - "622", - "623", - "712", - "721", - "722", - "811", - "812", - "813", - "1114", - "2111", - "2211", - "2213", - "2361", - "2382", - "3111", - "3115", - "3116", - "3117", - "3118", - "3121", - "3122", - "3162", - "3222", - "3253", - "3254", - "3255", - "3256", - "3261", - "3272", - "3323", - "3325", - "3328", - "3331", - "3332", - "3334", - "3341", - "3342", - "3343", - "3344", - "3345", - "3351", - "3352", - "3353", - "3359", - "3361", - "3363", - "3364", - "3365", - "3366", - "3372", - "3391", - "3399", - "4231", - "4233", - "4234", - "4235", - "4236", - "4238", - "4244", - "4245", - "4246", - "4247", - "4248", - "4411", - "4441", - "4451", - "4491", - "4561", - "4571", - "4591", - "4593", - "4811", - "4851", - "4853", - "4921", - "5121", - "5122", - "5131", - "5132", - "5161", - "5162", - "5173", - "5192", - "5221", - "5231", - "5239", - "5241", - "5242", - "5311", - "5312", - "5322", - "5411", - "5412", - "5413", - "5414", - "5415", - "5416", - "5417", - "5418", - "5419", - "5511", - "5613", - "5614", - "5615", - "5616", - "5617", - "5621", - "6111", - "6113", - "6114", - "6115", - "6213", - "6214", - "6215", - "6216", - "6241", - "6242", - "6244", - "7111", - "7112", - "7115", - "7132", - "7139", - "7225", - "8111", - "8121", - "8123", - "8129", - "8131", - "8132", - "8134", - "8139", - "9211", - "9221", - "9281", - "unknown", - "31-33", - "44-45", - "48-49" -]
- Changed
exec_moves4 fields changed- added
Input schema / properties / domainAdded value: +{ + "description": "Company domain, e.g. stripe.com. Matches the company's primary domain or any domain it redirected from; a full URL works too.", + "maxLength": 253, + "type": "string" +} - added
Input schema / properties / includeTotalAdded value: +{ + "description": "Also return pagination.total, the number of records matching these filters across all pages. Costs no credits.", + "type": "boolean" +} - changed
Input schema / properties / naicsCode / descriptionPrevious value: -"NAICS 2022 code for the company. Matches the code and everything beneath it, so \"51\" also returns 5132 and 5173. Sector ranges work: \"31-33\" returns all manufacturing."New value: +"NAICS 2022 code for the company. Matches the code and everything beneath it, so \"51\" also returns 5132 and 5173. Sector ranges work: \"31-33\" returns all manufacturing. Any 2- to 6-digit code is accepted; codes deeper than we classify (e.g. 541511) match at their deepest classified parent (5415)." - removed
Input schema / properties / naicsCode / enumRemoved value: -[ - "11", - "21", - "22", - "23", - "42", - "51", - "52", - "53", - "54", - "56", - "71", - "81", - "92", - "111", - "113", - "114", - "212", - "236", - "238", - "311", - "313", - "315", - "316", - "321", - "322", - "323", - "325", - "327", - "331", - "332", - "335", - "336", - "337", - "458", - "482", - "483", - "484", - "485", - "493", - "519", - "532", - "562", - "611", - "621", - "622", - "623", - "712", - "721", - "722", - "811", - "812", - "813", - "1114", - "2111", - "2211", - "2213", - "2361", - "2382", - "3111", - "3115", - "3116", - "3117", - "3118", - "3121", - "3122", - "3162", - "3222", - "3253", - "3254", - "3255", - "3256", - "3261", - "3272", - "3323", - "3325", - "3328", - "3331", - "3332", - "3334", - "3341", - "3342", - "3343", - "3344", - "3345", - "3351", - "3352", - "3353", - "3359", - "3361", - "3363", - "3364", - "3365", - "3366", - "3372", - "3391", - "3399", - "4231", - "4233", - "4234", - "4235", - "4236", - "4238", - "4244", - "4245", - "4246", - "4247", - "4248", - "4411", - "4441", - "4451", - "4491", - "4561", - "4571", - "4591", - "4593", - "4811", - "4851", - "4853", - "4921", - "5121", - "5122", - "5131", - "5132", - "5161", - "5162", - "5173", - "5192", - "5221", - "5231", - "5239", - "5241", - "5242", - "5311", - "5312", - "5322", - "5411", - "5412", - "5413", - "5414", - "5415", - "5416", - "5417", - "5418", - "5419", - "5511", - "5613", - "5614", - "5615", - "5616", - "5617", - "5621", - "6111", - "6113", - "6114", - "6115", - "6213", - "6214", - "6215", - "6216", - "6241", - "6242", - "6244", - "7111", - "7112", - "7115", - "7132", - "7139", - "7225", - "8111", - "8121", - "8123", - "8129", - "8131", - "8132", - "8134", - "8139", - "9211", - "9221", - "9281", - "unknown", - "31-33", - "44-45", - "48-49" -]
- Changed
funding_events5 fields changed- added
Input schema / properties / domainAdded value: +{ + "description": "Company domain, e.g. stripe.com. Matches the company's primary domain or any domain it redirected from; a full URL works too.", + "maxLength": 253, + "type": "string" +} - added
Input schema / properties / includeTotalAdded value: +{ + "description": "Also return pagination.total, the number of records matching these filters across all pages. Costs no credits.", + "type": "boolean" +} - changed
Input schema / properties / industryGroups / descriptionPrevious value: -"Company industry groups (OR). Matched literally against the LinkedIn labels. Pass \"unknown\" for companies with no industry on file."New value: +"Company industry groups (OR). LinkedIn industry labels, matched case-insensitively; older LinkedIn names and short forms like \"software\" map to the current label. Pass \"unknown\" for companies with no industry on file." - changed
Input schema / properties / naicsCode / descriptionPrevious value: -"NAICS 2022 code for the company. Matches the code and everything beneath it, so \"51\" also returns 5132 and 5173. Sector ranges work: \"31-33\" returns all manufacturing."New value: +"NAICS 2022 code for the company. Matches the code and everything beneath it, so \"51\" also returns 5132 and 5173. Sector ranges work: \"31-33\" returns all manufacturing. Any 2- to 6-digit code is accepted; codes deeper than we classify (e.g. 541511) match at their deepest classified parent (5415)." - removed
Input schema / properties / naicsCode / enumRemoved value: -[ - "11", - "21", - "22", - "23", - "42", - "51", - "52", - "53", - "54", - "56", - "71", - "81", - "92", - "111", - "113", - "114", - "212", - "236", - "238", - "311", - "313", - "315", - "316", - "321", - "322", - "323", - "325", - "327", - "331", - "332", - "335", - "336", - "337", - "458", - "482", - "483", - "484", - "485", - "493", - "519", - "532", - "562", - "611", - "621", - "622", - "623", - "712", - "721", - "722", - "811", - "812", - "813", - "1114", - "2111", - "2211", - "2213", - "2361", - "2382", - "3111", - "3115", - "3116", - "3117", - "3118", - "3121", - "3122", - "3162", - "3222", - "3253", - "3254", - "3255", - "3256", - "3261", - "3272", - "3323", - "3325", - "3328", - "3331", - "3332", - "3334", - "3341", - "3342", - "3343", - "3344", - "3345", - "3351", - "3352", - "3353", - "3359", - "3361", - "3363", - "3364", - "3365", - "3366", - "3372", - "3391", - "3399", - "4231", - "4233", - "4234", - "4235", - "4236", - "4238", - "4244", - "4245", - "4246", - "4247", - "4248", - "4411", - "4441", - "4451", - "4491", - "4561", - "4571", - "4591", - "4593", - "4811", - "4851", - "4853", - "4921", - "5121", - "5122", - "5131", - "5132", - "5161", - "5162", - "5173", - "5192", - "5221", - "5231", - "5239", - "5241", - "5242", - "5311", - "5312", - "5322", - "5411", - "5412", - "5413", - "5414", - "5415", - "5416", - "5417", - "5418", - "5419", - "5511", - "5613", - "5614", - "5615", - "5616", - "5617", - "5621", - "6111", - "6113", - "6114", - "6115", - "6213", - "6214", - "6215", - "6216", - "6241", - "6242", - "6244", - "7111", - "7112", - "7115", - "7132", - "7139", - "7225", - "8111", - "8121", - "8123", - "8129", - "8131", - "8132", - "8134", - "8139", - "9211", - "9221", - "9281", - "unknown", - "31-33", - "44-45", - "48-49" -]
- Changed
investors1 field changed- added
Input schema / properties / includeTotalAdded value: +{ + "description": "Also return pagination.total, the number of records matching these filters across all pages. Costs no credits.", + "type": "boolean" +}
1 tool update
- Changed
funding_events1 field changed- added
Input schema / properties / enrichedOnlyAdded value: +{ + "description": "Return only rounds whose company resolved, so every result carries a domain, industry and country rather than a bare name. Leave it off for maximum coverage: some markets are reported nowhere else, and those rounds arrive with the company name alone.", + "type": "boolean" +}
1 tool update
- Changed
funding_events2 fields changed- changed
Input schema / properties / round / descriptionPrevious value: -"Funding round filters. Canonical values: pre-seed, seed, angel, series-a, series-b, series-c, series-d, series-e, series-f, series-g, series-h, series-i, growth, extension, bridge, convertible, safe, debt, grant, pre-ipo, secondary, pipe, other."New value: +"Funding round filters. Canonical values: pre-seed, seed, angel, series-a, series-b, series-c, series-d, series-e, series-f, series-g, series-h, series-i, growth, private-equity, extension, bridge, convertible, safe, debt, grant, pre-ipo, secondary, pipe, other." - changed
Input schema / properties / round / items / enumPrevious value: -[ - "pre-seed", - "seed", - "angel", - "series-a", - "series-b", - "series-c", - "series-d", - "series-e", - "series-f", - "series-g", - "series-h", - "series-i", - "growth", - "extension", - "bridge", - "convertible", - "safe", - "debt", - "grant", - "pre-ipo", - "secondary", - "pipe", - "other", - "unknown" -]New value: +[ + "pre-seed", + "seed", + "angel", + "series-a", + "series-b", + "series-c", + "series-d", + "series-e", + "series-f", + "series-g", + "series-h", + "series-i", + "growth", + "private-equity", + "extension", + "bridge", + "convertible", + "safe", + "debt", + "grant", + "pre-ipo", + "secondary", + "pipe", + "other", + "unknown" +]
5 tool updates
- Changed
acquisitions1 field changed- changed
Input schema / properties / countries / items / enumPrevious value: -[ - "unknown", - "AD", - "AE", - "AF", - "AG", - "AL", - "AM", - "AO", - "AR", - "AT", - "AU", - "AZ", - "BA", - "BB", - "BD", - "BE", - "BF", - "BG", - "BH", - "BI", - "BJ", - "BM", - "BN", - "BO", - "BR", - "BS", - "BT", - "BW", - "BY", - "BZ", - "CA", - "CD", - "CF", - "CG", - "CH", - "CI", - "CL", - "CM", - "CN", - "CO", - "CR", - "CU", - "CV", - "CY", - "CZ", - "DE", - "DJ", - "DK", - "DM", - "DO", - "DZ", - "EC", - "EE", - "EG", - "ER", - "ES", - "ET", - "FI", - "FJ", - "FM", - "FR", - "GA", - "GB", - "GD", - "GE", - "GG", - "GH", - "GI", - "GM", - "GN", - "GQ", - "GR", - "GT", - "GW", - "GY", - "HK", - "HN", - "HR", - "HT", - "HU", - "ID", - "IE", - "IL", - "IM", - "IN", - "IQ", - "IR", - "IS", - "IT", - "JE", - "JM", - "JO", - "JP", - "KE", - "KG", - "KH", - "KI", - "KM", - "KN", - "KP", - "KR", - "KW", - "KY", - "KZ", - "LA", - "LB", - "LC", - "LI", - "LK", - "LR", - "LS", - "LT", - "LU", - "LV", - "LY", - "MA", - "MC", - "MD", - "ME", - "MG", - "MH", - "MK", - "ML", - "MM", - "MN", - "MO", - "MR", - "MT", - "MU", - "MV", - "MW", - "MX", - "MY", - "MZ", - "NA", - "NE", - "NG", - "NI", - "NL", - "NO", - "NP", - "NR", - "NZ", - "OM", - "PA", - "PG", - "PH", - "PK", - "PL", - "PR", - "PS", - "PT", - "PW", - "PY", - "QA", - "RO", - "RS", - "RU", - "RW", - "SA", - "SB", - "SC", - "SD", - "SE", - "SG", - "SI", - "SK", - "SL", - "SM", - "SN", - "SO", - "SR", - "SS", - "ST", - "SV", - "SY", - "SZ", - "TD", - "TG", - "TH", - "TJ", - "TL", - "TM", - "TN", - "TO", - "TR", - "TT", - "TV", - "TW", - "TZ", - "UA", - "UG", - "US", - "UY", - "UZ", - "VA", - "VC", - "VE", - "VG", - "VN", - "VU", - "WS", - "YE", - "ZA", - "ZM", - "ZW" -]New value: +[ + "unknown", + "AD", + "AE", + "AF", + "AG", + "AI", + "AL", + "AM", + "AO", + "AR", + "AS", + "AT", + "AU", + "AW", + "AX", + "AZ", + "BA", + "BB", + "BD", + "BE", + "BF", + "BG", + "BH", + "BI", + "BJ", + "BL", + "BM", + "BN", + "BO", + "BQ", + "BR", + "BS", + "BT", + "BW", + "BY", + "BZ", + "CA", + "CD", + "CF", + "CG", + "CH", + "CI", + "CK", + "CL", + "CM", + "CN", + "CO", + "CR", + "CU", + "CV", + "CW", + "CY", + "CZ", + "DE", + "DJ", + "DK", + "DM", + "DO", + "DZ", + "EC", + "EE", + "EG", + "EH", + "ER", + "ES", + "ET", + "FI", + "FJ", + "FK", + "FM", + "FO", + "FR", + "GA", + "GB", + "GD", + "GE", + "GF", + "GG", + "GH", + "GI", + "GL", + "GM", + "GN", + "GP", + "GQ", + "GR", + "GT", + "GU", + "GW", + "GY", + "HK", + "HN", + "HR", + "HT", + "HU", + "ID", + "IE", + "IL", + "IM", + "IN", + "IQ", + "IR", + "IS", + "IT", + "JE", + "JM", + "JO", + "JP", + "KE", + "KG", + "KH", + "KI", + "KM", + "KN", + "KP", + "KR", + "KW", + "KY", + "KZ", + "LA", + "LB", + "LC", + "LI", + "LK", + "LR", + "LS", + "LT", + "LU", + "LV", + "LY", + "MA", + "MC", + "MD", + "ME", + "MF", + "MG", + "MH", + "MK", + "ML", + "MM", + "MN", + "MO", + "MP", + "MQ", + "MR", + "MS", + "MT", + "MU", + "MV", + "MW", + "MX", + "MY", + "MZ", + "NA", + "NC", + "NE", + "NG", + "NI", + "NL", + "NO", + "NP", + "NR", + "NU", + "NZ", + "OM", + "PA", + "PE", + "PF", + "PG", + "PH", + "PK", + "PL", + "PM", + "PR", + "PS", + "PT", + "PW", + "PY", + "QA", + "RE", + "RO", + "RS", + "RU", + "RW", + "SA", + "SB", + "SC", + "SD", + "SE", + "SG", + "SH", + "SI", + "SK", + "SL", + "SM", + "SN", + "SO", + "SR", + "SS", + "ST", + "SV", + "SX", + "SY", + "SZ", + "TC", + "TD", + "TG", + "TH", + "TJ", + "TK", + "TL", + "TM", + "TN", + "TO", + "TR", + "TT", + "TV", + "TW", + "TZ", + "UA", + "UG", + "US", + "UY", + "UZ", + "VA", + "VC", + "VE", + "VG", + "VI", + "VN", + "VU", + "WF", + "WS", + "YE", + "YT", + "ZA", + "ZM", + "ZW" +]
- Changed
companies1 field changed- changed
Input schema / properties / countries / items / enumPrevious value: -[ - "unknown", - "AD", - "AE", - "AF", - "AG", - "AL", - "AM", - "AO", - "AR", - "AT", - "AU", - "AZ", - "BA", - "BB", - "BD", - "BE", - "BF", - "BG", - "BH", - "BI", - "BJ", - "BM", - "BN", - "BO", - "BR", - "BS", - "BT", - "BW", - "BY", - "BZ", - "CA", - "CD", - "CF", - "CG", - "CH", - "CI", - "CL", - "CM", - "CN", - "CO", - "CR", - "CU", - "CV", - "CY", - "CZ", - "DE", - "DJ", - "DK", - "DM", - "DO", - "DZ", - "EC", - "EE", - "EG", - "ER", - "ES", - "ET", - "FI", - "FJ", - "FM", - "FR", - "GA", - "GB", - "GD", - "GE", - "GG", - "GH", - "GI", - "GM", - "GN", - "GQ", - "GR", - "GT", - "GW", - "GY", - "HK", - "HN", - "HR", - "HT", - "HU", - "ID", - "IE", - "IL", - "IM", - "IN", - "IQ", - "IR", - "IS", - "IT", - "JE", - "JM", - "JO", - "JP", - "KE", - "KG", - "KH", - "KI", - "KM", - "KN", - "KP", - "KR", - "KW", - "KY", - "KZ", - "LA", - "LB", - "LC", - "LI", - "LK", - "LR", - "LS", - "LT", - "LU", - "LV", - "LY", - "MA", - "MC", - "MD", - "ME", - "MG", - "MH", - "MK", - "ML", - "MM", - "MN", - "MO", - "MR", - "MT", - "MU", - "MV", - "MW", - "MX", - "MY", - "MZ", - "NA", - "NE", - "NG", - "NI", - "NL", - "NO", - "NP", - "NR", - "NZ", - "OM", - "PA", - "PG", - "PH", - "PK", - "PL", - "PR", - "PS", - "PT", - "PW", - "PY", - "QA", - "RO", - "RS", - "RU", - "RW", - "SA", - "SB", - "SC", - "SD", - "SE", - "SG", - "SI", - "SK", - "SL", - "SM", - "SN", - "SO", - "SR", - "SS", - "ST", - "SV", - "SY", - "SZ", - "TD", - "TG", - "TH", - "TJ", - "TL", - "TM", - "TN", - "TO", - "TR", - "TT", - "TV", - "TW", - "TZ", - "UA", - "UG", - "US", - "UY", - "UZ", - "VA", - "VC", - "VE", - "VG", - "VN", - "VU", - "WS", - "YE", - "ZA", - "ZM", - "ZW" -]New value: +[ + "unknown", + "AD", + "AE", + "AF", + "AG", + "AI", + "AL", + "AM", + "AO", + "AR", + "AS", + "AT", + "AU", + "AW", + "AX", + "AZ", + "BA", + "BB", + "BD", + "BE", + "BF", + "BG", + "BH", + "BI", + "BJ", + "BL", + "BM", + "BN", + "BO", + "BQ", + "BR", + "BS", + "BT", + "BW", + "BY", + "BZ", + "CA", + "CD", + "CF", + "CG", + "CH", + "CI", + "CK", + "CL", + "CM", + "CN", + "CO", + "CR", + "CU", + "CV", + "CW", + "CY", + "CZ", + "DE", + "DJ", + "DK", + "DM", + "DO", + "DZ", + "EC", + "EE", + "EG", + "EH", + "ER", + "ES", + "ET", + "FI", + "FJ", + "FK", + "FM", + "FO", + "FR", + "GA", + "GB", + "GD", + "GE", + "GF", + "GG", + "GH", + "GI", + "GL", + "GM", + "GN", + "GP", + "GQ", + "GR", + "GT", + "GU", + "GW", + "GY", + "HK", + "HN", + "HR", + "HT", + "HU", + "ID", + "IE", + "IL", + "IM", + "IN", + "IQ", + "IR", + "IS", + "IT", + "JE", + "JM", + "JO", + "JP", + "KE", + "KG", + "KH", + "KI", + "KM", + "KN", + "KP", + "KR", + "KW", + "KY", + "KZ", + "LA", + "LB", + "LC", + "LI", + "LK", + "LR", + "LS", + "LT", + "LU", + "LV", + "LY", + "MA", + "MC", + "MD", + "ME", + "MF", + "MG", + "MH", + "MK", + "ML", + "MM", + "MN", + "MO", + "MP", + "MQ", + "MR", + "MS", + "MT", + "MU", + "MV", + "MW", + "MX", + "MY", + "MZ", + "NA", + "NC", + "NE", + "NG", + "NI", + "NL", + "NO", + "NP", + "NR", + "NU", + "NZ", + "OM", + "PA", + "PE", + "PF", + "PG", + "PH", + "PK", + "PL", + "PM", + "PR", + "PS", + "PT", + "PW", + "PY", + "QA", + "RE", + "RO", + "RS", + "RU", + "RW", + "SA", + "SB", + "SC", + "SD", + "SE", + "SG", + "SH", + "SI", + "SK", + "SL", + "SM", + "SN", + "SO", + "SR", + "SS", + "ST", + "SV", + "SX", + "SY", + "SZ", + "TC", + "TD", + "TG", + "TH", + "TJ", + "TK", + "TL", + "TM", + "TN", + "TO", + "TR", + "TT", + "TV", + "TW", + "TZ", + "UA", + "UG", + "US", + "UY", + "UZ", + "VA", + "VC", + "VE", + "VG", + "VI", + "VN", + "VU", + "WF", + "WS", + "YE", + "YT", + "ZA", + "ZM", + "ZW" +]
- Changed
exec_moves1 field changed- changed
Input schema / properties / countries / items / enumPrevious value: -[ - "unknown", - "AD", - "AE", - "AF", - "AG", - "AL", - "AM", - "AO", - "AR", - "AT", - "AU", - "AZ", - "BA", - "BB", - "BD", - "BE", - "BF", - "BG", - "BH", - "BI", - "BJ", - "BM", - "BN", - "BO", - "BR", - "BS", - "BT", - "BW", - "BY", - "BZ", - "CA", - "CD", - "CF", - "CG", - "CH", - "CI", - "CL", - "CM", - "CN", - "CO", - "CR", - "CU", - "CV", - "CY", - "CZ", - "DE", - "DJ", - "DK", - "DM", - "DO", - "DZ", - "EC", - "EE", - "EG", - "ER", - "ES", - "ET", - "FI", - "FJ", - "FM", - "FR", - "GA", - "GB", - "GD", - "GE", - "GG", - "GH", - "GI", - "GM", - "GN", - "GQ", - "GR", - "GT", - "GW", - "GY", - "HK", - "HN", - "HR", - "HT", - "HU", - "ID", - "IE", - "IL", - "IM", - "IN", - "IQ", - "IR", - "IS", - "IT", - "JE", - "JM", - "JO", - "JP", - "KE", - "KG", - "KH", - "KI", - "KM", - "KN", - "KP", - "KR", - "KW", - "KY", - "KZ", - "LA", - "LB", - "LC", - "LI", - "LK", - "LR", - "LS", - "LT", - "LU", - "LV", - "LY", - "MA", - "MC", - "MD", - "ME", - "MG", - "MH", - "MK", - "ML", - "MM", - "MN", - "MO", - "MR", - "MT", - "MU", - "MV", - "MW", - "MX", - "MY", - "MZ", - "NA", - "NE", - "NG", - "NI", - "NL", - "NO", - "NP", - "NR", - "NZ", - "OM", - "PA", - "PG", - "PH", - "PK", - "PL", - "PR", - "PS", - "PT", - "PW", - "PY", - "QA", - "RO", - "RS", - "RU", - "RW", - "SA", - "SB", - "SC", - "SD", - "SE", - "SG", - "SI", - "SK", - "SL", - "SM", - "SN", - "SO", - "SR", - "SS", - "ST", - "SV", - "SY", - "SZ", - "TD", - "TG", - "TH", - "TJ", - "TL", - "TM", - "TN", - "TO", - "TR", - "TT", - "TV", - "TW", - "TZ", - "UA", - "UG", - "US", - "UY", - "UZ", - "VA", - "VC", - "VE", - "VG", - "VN", - "VU", - "WS", - "YE", - "ZA", - "ZM", - "ZW" -]New value: +[ + "unknown", + "AD", + "AE", + "AF", + "AG", + "AI", + "AL", + "AM", + "AO", + "AR", + "AS", + "AT", + "AU", + "AW", + "AX", + "AZ", + "BA", + "BB", + "BD", + "BE", + "BF", + "BG", + "BH", + "BI", + "BJ", + "BL", + "BM", + "BN", + "BO", + "BQ", + "BR", + "BS", + "BT", + "BW", + "BY", + "BZ", + "CA", + "CD", + "CF", + "CG", + "CH", + "CI", + "CK", + "CL", + "CM", + "CN", + "CO", + "CR", + "CU", + "CV", + "CW", + "CY", + "CZ", + "DE", + "DJ", + "DK", + "DM", + "DO", + "DZ", + "EC", + "EE", + "EG", + "EH", + "ER", + "ES", + "ET", + "FI", + "FJ", + "FK", + "FM", + "FO", + "FR", + "GA", + "GB", + "GD", + "GE", + "GF", + "GG", + "GH", + "GI", + "GL", + "GM", + "GN", + "GP", + "GQ", + "GR", + "GT", + "GU", + "GW", + "GY", + "HK", + "HN", + "HR", + "HT", + "HU", + "ID", + "IE", + "IL", + "IM", + "IN", + "IQ", + "IR", + "IS", + "IT", + "JE", + "JM", + "JO", + "JP", + "KE", + "KG", + "KH", + "KI", + "KM", + "KN", + "KP", + "KR", + "KW", + "KY", + "KZ", + "LA", + "LB", + "LC", + "LI", + "LK", + "LR", + "LS", + "LT", + "LU", + "LV", + "LY", + "MA", + "MC", + "MD", + "ME", + "MF", + "MG", + "MH", + "MK", + "ML", + "MM", + "MN", + "MO", + "MP", + "MQ", + "MR", + "MS", + "MT", + "MU", + "MV", + "MW", + "MX", + "MY", + "MZ", + "NA", + "NC", + "NE", + "NG", + "NI", + "NL", + "NO", + "NP", + "NR", + "NU", + "NZ", + "OM", + "PA", + "PE", + "PF", + "PG", + "PH", + "PK", + "PL", + "PM", + "PR", + "PS", + "PT", + "PW", + "PY", + "QA", + "RE", + "RO", + "RS", + "RU", + "RW", + "SA", + "SB", + "SC", + "SD", + "SE", + "SG", + "SH", + "SI", + "SK", + "SL", + "SM", + "SN", + "SO", + "SR", + "SS", + "ST", + "SV", + "SX", + "SY", + "SZ", + "TC", + "TD", + "TG", + "TH", + "TJ", + "TK", + "TL", + "TM", + "TN", + "TO", + "TR", + "TT", + "TV", + "TW", + "TZ", + "UA", + "UG", + "US", + "UY", + "UZ", + "VA", + "VC", + "VE", + "VG", + "VI", + "VN", + "VU", + "WF", + "WS", + "YE", + "YT", + "ZA", + "ZM", + "ZW" +]
- Changed
funding_events1 field changed- changed
Input schema / properties / countries / items / enumPrevious value: -[ - "unknown", - "AD", - "AE", - "AF", - "AG", - "AL", - "AM", - "AO", - "AR", - "AT", - "AU", - "AZ", - "BA", - "BB", - "BD", - "BE", - "BF", - "BG", - "BH", - "BI", - "BJ", - "BM", - "BN", - "BO", - "BR", - "BS", - "BT", - "BW", - "BY", - "BZ", - "CA", - "CD", - "CF", - "CG", - "CH", - "CI", - "CL", - "CM", - "CN", - "CO", - "CR", - "CU", - "CV", - "CY", - "CZ", - "DE", - "DJ", - "DK", - "DM", - "DO", - "DZ", - "EC", - "EE", - "EG", - "ER", - "ES", - "ET", - "FI", - "FJ", - "FM", - "FR", - "GA", - "GB", - "GD", - "GE", - "GG", - "GH", - "GI", - "GM", - "GN", - "GQ", - "GR", - "GT", - "GW", - "GY", - "HK", - "HN", - "HR", - "HT", - "HU", - "ID", - "IE", - "IL", - "IM", - "IN", - "IQ", - "IR", - "IS", - "IT", - "JE", - "JM", - "JO", - "JP", - "KE", - "KG", - "KH", - "KI", - "KM", - "KN", - "KP", - "KR", - "KW", - "KY", - "KZ", - "LA", - "LB", - "LC", - "LI", - "LK", - "LR", - "LS", - "LT", - "LU", - "LV", - "LY", - "MA", - "MC", - "MD", - "ME", - "MG", - "MH", - "MK", - "ML", - "MM", - "MN", - "MO", - "MR", - "MT", - "MU", - "MV", - "MW", - "MX", - "MY", - "MZ", - "NA", - "NE", - "NG", - "NI", - "NL", - "NO", - "NP", - "NR", - "NZ", - "OM", - "PA", - "PG", - "PH", - "PK", - "PL", - "PR", - "PS", - "PT", - "PW", - "PY", - "QA", - "RO", - "RS", - "RU", - "RW", - "SA", - "SB", - "SC", - "SD", - "SE", - "SG", - "SI", - "SK", - "SL", - "SM", - "SN", - "SO", - "SR", - "SS", - "ST", - "SV", - "SY", - "SZ", - "TD", - "TG", - "TH", - "TJ", - "TL", - "TM", - "TN", - "TO", - "TR", - "TT", - "TV", - "TW", - "TZ", - "UA", - "UG", - "US", - "UY", - "UZ", - "VA", - "VC", - "VE", - "VG", - "VN", - "VU", - "WS", - "YE", - "ZA", - "ZM", - "ZW" -]New value: +[ + "unknown", + "AD", + "AE", + "AF", + "AG", + "AI", + "AL", + "AM", + "AO", + "AR", + "AS", + "AT", + "AU", + "AW", + "AX", + "AZ", + "BA", + "BB", + "BD", + "BE", + "BF", + "BG", + "BH", + "BI", + "BJ", + "BL", + "BM", + "BN", + "BO", + "BQ", + "BR", + "BS", + "BT", + "BW", + "BY", + "BZ", + "CA", + "CD", + "CF", + "CG", + "CH", + "CI", + "CK", + "CL", + "CM", + "CN", + "CO", + "CR", + "CU", + "CV", + "CW", + "CY", + "CZ", + "DE", + "DJ", + "DK", + "DM", + "DO", + "DZ", + "EC", + "EE", + "EG", + "EH", + "ER", + "ES", + "ET", + "FI", + "FJ", + "FK", + "FM", + "FO", + "FR", + "GA", + "GB", + "GD", + "GE", + "GF", + "GG", + "GH", + "GI", + "GL", + "GM", + "GN", + "GP", + "GQ", + "GR", + "GT", + "GU", + "GW", + "GY", + "HK", + "HN", + "HR", + "HT", + "HU", + "ID", + "IE", + "IL", + "IM", + "IN", + "IQ", + "IR", + "IS", + "IT", + "JE", + "JM", + "JO", + "JP", + "KE", + "KG", + "KH", + "KI", + "KM", + "KN", + "KP", + "KR", + "KW", + "KY", + "KZ", + "LA", + "LB", + "LC", + "LI", + "LK", + "LR", + "LS", + "LT", + "LU", + "LV", + "LY", + "MA", + "MC", + "MD", + "ME", + "MF", + "MG", + "MH", + "MK", + "ML", + "MM", + "MN", + "MO", + "MP", + "MQ", + "MR", + "MS", + "MT", + "MU", + "MV", + "MW", + "MX", + "MY", + "MZ", + "NA", + "NC", + "NE", + "NG", + "NI", + "NL", + "NO", + "NP", + "NR", + "NU", + "NZ", + "OM", + "PA", + "PE", + "PF", + "PG", + "PH", + "PK", + "PL", + "PM", + "PR", + "PS", + "PT", + "PW", + "PY", + "QA", + "RE", + "RO", + "RS", + "RU", + "RW", + "SA", + "SB", + "SC", + "SD", + "SE", + "SG", + "SH", + "SI", + "SK", + "SL", + "SM", + "SN", + "SO", + "SR", + "SS", + "ST", + "SV", + "SX", + "SY", + "SZ", + "TC", + "TD", + "TG", + "TH", + "TJ", + "TK", + "TL", + "TM", + "TN", + "TO", + "TR", + "TT", + "TV", + "TW", + "TZ", + "UA", + "UG", + "US", + "UY", + "UZ", + "VA", + "VC", + "VE", + "VG", + "VI", + "VN", + "VU", + "WF", + "WS", + "YE", + "YT", + "ZA", + "ZM", + "ZW" +]
- Changed
investors2 fields changed- changed
Input schema / properties / countries / items / enumPrevious value: -[ - "unknown", - "AD", - "AE", - "AF", - "AG", - "AL", - "AM", - "AO", - "AR", - "AT", - "AU", - "AZ", - "BA", - "BB", - "BD", - "BE", - "BF", - "BG", - "BH", - "BI", - "BJ", - "BM", - "BN", - "BO", - "BR", - "BS", - "BT", - "BW", - "BY", - "BZ", - "CA", - "CD", - "CF", - "CG", - "CH", - "CI", - "CL", - "CM", - "CN", - "CO", - "CR", - "CU", - "CV", - "CY", - "CZ", - "DE", - "DJ", - "DK", - "DM", - "DO", - "DZ", - "EC", - "EE", - "EG", - "ER", - "ES", - "ET", - "FI", - "FJ", - "FM", - "FR", - "GA", - "GB", - "GD", - "GE", - "GG", - "GH", - "GI", - "GM", - "GN", - "GQ", - "GR", - "GT", - "GW", - "GY", - "HK", - "HN", - "HR", - "HT", - "HU", - "ID", - "IE", - "IL", - "IM", - "IN", - "IQ", - "IR", - "IS", - "IT", - "JE", - "JM", - "JO", - "JP", - "KE", - "KG", - "KH", - "KI", - "KM", - "KN", - "KP", - "KR", - "KW", - "KY", - "KZ", - "LA", - "LB", - "LC", - "LI", - "LK", - "LR", - "LS", - "LT", - "LU", - "LV", - "LY", - "MA", - "MC", - "MD", - "ME", - "MG", - "MH", - "MK", - "ML", - "MM", - "MN", - "MO", - "MR", - "MT", - "MU", - "MV", - "MW", - "MX", - "MY", - "MZ", - "NA", - "NE", - "NG", - "NI", - "NL", - "NO", - "NP", - "NR", - "NZ", - "OM", - "PA", - "PG", - "PH", - "PK", - "PL", - "PR", - "PS", - "PT", - "PW", - "PY", - "QA", - "RO", - "RS", - "RU", - "RW", - "SA", - "SB", - "SC", - "SD", - "SE", - "SG", - "SI", - "SK", - "SL", - "SM", - "SN", - "SO", - "SR", - "SS", - "ST", - "SV", - "SY", - "SZ", - "TD", - "TG", - "TH", - "TJ", - "TL", - "TM", - "TN", - "TO", - "TR", - "TT", - "TV", - "TW", - "TZ", - "UA", - "UG", - "US", - "UY", - "UZ", - "VA", - "VC", - "VE", - "VG", - "VN", - "VU", - "WS", - "YE", - "ZA", - "ZM", - "ZW" -]New value: +[ + "unknown", + "AD", + "AE", + "AF", + "AG", + "AI", + "AL", + "AM", + "AO", + "AR", + "AS", + "AT", + "AU", + "AW", + "AX", + "AZ", + "BA", + "BB", + "BD", + "BE", + "BF", + "BG", + "BH", + "BI", + "BJ", + "BL", + "BM", + "BN", + "BO", + "BQ", + "BR", + "BS", + "BT", + "BW", + "BY", + "BZ", + "CA", + "CD", + "CF", + "CG", + "CH", + "CI", + "CK", + "CL", + "CM", + "CN", + "CO", + "CR", + "CU", + "CV", + "CW", + "CY", + "CZ", + "DE", + "DJ", + "DK", + "DM", + "DO", + "DZ", + "EC", + "EE", + "EG", + "EH", + "ER", + "ES", + "ET", + "FI", + "FJ", + "FK", + "FM", + "FO", + "FR", + "GA", + "GB", + "GD", + "GE", + "GF", + "GG", + "GH", + "GI", + "GL", + "GM", + "GN", + "GP", + "GQ", + "GR", + "GT", + "GU", + "GW", + "GY", + "HK", + "HN", + "HR", + "HT", + "HU", + "ID", + "IE", + "IL", + "IM", + "IN", + "IQ", + "IR", + "IS", + "IT", + "JE", + "JM", + "JO", + "JP", + "KE", + "KG", + "KH", + "KI", + "KM", + "KN", + "KP", + "KR", + "KW", + "KY", + "KZ", + "LA", + "LB", + "LC", + "LI", + "LK", + "LR", + "LS", + "LT", + "LU", + "LV", + "LY", + "MA", + "MC", + "MD", + "ME", + "MF", + "MG", + "MH", + "MK", + "ML", + "MM", + "MN", + "MO", + "MP", + "MQ", + "MR", + "MS", + "MT", + "MU", + "MV", + "MW", + "MX", + "MY", + "MZ", + "NA", + "NC", + "NE", + "NG", + "NI", + "NL", + "NO", + "NP", + "NR", + "NU", + "NZ", + "OM", + "PA", + "PE", + "PF", + "PG", + "PH", + "PK", + "PL", + "PM", + "PR", + "PS", + "PT", + "PW", + "PY", + "QA", + "RE", + "RO", + "RS", + "RU", + "RW", + "SA", + "SB", + "SC", + "SD", + "SE", + "SG", + "SH", + "SI", + "SK", + "SL", + "SM", + "SN", + "SO", + "SR", + "SS", + "ST", + "SV", + "SX", + "SY", + "SZ", + "TC", + "TD", + "TG", + "TH", + "TJ", + "TK", + "TL", + "TM", + "TN", + "TO", + "TR", + "TT", + "TV", + "TW", + "TZ", + "UA", + "UG", + "US", + "UY", + "UZ", + "VA", + "VC", + "VE", + "VG", + "VI", + "VN", + "VU", + "WF", + "WS", + "YE", + "YT", + "ZA", + "ZM", + "ZW" +] - added
Input schema / properties / investsInAdded value: +{ + "description": "Only investors that have funded companies headquartered in these countries (OR), e.g. [\"US\"]. Filters on where an investor deploys rather than where it is registered, and is far better covered than HQ country.", + "items": { + "type": "string" + }, + "type": "array" +}
1 tool update
- Changed
investors3 fields changed- added
Input schema / properties / activeSinceAdded value: +{ + "description": "Only investors whose most recent round was announced on or after this date (YYYY-MM-DD).", + "type": "string" +} - added
Input schema / properties / minRoundUsdAdded value: +{ + "description": "Only investors that have participated in at least one round at or above this amount, in whole USD. Filters on behaviour rather than on a type label, which is sparse.", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" +} - added
Input schema / properties / minRoundsAdded value: +{ + "description": "Only investors that have participated in at least this many rounds.", + "maximum": 9007199254740991, + "minimum": 1, + "type": "integer" +}
5 tool updates
- Changed
acquisitions1 field changed- added
Input schema / properties / countries / items / enumAdded value: +[ + "unknown", + "AD", + "AE", + "AF", + "AG", + "AL", + "AM", + "AO", + "AR", + "AT", + "AU", + "AZ", + "BA", + "BB", + "BD", + "BE", + "BF", + "BG", + "BH", + "BI", + "BJ", + "BM", + "BN", + "BO", + "BR", + "BS", + "BT", + "BW", + "BY", + "BZ", + "CA", + "CD", + "CF", + "CG", + "CH", + "CI", + "CL", + "CM", + "CN", + "CO", + "CR", + "CU", + "CV", + "CY", + "CZ", + "DE", + "DJ", + "DK", + "DM", + "DO", + "DZ", + "EC", + "EE", + "EG", + "ER", + "ES", + "ET", + "FI", + "FJ", + "FM", + "FR", + "GA", + "GB", + "GD", + "GE", + "GG", + "GH", + "GI", + "GM", + "GN", + "GQ", + "GR", + "GT", + "GW", + "GY", + "HK", + "HN", + "HR", + "HT", + "HU", + "ID", + "IE", + "IL", + "IM", + "IN", + "IQ", + "IR", + "IS", + "IT", + "JE", + "JM", + "JO", + "JP", + "KE", + "KG", + "KH", + "KI", + "KM", + "KN", + "KP", + "KR", + "KW", + "KY", + "KZ", + "LA", + "LB", + "LC", + "LI", + "LK", + "LR", + "LS", + "LT", + "LU", + "LV", + "LY", + "MA", + "MC", + "MD", + "ME", + "MG", + "MH", + "MK", + "ML", + "MM", + "MN", + "MO", + "MR", + "MT", + "MU", + "MV", + "MW", + "MX", + "MY", + "MZ", + "NA", + "NE", + "NG", + "NI", + "NL", + "NO", + "NP", + "NR", + "NZ", + "OM", + "PA", + "PG", + "PH", + "PK", + "PL", + "PR", + "PS", + "PT", + "PW", + "PY", + "QA", + "RO", + "RS", + "RU", + "RW", + "SA", + "SB", + "SC", + "SD", + "SE", + "SG", + "SI", + "SK", + "SL", + "SM", + "SN", + "SO", + "SR", + "SS", + "ST", + "SV", + "SY", + "SZ", + "TD", + "TG", + "TH", + "TJ", + "TL", + "TM", + "TN", + "TO", + "TR", + "TT", + "TV", + "TW", + "TZ", + "UA", + "UG", + "US", + "UY", + "UZ", + "VA", + "VC", + "VE", + "VG", + "VN", + "VU", + "WS", + "YE", + "ZA", + "ZM", + "ZW" +]
- Changed
companies1 field changed- added
Input schema / properties / countries / items / enumAdded value: +[ + "unknown", + "AD", + "AE", + "AF", + "AG", + "AL", + "AM", + "AO", + "AR", + "AT", + "AU", + "AZ", + "BA", + "BB", + "BD", + "BE", + "BF", + "BG", + "BH", + "BI", + "BJ", + "BM", + "BN", + "BO", + "BR", + "BS", + "BT", + "BW", + "BY", + "BZ", + "CA", + "CD", + "CF", + "CG", + "CH", + "CI", + "CL", + "CM", + "CN", + "CO", + "CR", + "CU", + "CV", + "CY", + "CZ", + "DE", + "DJ", + "DK", + "DM", + "DO", + "DZ", + "EC", + "EE", + "EG", + "ER", + "ES", + "ET", + "FI", + "FJ", + "FM", + "FR", + "GA", + "GB", + "GD", + "GE", + "GG", + "GH", + "GI", + "GM", + "GN", + "GQ", + "GR", + "GT", + "GW", + "GY", + "HK", + "HN", + "HR", + "HT", + "HU", + "ID", + "IE", + "IL", + "IM", + "IN", + "IQ", + "IR", + "IS", + "IT", + "JE", + "JM", + "JO", + "JP", + "KE", + "KG", + "KH", + "KI", + "KM", + "KN", + "KP", + "KR", + "KW", + "KY", + "KZ", + "LA", + "LB", + "LC", + "LI", + "LK", + "LR", + "LS", + "LT", + "LU", + "LV", + "LY", + "MA", + "MC", + "MD", + "ME", + "MG", + "MH", + "MK", + "ML", + "MM", + "MN", + "MO", + "MR", + "MT", + "MU", + "MV", + "MW", + "MX", + "MY", + "MZ", + "NA", + "NE", + "NG", + "NI", + "NL", + "NO", + "NP", + "NR", + "NZ", + "OM", + "PA", + "PG", + "PH", + "PK", + "PL", + "PR", + "PS", + "PT", + "PW", + "PY", + "QA", + "RO", + "RS", + "RU", + "RW", + "SA", + "SB", + "SC", + "SD", + "SE", + "SG", + "SI", + "SK", + "SL", + "SM", + "SN", + "SO", + "SR", + "SS", + "ST", + "SV", + "SY", + "SZ", + "TD", + "TG", + "TH", + "TJ", + "TL", + "TM", + "TN", + "TO", + "TR", + "TT", + "TV", + "TW", + "TZ", + "UA", + "UG", + "US", + "UY", + "UZ", + "VA", + "VC", + "VE", + "VG", + "VN", + "VU", + "WS", + "YE", + "ZA", + "ZM", + "ZW" +]
- Changed
exec_moves1 field changed- added
Input schema / properties / countries / items / enumAdded value: +[ + "unknown", + "AD", + "AE", + "AF", + "AG", + "AL", + "AM", + "AO", + "AR", + "AT", + "AU", + "AZ", + "BA", + "BB", + "BD", + "BE", + "BF", + "BG", + "BH", + "BI", + "BJ", + "BM", + "BN", + "BO", + "BR", + "BS", + "BT", + "BW", + "BY", + "BZ", + "CA", + "CD", + "CF", + "CG", + "CH", + "CI", + "CL", + "CM", + "CN", + "CO", + "CR", + "CU", + "CV", + "CY", + "CZ", + "DE", + "DJ", + "DK", + "DM", + "DO", + "DZ", + "EC", + "EE", + "EG", + "ER", + "ES", + "ET", + "FI", + "FJ", + "FM", + "FR", + "GA", + "GB", + "GD", + "GE", + "GG", + "GH", + "GI", + "GM", + "GN", + "GQ", + "GR", + "GT", + "GW", + "GY", + "HK", + "HN", + "HR", + "HT", + "HU", + "ID", + "IE", + "IL", + "IM", + "IN", + "IQ", + "IR", + "IS", + "IT", + "JE", + "JM", + "JO", + "JP", + "KE", + "KG", + "KH", + "KI", + "KM", + "KN", + "KP", + "KR", + "KW", + "KY", + "KZ", + "LA", + "LB", + "LC", + "LI", + "LK", + "LR", + "LS", + "LT", + "LU", + "LV", + "LY", + "MA", + "MC", + "MD", + "ME", + "MG", + "MH", + "MK", + "ML", + "MM", + "MN", + "MO", + "MR", + "MT", + "MU", + "MV", + "MW", + "MX", + "MY", + "MZ", + "NA", + "NE", + "NG", + "NI", + "NL", + "NO", + "NP", + "NR", + "NZ", + "OM", + "PA", + "PG", + "PH", + "PK", + "PL", + "PR", + "PS", + "PT", + "PW", + "PY", + "QA", + "RO", + "RS", + "RU", + "RW", + "SA", + "SB", + "SC", + "SD", + "SE", + "SG", + "SI", + "SK", + "SL", + "SM", + "SN", + "SO", + "SR", + "SS", + "ST", + "SV", + "SY", + "SZ", + "TD", + "TG", + "TH", + "TJ", + "TL", + "TM", + "TN", + "TO", + "TR", + "TT", + "TV", + "TW", + "TZ", + "UA", + "UG", + "US", + "UY", + "UZ", + "VA", + "VC", + "VE", + "VG", + "VN", + "VU", + "WS", + "YE", + "ZA", + "ZM", + "ZW" +]
- Changed
funding_events1 field changed- added
Input schema / properties / countries / items / enumAdded value: +[ + "unknown", + "AD", + "AE", + "AF", + "AG", + "AL", + "AM", + "AO", + "AR", + "AT", + "AU", + "AZ", + "BA", + "BB", + "BD", + "BE", + "BF", + "BG", + "BH", + "BI", + "BJ", + "BM", + "BN", + "BO", + "BR", + "BS", + "BT", + "BW", + "BY", + "BZ", + "CA", + "CD", + "CF", + "CG", + "CH", + "CI", + "CL", + "CM", + "CN", + "CO", + "CR", + "CU", + "CV", + "CY", + "CZ", + "DE", + "DJ", + "DK", + "DM", + "DO", + "DZ", + "EC", + "EE", + "EG", + "ER", + "ES", + "ET", + "FI", + "FJ", + "FM", + "FR", + "GA", + "GB", + "GD", + "GE", + "GG", + "GH", + "GI", + "GM", + "GN", + "GQ", + "GR", + "GT", + "GW", + "GY", + "HK", + "HN", + "HR", + "HT", + "HU", + "ID", + "IE", + "IL", + "IM", + "IN", + "IQ", + "IR", + "IS", + "IT", + "JE", + "JM", + "JO", + "JP", + "KE", + "KG", + "KH", + "KI", + "KM", + "KN", + "KP", + "KR", + "KW", + "KY", + "KZ", + "LA", + "LB", + "LC", + "LI", + "LK", + "LR", + "LS", + "LT", + "LU", + "LV", + "LY", + "MA", + "MC", + "MD", + "ME", + "MG", + "MH", + "MK", + "ML", + "MM", + "MN", + "MO", + "MR", + "MT", + "MU", + "MV", + "MW", + "MX", + "MY", + "MZ", + "NA", + "NE", + "NG", + "NI", + "NL", + "NO", + "NP", + "NR", + "NZ", + "OM", + "PA", + "PG", + "PH", + "PK", + "PL", + "PR", + "PS", + "PT", + "PW", + "PY", + "QA", + "RO", + "RS", + "RU", + "RW", + "SA", + "SB", + "SC", + "SD", + "SE", + "SG", + "SI", + "SK", + "SL", + "SM", + "SN", + "SO", + "SR", + "SS", + "ST", + "SV", + "SY", + "SZ", + "TD", + "TG", + "TH", + "TJ", + "TL", + "TM", + "TN", + "TO", + "TR", + "TT", + "TV", + "TW", + "TZ", + "UA", + "UG", + "US", + "UY", + "UZ", + "VA", + "VC", + "VE", + "VG", + "VN", + "VU", + "WS", + "YE", + "ZA", + "ZM", + "ZW" +]
- Changed
investors1 field changed- added
Input schema / properties / countries / items / enumAdded value: +[ + "unknown", + "AD", + "AE", + "AF", + "AG", + "AL", + "AM", + "AO", + "AR", + "AT", + "AU", + "AZ", + "BA", + "BB", + "BD", + "BE", + "BF", + "BG", + "BH", + "BI", + "BJ", + "BM", + "BN", + "BO", + "BR", + "BS", + "BT", + "BW", + "BY", + "BZ", + "CA", + "CD", + "CF", + "CG", + "CH", + "CI", + "CL", + "CM", + "CN", + "CO", + "CR", + "CU", + "CV", + "CY", + "CZ", + "DE", + "DJ", + "DK", + "DM", + "DO", + "DZ", + "EC", + "EE", + "EG", + "ER", + "ES", + "ET", + "FI", + "FJ", + "FM", + "FR", + "GA", + "GB", + "GD", + "GE", + "GG", + "GH", + "GI", + "GM", + "GN", + "GQ", + "GR", + "GT", + "GW", + "GY", + "HK", + "HN", + "HR", + "HT", + "HU", + "ID", + "IE", + "IL", + "IM", + "IN", + "IQ", + "IR", + "IS", + "IT", + "JE", + "JM", + "JO", + "JP", + "KE", + "KG", + "KH", + "KI", + "KM", + "KN", + "KP", + "KR", + "KW", + "KY", + "KZ", + "LA", + "LB", + "LC", + "LI", + "LK", + "LR", + "LS", + "LT", + "LU", + "LV", + "LY", + "MA", + "MC", + "MD", + "ME", + "MG", + "MH", + "MK", + "ML", + "MM", + "MN", + "MO", + "MR", + "MT", + "MU", + "MV", + "MW", + "MX", + "MY", + "MZ", + "NA", + "NE", + "NG", + "NI", + "NL", + "NO", + "NP", + "NR", + "NZ", + "OM", + "PA", + "PG", + "PH", + "PK", + "PL", + "PR", + "PS", + "PT", + "PW", + "PY", + "QA", + "RO", + "RS", + "RU", + "RW", + "SA", + "SB", + "SC", + "SD", + "SE", + "SG", + "SI", + "SK", + "SL", + "SM", + "SN", + "SO", + "SR", + "SS", + "ST", + "SV", + "SY", + "SZ", + "TD", + "TG", + "TH", + "TJ", + "TL", + "TM", + "TN", + "TO", + "TR", + "TT", + "TV", + "TW", + "TZ", + "UA", + "UG", + "US", + "UY", + "UZ", + "VA", + "VC", + "VE", + "VG", + "VN", + "VU", + "WS", + "YE", + "ZA", + "ZM", + "ZW" +]
5 tool updates
- Changed
acquisitions3 fields changed- added
Input schema / properties / countriesAdded value: +{ + "description": "Headquarters country codes (ISO alpha-2, OR). Pass \"unknown\" to include companies with no country on file.", + "items": { + "type": "string" + }, + "type": "array" +} - added
Input schema / properties / industryGroupsAdded value: +{ + "description": "Company industry groups (OR). Matched literally against the LinkedIn labels. Pass \"unknown\" for companies with no industry on file.", + "items": { + "type": "string" + }, + "type": "array" +} - added
Input schema / properties / untilAdded value: +{ + "description": "Return records announced on or before this date (YYYY-MM-DD, inclusive) or ISO-8601 timestamp.", + "type": "string" +}
- Changed
companies6 fields changed- added
Input schema / properties / countriesAdded value: +{ + "description": "Headquarters country codes (ISO alpha-2, OR). Pass \"unknown\" to include companies with no country on file.", + "items": { + "type": "string" + }, + "type": "array" +} - removed
Input schema / properties / countryRemoved value: -{ - "description": "Headquarters country code (ISO alpha-2).", - "type": "string" -} - removed
Input schema / properties / employeeCountBucketRemoved value: -{ - "description": "LinkedIn employee count bucket, e.g. 51-200.", - "type": "string" -} - added
Input schema / properties / employeeCountBucketsAdded value: +{ + "description": "LinkedIn employee count buckets (OR), e.g. 51-200. Pass \"unknown\" for no headcount.", + "items": { + "type": "string" + }, + "type": "array" +} - removed
Input schema / properties / industryGroupRemoved value: -{ - "description": "Company industry group.", - "type": "string" -} - added
Input schema / properties / industryGroupsAdded value: +{ + "description": "Company industry groups (OR). Matched literally against the LinkedIn labels. Pass \"unknown\" for companies with no industry on file.", + "items": { + "type": "string" + }, + "type": "array" +}
- Changed
exec_moves2 fields changed- added
Input schema / properties / countriesAdded value: +{ + "description": "Headquarters country codes (ISO alpha-2, OR). Pass \"unknown\" to include companies with no country on file.", + "items": { + "type": "string" + }, + "type": "array" +} - changed
Input schema / properties / until / descriptionPrevious value: -"Return events announced on or before this date (YYYY-MM-DD, inclusive) or ISO-8601 timestamp."New value: +"Return records announced on or before this date (YYYY-MM-DD, inclusive) or ISO-8601 timestamp."
- Changed
funding_events6 fields changed- added
Input schema / properties / countriesAdded value: +{ + "description": "Headquarters country codes (ISO alpha-2, OR). Pass \"unknown\" to include companies with no country on file.", + "items": { + "type": "string" + }, + "type": "array" +} - removed
Input schema / properties / countryRemoved value: -{ - "description": "Company headquarters country code (ISO alpha-2).", - "type": "string" -} - added
Input schema / properties / employeeBucketsAdded value: +{ + "description": "Company employee-count buckets (OR). Canonical values: 1-10, 11-50, 51-200, 201-500, 501-1000, 1001-5000, 5001-10000, 10001+.", + "items": { + "enum": [ + "1-10", + "11-50", + "51-200", + "201-500", + "501-1000", + "1001-5000", + "5001-10000", + "10001+", + "unknown" + ], + "type": "string" + }, + "type": "array" +} - removed
Input schema / properties / industryGroupRemoved value: -{ - "description": "Company industry group.", - "type": "string" -} - added
Input schema / properties / industryGroupsAdded value: +{ + "description": "Company industry groups (OR). Matched literally against the LinkedIn labels. Pass \"unknown\" for companies with no industry on file.", + "items": { + "type": "string" + }, + "type": "array" +} - added
Input schema / properties / untilAdded value: +{ + "description": "Return records announced on or before this date (YYYY-MM-DD, inclusive) or ISO-8601 timestamp.", + "type": "string" +}
- Changed
investors3 fields changed- added
Input schema / properties / countriesAdded value: +{ + "description": "Headquarters country codes (ISO alpha-2, OR). Pass \"unknown\" to include companies with no country on file.", + "items": { + "type": "string" + }, + "type": "array" +} - removed
Input schema / properties / countryRemoved value: -{ - "description": "Headquarters country code (ISO alpha-2).", - "type": "string" -} - added
Input schema / properties / hasFirmographicsAdded value: +{ + "description": "Only investors whose domain and type we have resolved.", + "type": "boolean" +}
4 tool updates
- Changed
acquisitions1 field changed- added
Input schema / properties / naicsCodeAdded value: +{ + "description": "NAICS 2022 code for the target (acquired) company. Matches the code and everything beneath it, so \"51\" also returns 5132 and 5173. Sector ranges work: \"31-33\" returns all manufacturing.", + "enum": [ + "11", + "21", + "22", + "23", + "42", + "51", + "52", + "53", + "54", + "56", + "71", + "81", + "92", + "111", + "113", + "114", + "212", + "236", + "238", + "311", + "313", + "315", + "316", + "321", + "322", + "323", + "325", + "327", + "331", + "332", + "335", + "336", + "337", + "458", + "482", + "483", + "484", + "485", + "493", + "519", + "532", + "562", + "611", + "621", + "622", + "623", + "712", + "721", + "722", + "811", + "812", + "813", + "1114", + "2111", + "2211", + "2213", + "2361", + "2382", + "3111", + "3115", + "3116", + "3117", + "3118", + "3121", + "3122", + "3162", + "3222", + "3253", + "3254", + "3255", + "3256", + "3261", + "3272", + "3323", + "3325", + "3328", + "3331", + "3332", + "3334", + "3341", + "3342", + "3343", + "3344", + "3345", + "3351", + "3352", + "3353", + "3359", + "3361", + "3363", + "3364", + "3365", + "3366", + "3372", + "3391", + "3399", + "4231", + "4233", + "4234", + "4235", + "4236", + "4238", + "4244", + "4245", + "4246", + "4247", + "4248", + "4411", + "4441", + "4451", + "4491", + "4561", + "4571", + "4591", + "4593", + "4811", + "4851", + "4853", + "4921", + "5121", + "5122", + "5131", + "5132", + "5161", + "5162", + "5173", + "5192", + "5221", + "5231", + "5239", + "5241", + "5242", + "5311", + "5312", + "5322", + "5411", + "5412", + "5413", + "5414", + "5415", + "5416", + "5417", + "5418", + "5419", + "5511", + "5613", + "5614", + "5615", + "5616", + "5617", + "5621", + "6111", + "6113", + "6114", + "6115", + "6213", + "6214", + "6215", + "6216", + "6241", + "6242", + "6244", + "7111", + "7112", + "7115", + "7132", + "7139", + "7225", + "8111", + "8121", + "8123", + "8129", + "8131", + "8132", + "8134", + "8139", + "9211", + "9221", + "9281", + "unknown", + "31-33", + "44-45", + "48-49" + ], + "type": "string" +}
- Changed
companies1 field changed- added
Input schema / properties / naicsCode / enumAdded value: +[ + "11", + "21", + "22", + "23", + "42", + "51", + "52", + "53", + "54", + "56", + "71", + "81", + "92", + "111", + "113", + "114", + "212", + "236", + "238", + "311", + "313", + "315", + "316", + "321", + "322", + "323", + "325", + "327", + "331", + "332", + "335", + "336", + "337", + "458", + "482", + "483", + "484", + "485", + "493", + "519", + "532", + "562", + "611", + "621", + "622", + "623", + "712", + "721", + "722", + "811", + "812", + "813", + "1114", + "2111", + "2211", + "2213", + "2361", + "2382", + "3111", + "3115", + "3116", + "3117", + "3118", + "3121", + "3122", + "3162", + "3222", + "3253", + "3254", + "3255", + "3256", + "3261", + "3272", + "3323", + "3325", + "3328", + "3331", + "3332", + "3334", + "3341", + "3342", + "3343", + "3344", + "3345", + "3351", + "3352", + "3353", + "3359", + "3361", + "3363", + "3364", + "3365", + "3366", + "3372", + "3391", + "3399", + "4231", + "4233", + "4234", + "4235", + "4236", + "4238", + "4244", + "4245", + "4246", + "4247", + "4248", + "4411", + "4441", + "4451", + "4491", + "4561", + "4571", + "4591", + "4593", + "4811", + "4851", + "4853", + "4921", + "5121", + "5122", + "5131", + "5132", + "5161", + "5162", + "5173", + "5192", + "5221", + "5231", + "5239", + "5241", + "5242", + "5311", + "5312", + "5322", + "5411", + "5412", + "5413", + "5414", + "5415", + "5416", + "5417", + "5418", + "5419", + "5511", + "5613", + "5614", + "5615", + "5616", + "5617", + "5621", + "6111", + "6113", + "6114", + "6115", + "6213", + "6214", + "6215", + "6216", + "6241", + "6242", + "6244", + "7111", + "7112", + "7115", + "7132", + "7139", + "7225", + "8111", + "8121", + "8123", + "8129", + "8131", + "8132", + "8134", + "8139", + "9211", + "9221", + "9281", + "unknown", + "31-33", + "44-45", + "48-49" +]
- Changed
exec_moves1 field changed- added
Input schema / properties / naicsCodeAdded value: +{ + "description": "NAICS 2022 code for the company. Matches the code and everything beneath it, so \"51\" also returns 5132 and 5173. Sector ranges work: \"31-33\" returns all manufacturing.", + "enum": [ + "11", + "21", + "22", + "23", + "42", + "51", + "52", + "53", + "54", + "56", + "71", + "81", + "92", + "111", + "113", + "114", + "212", + "236", + "238", + "311", + "313", + "315", + "316", + "321", + "322", + "323", + "325", + "327", + "331", + "332", + "335", + "336", + "337", + "458", + "482", + "483", + "484", + "485", + "493", + "519", + "532", + "562", + "611", + "621", + "622", + "623", + "712", + "721", + "722", + "811", + "812", + "813", + "1114", + "2111", + "2211", + "2213", + "2361", + "2382", + "3111", + "3115", + "3116", + "3117", + "3118", + "3121", + "3122", + "3162", + "3222", + "3253", + "3254", + "3255", + "3256", + "3261", + "3272", + "3323", + "3325", + "3328", + "3331", + "3332", + "3334", + "3341", + "3342", + "3343", + "3344", + "3345", + "3351", + "3352", + "3353", + "3359", + "3361", + "3363", + "3364", + "3365", + "3366", + "3372", + "3391", + "3399", + "4231", + "4233", + "4234", + "4235", + "4236", + "4238", + "4244", + "4245", + "4246", + "4247", + "4248", + "4411", + "4441", + "4451", + "4491", + "4561", + "4571", + "4591", + "4593", + "4811", + "4851", + "4853", + "4921", + "5121", + "5122", + "5131", + "5132", + "5161", + "5162", + "5173", + "5192", + "5221", + "5231", + "5239", + "5241", + "5242", + "5311", + "5312", + "5322", + "5411", + "5412", + "5413", + "5414", + "5415", + "5416", + "5417", + "5418", + "5419", + "5511", + "5613", + "5614", + "5615", + "5616", + "5617", + "5621", + "6111", + "6113", + "6114", + "6115", + "6213", + "6214", + "6215", + "6216", + "6241", + "6242", + "6244", + "7111", + "7112", + "7115", + "7132", + "7139", + "7225", + "8111", + "8121", + "8123", + "8129", + "8131", + "8132", + "8134", + "8139", + "9211", + "9221", + "9281", + "unknown", + "31-33", + "44-45", + "48-49" + ], + "type": "string" +}
- Changed
funding_events1 field changed- added
Input schema / properties / naicsCodeAdded value: +{ + "description": "NAICS 2022 code for the company. Matches the code and everything beneath it, so \"51\" also returns 5132 and 5173. Sector ranges work: \"31-33\" returns all manufacturing.", + "enum": [ + "11", + "21", + "22", + "23", + "42", + "51", + "52", + "53", + "54", + "56", + "71", + "81", + "92", + "111", + "113", + "114", + "212", + "236", + "238", + "311", + "313", + "315", + "316", + "321", + "322", + "323", + "325", + "327", + "331", + "332", + "335", + "336", + "337", + "458", + "482", + "483", + "484", + "485", + "493", + "519", + "532", + "562", + "611", + "621", + "622", + "623", + "712", + "721", + "722", + "811", + "812", + "813", + "1114", + "2111", + "2211", + "2213", + "2361", + "2382", + "3111", + "3115", + "3116", + "3117", + "3118", + "3121", + "3122", + "3162", + "3222", + "3253", + "3254", + "3255", + "3256", + "3261", + "3272", + "3323", + "3325", + "3328", + "3331", + "3332", + "3334", + "3341", + "3342", + "3343", + "3344", + "3345", + "3351", + "3352", + "3353", + "3359", + "3361", + "3363", + "3364", + "3365", + "3366", + "3372", + "3391", + "3399", + "4231", + "4233", + "4234", + "4235", + "4236", + "4238", + "4244", + "4245", + "4246", + "4247", + "4248", + "4411", + "4441", + "4451", + "4491", + "4561", + "4571", + "4591", + "4593", + "4811", + "4851", + "4853", + "4921", + "5121", + "5122", + "5131", + "5132", + "5161", + "5162", + "5173", + "5192", + "5221", + "5231", + "5239", + "5241", + "5242", + "5311", + "5312", + "5322", + "5411", + "5412", + "5413", + "5414", + "5415", + "5416", + "5417", + "5418", + "5419", + "5511", + "5613", + "5614", + "5615", + "5616", + "5617", + "5621", + "6111", + "6113", + "6114", + "6115", + "6213", + "6214", + "6215", + "6216", + "6241", + "6242", + "6244", + "7111", + "7112", + "7115", + "7132", + "7139", + "7225", + "8111", + "8121", + "8123", + "8129", + "8131", + "8132", + "8134", + "8139", + "9211", + "9221", + "9281", + "unknown", + "31-33", + "44-45", + "48-49" + ], + "type": "string" +}
4 tool updates
- Changed
acquisitions1 field changed- added
Input schema / properties / paymentType / items / enumAdded value: +[ + "cash", + "stock", + "mixed", + "undisclosed" +]
- Changed
companies1 field changed- added
Input schema / properties / naicsCodeAdded value: +{ + "description": "NAICS 2022 code. Matches the code and everything beneath it, so \"51\" also returns 5132 and 5173. Sector ranges work: \"31-33\" returns all manufacturing. Pass \"unknown\" for unclassified companies.", + "type": "string" +}
- Changed
exec_moves2 fields changed- added
Input schema / properties / moveType / items / enumAdded value: +[ + "appointment", + "promotion", + "departure", + "transition" +] - added
Input schema / properties / roleSeniority / items / enumAdded value: +[ + "c_level", + "vp_level", + "founder" +]
- Changed
funding_events1 field changed- added
Input schema / properties / round / items / enumAdded value: +[ + "pre-seed", + "seed", + "angel", + "series-a", + "series-b", + "series-c", + "series-d", + "series-e", + "series-f", + "series-g", + "series-h", + "series-i", + "growth", + "extension", + "bridge", + "convertible", + "safe", + "debt", + "grant", + "pre-ipo", + "secondary", + "pipe", + "other", + "unknown" +]
2 tool updates
- Changed
acquisitions1 field changed- changed
Input schema / properties / verticals / descriptionPrevious value: -"Target company sector filters (OR). Canonical values: ai, fintech, saas, devtools, healthcare, climate, robotics, cybersecurity, logistics, commerce, data, crypto."New value: +"Target company sector filters (OR). Canonical values: ai, fintech, saas, devtools, healthcare, climate, robotics, cybersecurity, logistics, commerce, data, crypto, media, education, marketing, telecom, realestate, hardware, gaming, space."
- Changed
funding_events1 field changed- changed
Input schema / properties / verticals / descriptionPrevious value: -"High-level sector filters (OR). Canonical values: ai, fintech, saas, devtools, healthcare, climate, robotics, cybersecurity, logistics, commerce, data, crypto."New value: +"High-level sector filters (OR). Canonical values: ai, fintech, saas, devtools, healthcare, climate, robotics, cybersecurity, logistics, commerce, data, crypto, media, education, marketing, telecom, realestate, hardware, gaming, space."
3 tool updates
- Changed
acquisitions1 field changed- changed
Input schema / properties / since / descriptionPrevious value: -"Return records discovered/announced on or after this date (YYYY-MM-DD) or ISO-8601 timestamp."New value: +"Return records announced on or after this date (YYYY-MM-DD) or ISO-8601 timestamp."
- Changed
exec_moves2 fields changed- changed
Input schema / properties / since / descriptionPrevious value: -"Return records discovered/announced on or after this date (YYYY-MM-DD) or ISO-8601 timestamp."New value: +"Return records announced on or after this date (YYYY-MM-DD) or ISO-8601 timestamp." - changed
Input schema / properties / until / descriptionPrevious value: -"Return events discovered/announced on or before this date (YYYY-MM-DD, inclusive) or ISO-8601 timestamp."New value: +"Return events announced on or before this date (YYYY-MM-DD, inclusive) or ISO-8601 timestamp."
- Changed
funding_events1 field changed- changed
Input schema / properties / since / descriptionPrevious value: -"Return records discovered/announced on or after this date (YYYY-MM-DD) or ISO-8601 timestamp."New value: +"Return records announced on or after this date (YYYY-MM-DD) or ISO-8601 timestamp."
5 tool updates
- Added
add_to_watchlist - Added
create_watchlist - Added
get_watchlist - Added
list_watchlists - Added
remove_from_watchlist
1 tool update
- Added
company_timeline
Related MCP Connectors
Millions of dated buying and momentum signals: who raised, who's hiring, what changed and when
Company and market intelligence, news, enrichment, and agentic workflows for dealmakers.
Private company data, entity-resolved news, targeted lists, and alternative signals for AI agents.
SEC-sourced funding rounds, acquisitions, exec moves, hiring and investor signals. 7 keyless tools.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables querying and analyzing changes in technology company documentation through MCP tools, including change feeds, company info, and evidence-based messaging.-
- AlicenseAqualityAmaintenanceScans public news and press for a company's funding rounds, executive moves, product launches, acquisitions, partnerships, and IPOs, returning deduplicated events in flat JSON.1237 npmMIT
- FlicenseNot gradedqualityBmaintenanceAI research on companies and industries — one MCP tool per research domain.-
- FlicenseNot gradedqualityCmaintenanceEnables evaluating quantum and deep-tech startups by providing access to a curated dataset, company profiles with computed ratings, and a configurable deal-scoring rubric through MCP tools.-
Glama MCP Gateway
Add one secure layer between your agents and this server.