An MCP server that returns a company funding record from SEC Form D, Companies House and press, each labeled with the source it came from. It wraps the Mamba Labs Funding Record from SEC and Companies House actor on Apify and returns a Clay-ready flat JSON row to any MCP client.
Related MCP server: mcp-company-contact-details-extractor
Give it a company name and domain and it reads primary sources and returns a funding record: SEC EDGAR Form D amounts, UK Companies House registration details, and press coverage of funding rounds. One flat row per company.
Every number travels with a source_of_record saying whether it came from a legal filing or from a press release, because those are not the same kind of fact and merging them is the defect this tool exists to prevent. Only an exact entity match, after corporate suffixes are stripped, populates an amount. A near match such as a differently named subsidiary goes to separate related_entity columns as a named lead and can never be summed into a total. This is not Crunchbase and not a resold database, so it returns less than a database would and what it returns has a filing behind it.
All of the lookup runs on Apify. This package is a thin client that calls the actor and hands back the result unchanged.
You need Node.js 18 or newer and an Apify account with an API token.
Add this to your Claude Desktop config:
{
"mcpServers": {
"mamba-funding-investor-record": {
"command": "npx",
"args": ["-y", "@mambalabsdev/mcp-funding-investor-record"],
"env": {
"APIFY_TOKEN": "your-apify-token"
}
}
}
}Get your token at https://console.apify.com/account/integrations, paste it in, and restart Claude Desktop. The get_company_funding_record tool will be available.
Node.js 18 or newer
An Apify account with an API token
Optional: your own Companies House REST API key, free at developer.company-information.service.gov.uk, if you want the UK columns populated
"Get the funding record for Anthropic at anthropic.com."
"Has Notion filed a Form D in the last 24 months? Regulatory sources only."
"Look up funding for this UK company and flag anything above 10 million dollars."
"Show me press reported funding for figma.com and keep it separate from any filing."
company_domain (optional): bare company domain, for example notion.com. Used to derive a company name when none is given, and carried on the row as the join key.
company_name (optional but strongly recommended): every source here is searched by name rather than by domain, and the name is what the entity gate compares a filing against. A wrong or missing name is the largest source of wrong rows.
sources (optional): which sources to query. One of all, regulatory, sec_only, uk_only or press_only. Regulatory sources are filings and are authoritative; press is the most recent and least verified. Choose regulatory when a number has to be defensible and all when recency matters more.
lookbackMonths (optional): how far back to consider a filing. One of 12, 24, 36, 60 or 120, with 36 months the default. A Form D from six years ago is a real filing and usually not a current signal, and this is where you say which you mean.
minAmountUsd (optional): one of none, 1000000, 5000000, 10000000 or 50000000. It sets amount_meets_threshold on the row so you can filter to material raises without writing the comparison yourself. It never drops a row and never changes the amount returned.
companiesHouseApiKey (optional): your own Companies House REST API key, free at developer.company-information.service.gov.uk. Without one the UK columns report skipped rather than guessing, and the SEC and press sources still run.
skipCache (optional): when false (the default) a successful lookup is cached for seven days and reused. Set true to force a fresh fetch.
The tool returns the actor's flat JSON row for the company, with 32 snake_case fields and no nested objects. source_of_record says where a number came from, form_d_entity_match and uk_entity_match record how strict the entity match was, and filings_rejected counts what the entity gate turned away. See the Apify Store page for the full output schema.
{
"degraded": false,
"degradation_reason": null,
"company_domain": "anthropic.com",
"company_name": "Anthropic",
"source_of_record": "multiple",
"form_d_filed": true,
"form_d_date": "2026-06-01",
"form_d_entity_name": "WU Anthropic LP",
"form_d_entity_match": "exact",
"form_d_accession": "0002109576-26-000001",
"filings_rejected": 56,
"uk_company_number": "14604577",
"uk_company_name": "ANTHROPIC LIMITED",
"uk_company_status": "active",
"uk_entity_match": "exact",
"uk_incorporation_date": "2023-01-19",
"press_amount": 65000000000,
"press_currency": "$",
"press_url": "https://techcrunch.com/2026/05/28/anthropic-raises-65-billion-nears-1t-valuation-ahead-of-ipo/",
"related_entity_name": null,
"amount_meets_threshold": null,
"sources_queried": "sec_form_d, companies_house, press",
"coverage": 0.9,
"fetch_status": "ok",
"run_date": "2026-08-23T09:56:16.906Z"
}SEC Form D filings, returned with the accession number
UK Companies House registration details, with your own key
Press coverage labeled as press and never merged with a filing
Primary sources only, not a resold database
Entity identity gate, so a near name match is rejected and recorded
Rejection accounting in filings_rejected and related_entity_note
32 flat snake_case fields, one row per company
This server is a thin client and holds no lookup logic. For the complete input and output reference, pricing, and run history, see the Apify Store page:
https://apify.com/mambalabs/funding-investor-record
This server is one of the Mamba Labs GTM Suite MCP servers. Every actor in the suite takes a domain or a company and returns one flat row, so they stack in the same Clay table without reshaping anything. The actor behind this server is the Funding Record from SEC and Companies House, immutable Apify actor ID OFS4Mt1gyYNtGfUbE.
Built by Mamba Labs | npm | Apify Store
MIT
Built by Mamba Labs. https://apify.com/mambalabs
Return a company's funding record from PRIMARY sources: SEC EDGAR Form D filings, UK Companies House registrations and press coverage. Returns one flat Clay ready row in which every number carries a source_of_record saying whether it came from a legal filing or a press release, because those are not the same kind of fact and merging them is the defect this tool exists to prevent. Only an EXACT entity match after corporate suffixes are stripped populates an amount; a near match such as a differently named subsidiary goes to separate related_entity columns as a named lead and can never be summed into a total. Not Crunchbase and not a resold database. Read only; requires an APIFY_TOKEN and consumes Apify credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| sources | No | Which sources to query. Regulatory sources are filings and are authoritative; press is the most recent and least verified. Choose "regulatory" when a number has to be defensible and "all" when recency matters more. Sent as a string for Clay compatibility. | |
| skipCache | No | When "false" (default) a successful lookup is cached for seven days and reused, which costs you nothing on a repeated run. Set "true" to force a fresh fetch. Sent as a string for Clay compatibility. | |
| company_name | No | Strongly recommended here. Every source in this actor is searched by NAME, not by domain, and the name is what the entity gate compares a filing against. A wrong or missing name is the single largest source of wrong rows. | |
| minAmountUsd | No | Sets amount_meets_threshold on the row so you can filter to material raises without writing the comparison yourself. It never drops a row and never changes the amount returned. Sent as a string for Clay compatibility. | |
| company_domain | No | Bare company domain, for example notion.com. Used to derive a company name when none is given, and carried on the row as the join key. | |
| lookbackMonths | No | How far back to consider a filing. 36 months by default. A Form D from six years ago is a real filing and usually not a current signal, and this is where you say which you mean. Sent as a string for Clay compatibility. | |
| companiesHouseApiKey | No | YOUR OWN Companies House REST API key, free at developer.company-information.service.gov.uk. OPTIONAL: without one the UK columns report skipped rather than guessing, and the SEC and press sources still run. Marked secret, so the value never renders on this page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description discloses meaningful runtime behavior: it requires an APIFY_TOKEN, consumes credits per call, caches successful lookups for seven days, only populates amounts on exact entity matches, and sends near matches to related_entity columns. It also explains that legal filings and press releases are deliberately kept distinct via source_of_record. This is far more than the annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose and sources, result shape and source_of_record logic, exact-match rules, exclusions, and auth/cost implications. It is front-loaded with the most important facts and avoids 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?
Despite having no output schema, the description explains what the returned row looks like, how numbers are attributed, how matching works, what happens with near matches, and what credentials are needed. Combined with the detailed parameter descriptions, an agent has enough context to call the tool correctly and interpret the result safely.
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, but the description adds semantic value beyond the schema by explaining exact-match behavior after corporate suffix stripping and why a near match must never be summed into a total. It also clarifies the conceptual difference between 'source_of_record' values, which helps an agent interpret the company_name and sources parameters correctly.
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 opens with a specific verb and resource: 'Return a company's funding record from PRIMARY sources: SEC EDGAR Form D filings, UK Companies House registrations and press coverage.' It clearly distinguishes the tool from generic databases by saying 'Not Crunchbase and not a resold database,' and it explains the source-of-record concept that defines the tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-not guidance ('Not Crunchbase and not a resold database') and explains the tradeoff between authoritative regulatory filings and fresher press coverage. The parameter descriptions add concrete decision rules: choose 'regulatory' when a number must be defensible and 'all' when recency matters more. This tells an agent exactly how to route its choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get_company_funding_recordWith only one tool, there is no possibility of confusion or misselection. The single tool has a clear, specific purpose that is unambiguously described.
The tool name follows a standard verb_noun pattern (get_company_funding_record). Since there is only one tool, there are no conflicting conventions or mixed naming styles.
A single tool feels thin for a server that could plausibly support related operations (e.g., searching companies, comparing records). However, the tool is substantive and not trivial, so it is borderline rather than an extreme mismatch.
The read-only scope is largely self-contained, covering primary sources and edge cases like near matches. Minor gaps exist (e.g., no support for non-UK/US jurisdictions or batch operations), but the core workflow of retrieving a company's funding record is well covered.
MCP server for VC pitch-deck scoring, thesis-fit matching, and deal-flow management.
Marketplace MCP server for live venture-capital raises and agent-mediated dealflow.
MCP server for Codat — companies, connections, invoices, bills and financial statements.
Wellfound startup jobs with salary and equity parsed, via an Apify Actor, hosted MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mambalabsdev/mcp-funding-investor-record'
If you have feedback or need assistance with the MCP directory API, please join our Discord server