mcp-page-finder-extractor

Find Company Page

find_company_page

Idempotent

Find pricing, careers, investor relations, or other page types on a company's own website from its domain; returns URL, discovery method, confidence, and optional structured data.

Instructions

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.

Input Schema

Name	Required	Description
`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".

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv1.2.0Oct 16, 2026

addedInput schema / properties / concurrency / anyOf

Added value: +[
+  {
+    "minimum": 1,
+    "type": "integer"
+  },
+  {
+    "type": "string"
+  }
+]

changedInput schema / properties / concurrency / description

Previous 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."

removedInput schema / properties / concurrency / type
```
Removed value: -"string"
```

addedInput schema / properties / maxPagesPerType / anyOf

Added value: +[
+  {
+    "maximum": 12,
+    "minimum": 1,
+    "type": "integer"
+  },
+  {
+    "type": "string"
+  }
+]

changedInput schema / properties / maxPagesPerType / description

Previous 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."

removedInput schema / properties / maxPagesPerType / type
```
Removed value: -"string"
```

addedInput schema / properties / maxRequestsPerInput / anyOf

Added value: +[
+  {
+    "maximum": 200,
+    "minimum": 5,
+    "type": "integer"
+  },
+  {
+    "type": "string"
+  }
+]

changedInput schema / properties / maxRequestsPerInput / description

Previous 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."

removedInput schema / properties / maxRequestsPerInput / type
```
Removed value: -"string"
```

addedInput schema / properties / max_charge_usd

Added 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"
+}

First observedv1.0.0Aug 17, 2026

TDQS

A4.2/5.0

Behavior2/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server

Other Tools

find_company_pageA