Summary: Given a company domain (or company name) and one or more of 46 page types, it locates that page on the company's own website — returning the URL, the discovery method, and a per-method confidence — and can optionally read the page and return structured fields.
Locate pages by URL: Feed domain (e.g. stripe.com), domains (several), or companies (name-based, runs charged identity resolution first).
Target 46 page types: pricing, careers, investor_relations, security_trust_center, contact, terms_of_service, status_page, documentation, press_newsroom, and more. Default is ["pricing"].
Get an auditable answer: Each row gives {type}_url, {type}_method (known_url, homepage_anchor, footer_anchor, section_hop, sitemap, path_guess, …), {type}_confidence scored per method, plus coverage and fetch_status.
Distinguish false from unknown: {type}_found is true, false (site read, page absent) or null (not enough readable) — never collapsed.
Read the page too: Set mode: "locate_and_extract" to return structured fields into a second findings dataset (one record per field, keyed by input_key).
Choose extraction fields: extractionFields (emails, phones, social_links, schema_org, forms, ctas, etc.) and extractPageTypeFields for page-type-specific maps (pricing plans, filing rows, certifications, ATS host, governing law).
Supply URLs you already have: knownUrls keyed by page type skips discovery for those types.
Tune the crawl: maxPagesPerType (1–12), maxRequestsPerInput (5–200), concurrency, languageHints (11 European languages, reorders only), allowRender for JS pages, skipCache to bypass the 14-day cache.
Cap spend: max_charge_usd stops the run before a charge would exceed it and writes a notice row; Apify's own max cost is always honored.
Predictable billing: pay per locate/extract/resolution event (empty looks are still billed; dead domains, refusals and robots.txt disallows are not).
Read-only and polite: honors robots.txt and Crawl-delay, one request at a time per domain, descriptive user agent, no impersonation; returns a contact block or leadership names only when those pages are requested (is_personal_data: true).
Limits: does not crawl whole sites, read third-party review/social sites, or monitor pages over time. Requires an APIFY_TOKEN and Apify credits.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-page-finder-extractor Find pricing page on stripe.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Give it a company domain and name a page type. It finds that page on the company's own website and returns the URL, the method that found it, and a confidence for that method.
46 page types. Discovery vocabulary in 11 European languages. Optionally reads the page and returns structured fields.
Wraps the Page Finder and Extractor actor by Mamba Labs.
npx -y @mambalabsdev/mcp-page-finder-extractorRequires an Apify API token in APIFY_TOKEN. Create one at console.apify.com/account/integrations.
{
"mcpServers": {
"mamba-page-finder-extractor": {
"command": "npx",
"args": ["-y", "@mambalabsdev/mcp-page-finder-extractor"],
"env": {
"APIFY_TOKEN": "your-apify-token"
}
}
}
}Related MCP server: company-change-event-feed
find_company_pageInput | Required | What it does |
| one of these three | A single company domain, for example |
| one of these three | Several company domains |
| one of these three | Companies by name, as |
| no | Which of the 46 page types to find. Default |
| no |
|
| no | URLs you already hold, keyed by page type. Skips discovery for those |
| no | The page agnostic extraction menu |
| no | Also run the field map bound to the page type. Default |
| no | 1 to 12, candidate pages opened per type. A number or a numeric string. Default |
| no | 5 to 200, ceiling on requests per company. A number or a numeric string. Default |
| no | Open a browser for pages that need JavaScript. Default |
| no | Language codes to try first. Reorders vocabulary, never shortens it |
| no | Spend cap for the run, in USD. The run starts no company whose worst case cost would cross it and writes one notice row. Empty means no cap of your own |
| no | How many companies to work on at once. Per company the actor still makes one request at a time with a delay. A number or a numeric string. Default |
| no |
|
The 46 page types: pricing, demo_request, free_trial, procurement_vendor, about, leadership_team, locations, investor_relations, annual_report, governance, security_trust_center, compliance_certifications, privacy_policy, terms_of_service, dpa_subprocessors, accessibility_statement, status_page, careers, job_board, benefits, culture, documentation, api_reference, integrations, changelog, roadmap, developer_portal, blog, press_newsroom, case_studies, customers_logos, resources_library, events_webinars, podcast, media_kit, partners, reseller_channel, affiliate_program, marketplace_listing, community, contact, support_help_center, login_app, sustainability_esg, diversity_programs, giving_volunteering.
One flat row per input, always, including the ones where nothing was found.
{type}_url is the located page, for example pricing_url.
{type}_found is true, false or null. These are never collapsed. false means the site was read, its link graph and sitemap were searched, and the page is not there. null means not enough was readable to say so.
{type}_method is how it was found: known_url, known_host, homepage_anchor, footer_anchor, section_hop, sitemap or path_guess. Precision differs sharply between them.
{type}_confidence is scored for that method, not blended. Threshold at 0.8 for anything a customer will see. A path_guess never scores above 0.6.
coverage and fetch_status say whether the look completed. Read them before trusting a false.
In locate_and_extract mode the structured fields land in a second findings dataset, one record per field, keyed back by input_key, because eleven filing rows do not fit in one cell.
Pay per event on Apify credits. Roughly, at the FREE tier: $0.004 per page type located, $0.003 per page extracted, $0.007 per company name resolved, and the standard actor start fee.
A look that happens is billed, including the ones that come back empty, because the work is the same either way. A look that does not happen is not billed: a dead domain, a refusal, or a robots.txt disallow returns found: null and no locate charge.
You are never charged for identity resolution unless you use the companies path.
It reads publicly available pages on the company's own website. It honors robots.txt per host including Crawl-delay, makes one request at a time per domain with a delay, and sends a descriptive user agent that names it. It does not impersonate a browser, does not sign headers, and does not retry to get around a block. Where a page is publicly served but needs JavaScript to read, a browser renders it; a browser is never used against an access control.
Personal data. Two page types can return a named person: contact returns the contact block a company publishes on its own contact page, and about returns leadership names published on its own about page. Only what the company published, no inferred attributes, no lookups elsewhere. Those records carry is_personal_data: true and a lawful_basis, so the whole class filters out with one predicate, or leave contact and about out of pageTypes and none is produced. For a roster of people at a company, use Team Page People Extractor instead.
This server is read only. It starts an actor run and returns the dataset. It writes nothing anywhere else.
This server is one of the Mamba Labs MCP servers for go-to-market data, each backed by its own actor on the Apify Store. If you would rather install one package than many, @mambalabsdev/mcp-gtm-suite exposes the suite through a single server.
Browse the whole fleet on the Apify Store or on npm.
If you want a roster of people at a company rather than a page on its website, use Team Page People Extractor and Contact Classifier instead. This actor returns a contact block only when it happens to sit on a page you asked it to find.
The actor is on the Apify Store. This wrapper lives at github.com/mambalabsdev/mcp-page-finder-extractor and is MIT licensed.
Built by Mamba Labs.
Give it a company domain and name a page type. It finds that page on the company's own website and returns the URL, the method that found it, and a confidence for THAT method. 46 page types are available: pricing, investor_relations, security_trust_center, careers, about, contact, terms_of_service, privacy_policy, partners, integrations, documentation, api_reference, status_page, changelog, press_newsroom, customers_logos, sustainability_esg and 29 more. Discovery reads the homepage and footer link graph, the sitemap and its shards, known third party hosts such as boards.greenhouse.io and statuspage.io, and anchor vocabulary in 11 European languages; guessing a URL path is the LAST method tried and is scored 0.6 or below. Read {type}_confidence and threshold at 0.8 for anything a customer will see, and read coverage and fetch_status before trusting a false: found=false means the site was read and the page is not there, found=null means not enough was readable to say, and the two are never collapsed. Set mode to locate_and_extract to also read the page and return structured fields, which costs an extra event per page. Every input returns exactly one row, including the empty ones. Use it when you need a specific page on a company's own site, such as pricing, careers, or investor relations; it does not crawl a whole site, read third party review or social sites, or monitor a page over time. Requires an APIFY_TOKEN and consumes Apify credits. Read only.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | locate returns the page URL, the method and a confidence. locate_and_extract also reads the page and returns structured fields into a second findings dataset. Default: "locate". | |
| domain | No | A single company domain, for example stripe.com. Protocol and path are stripped. Supply this or domains or companies. | |
| domains | No | Several company domains. Every one returns a row, including the ones where nothing is found. | |
| companies | No | Companies you have a name for but not a domain. Identity resolution runs first on this path and is charged as its own event. Use domains instead whenever you hold a domain. | |
| knownUrls | No | URLs you already hold, keyed by page type, for example {"pricing": "https://stripe.com/pricing"}. Discovery is skipped for that page type, which is faster and exact. | |
| pageTypes | No | Which page types to locate. Each one costs a locate event and adds requests, so ask for what you will use. Default: ["pricing"]. | |
| skipCache | No | false uses the 14 day cache. true forces a fresh crawl. Default: "false". | |
| allowRender | No | true opens a browser for pages that serve no readable HTML, which is most Nordic investor calendars. A browser is never used against a block, a CAPTCHA, a login or robots.txt. Default: "true". | |
| concurrency | No | How many companies to work on at once. Per company the actor is still strictly one request at a time with a delay, so this does not make it impolite to any single site. A number or a numeric string. Default: 10. | |
| languageHints | No | Language codes to try first, for example ["de","fr"]. Vocabulary is multilingual by default in all 11 languages; this only reorders it and never shortens it. | |
| max_charge_usd | No | Optional. The actor's own spend cap for this run, in USD. The run stops before a charge would take its total past this amount, writes one notice row saying so, and keeps every row already charged. Leave it empty for no cap of your own; the maximum cost per run set in Apify is honored either way. | |
| maxPagesPerType | No | Between 1 and 12. Candidate pages opened per page type before giving up. Lowering it is faster and finds less. A number or a numeric string. Default: 4. | |
| extractionFields | No | The page agnostic extraction menu, available on any page type. Only used in locate_and_extract mode. Omit for all of them. | |
| maxRequestsPerInput | No | Between 5 and 200. Hard ceiling on requests to one company's site. Hitting it returns coverage partial rather than a false negative. A number or a numeric string. Default: 60. | |
| extractPageTypeFields | No | true also runs the field map bound to the page type: pricing plans, filing rows and a derived fiscal year end, certifications, ATS host, governing law. Only used in locate_and_extract mode. Default: "true". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is unusually rich — it discloses credit consumption and APIFY_TOKEN requirement, caching, the confidence threshold of 0.8 for customer-facing use, that path guessing is the last method tried and scored <=0.6, and the found=true/false/null distinction. However, it closes with 'Read only.' while annotations declare readOnlyHint=false, so the agent is told two different side-effect profiles for the same tool; the credit disclosure partially mitigates but does not resolve the conflict.
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?
Front-loaded with the core action and input shape in the first sentence, then layered detail; almost every sentence carries operational weight. It loses a point for enumerating 17 of the 46 page types that the schema's enum already lists in full, which is mild duplication in an otherwise dense block.
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-parameter, paid, open-world tool with no output schema, the description covers everything an agent needs: auth and credit cost, the confidence field and threshold, coverage/fetch_status caveats, the found vs null distinction, and the one-row-per-input guarantee. Nothing material to correct invocation 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?
Schema description coverage is 100%, so the baseline is 3, and the description earns above baseline by tying parameters to cost and usage decisions: mode=locate_and_extract 'costs an extra event per page', pageTypes should be limited to 'what you will use', and the confidence score is tied to the 0.8 threshold for customer-visible output. It still leaves per-parameter mechanics (maxPagesPerType, maxRequestsPerInput, languageHints) largely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Give it a company domain and name a page type. It finds that page on the company's own website') and immediately bounds the scope by naming what it is NOT (whole-site crawler, review/social sites, page monitoring). The agent knows exactly what class of task this tool serves 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?
Explicit when-to-use ('Use it when you need a specific page on a company's own site, such as pricing, careers, or investor relations') and explicit when-not ('it does not crawl a whole site, read third party review or social sites, or monitor a page over time'). It also routes between input paths (domain vs domains vs companies, and knownUrls to skip discovery). No alternatives are left to inference.
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.
v1.2.0find_company_page10 fields changedInput schema / properties / concurrency / anyOfAdded value: +[
+ {
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ }
+]Input schema / properties / concurrency / descriptionPrevious value: -"How many companies to work on at once. Per company the actor is still strictly one request at a time with a delay, so this does not make it impolite to any single site. Sent as a string. Default: \"10\"."New value: +"How many companies to work on at once. Per company the actor is still strictly one request at a time with a delay, so this does not make it impolite to any single site. A number or a numeric string. Default: 10."Input schema / properties / concurrency / typeRemoved value: -"string"Input schema / properties / maxPagesPerType / anyOfAdded value: +[
+ {
+ "maximum": 12,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ }
+]Input schema / properties / maxPagesPerType / descriptionPrevious value: -"Between 1 and 12. Candidate pages opened per page type before giving up. Lowering it is faster and finds less. Sent as a string so it works from Clay. Default: \"4\"."New value: +"Between 1 and 12. Candidate pages opened per page type before giving up. Lowering it is faster and finds less. A number or a numeric string. Default: 4."Input schema / properties / maxPagesPerType / typeRemoved value: -"string"Input schema / properties / maxRequestsPerInput / anyOfAdded value: +[
+ {
+ "maximum": 200,
+ "minimum": 5,
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ }
+]Input schema / properties / maxRequestsPerInput / descriptionPrevious value: -"Between 5 and 200. Hard ceiling on requests to one company's site. Hitting it returns coverage partial rather than a false negative. Sent as a string. Default: \"60\"."New value: +"Between 5 and 200. Hard ceiling on requests to one company's site. Hitting it returns coverage partial rather than a false negative. A number or a numeric string. Default: 60."Input schema / properties / maxRequestsPerInput / typeRemoved value: -"string"Input schema / properties / max_charge_usdAdded value: +{
+ "description": "Optional. The actor's own spend cap for this run, in USD. The run stops before a charge would take its total past this amount, writes one notice row saying so, and keeps every row already charged. Leave it empty for no cap of your own; the maximum cost per run set in Apify is honored either way.",
+ "minimum": 0,
+ "type": "number"
+}v1.0.0find_company_pageScored across 1 tool
There is only one tool, so there is nothing to confuse it with. Its purpose (locate a specific page type on a company's own domain, optionally extract structured fields) is stated precisely and its boundaries are explicit.
A single tool named find_company_page follows a clear verb_noun snake_case convention. There is no opportunity for inconsistency within a one-tool surface.
A single tool is thin for a server, though it is deliberately scoped as a focused, single-purpose capability. The heavy parameterization (46 page types, locate_and_extract mode) compresses what could plausibly be several tools into one, which is defensible but borderline.
The tool covers its stated read-only discovery purpose well, including confidence, coverage, and tri-state found semantics, and clearly declares out-of-scope behavior (no crawling, no third-party sites, no monitoring). Gaps are minor, e.g. no multi-page or batch lookup in one call, requiring repeated invocations.
Turn a company domain into a structured B2B sales brief from their public website.
Extracts verified emails, social links, 40+ tech stack signals, pricing tiers, and company summary
Extracts verified emails, social links, 40+ tech stack signals, pricing tiers, and company summar.
Turn any website into structured JSON data matching your custom schema.