mcp-review-platform-reputation-enricher

Get Trustpilot Reputation

get_trustpilot_reputation

Read-onlyIdempotent

Fetch a company's Trustpilot rating, review count, star score, and star breakdown as one flat row for Clay. Uses domain or business unit ID; read-only, requires APIFY_TOKEN.

Instructions

Return a company's Trustpilot rating, review count, star score, and one to five star breakdown as one flat Clay ready row. Trustpilot only: G2, Capterra, and Glassdoor ship as skipped status columns so the row shape stays fixed, and they are never fetched. By default it reads Trustpilot's public TrustBox data endpoint, which Trustpilot's robots.txt allows, and needs no Trustpilot API key. Pass trustpilotBusinessUnitId whenever you have it: with the id the lookup always resolves, while a domain alone resolves only when the company's own site embeds a Trustpilot widget. A row's trustpilot_business_id can be fed back as the id on a later call. Set publicPageAccess to unblocker to read the public company page through Apify Unblocker instead, which resolves a domain with no id and adds categories and claimed status, at a higher event price and against Trustpilot's robots.txt, so it is the caller's choice. A refused request reports blocked and a domain with no business unit reports not_found, and those two are never conflated. Do not use it for review text: it returns the aggregate, not review rows. Read only; requires an APIFY_TOKEN and consumes Apify credits per call.

Input Schema

TableJSON Schema

Name	Required	Description
`sources`	No	Which review sources to query. This version serves Trustpilot only. G2, Capterra, and Glassdoor appear as columns and always report skipped, with the reason on the row. This setting exists so a saved configuration keeps working when a source is added. Sent as a string for Clay compatibility.
`skipCache`	No	When "false" (default) a successful lookup is cached for seven days and reused, which costs nothing on a repeated run. Set "true" to force a fresh fetch. Sent as a string for Clay compatibility.
`company_name`	No	Optional. Carried through to the output row for joining. The lookup is keyed on the business unit id, so the name never changes which business is returned.
`company_domain`	No	Bare company domain, for example monzo.com. Used to look for a Trustpilot business unit id in the company's own widget embed. Supplying trustpilotBusinessUnitId instead skips this step and always resolves.
`minReviewCount`	No	Sets rating_is_meaningful on the row. A 5.0 rating from two reviews and a 4.2 from nine hundred are not comparable numbers, and this is the column that says which one you are looking at. It never drops a row and never changes the rating returned. Sent as a string for Clay compatibility.
`publicPageAccess`	No	Leave at "off" (default) to read only Trustpilot's public TrustBox data endpoint, which Trustpilot's robots.txt allows. Set "unblocker" to read Trustpilot's public company pages through Apify Unblocker, which resolves any domain with no business unit id and also returns categories, claimed status, and verification. Trustpilot's robots.txt disallows those pages to automated agents, so this is the caller's call, and it spends Unblocker units from the caller's Apify account. A row resolved this way charges public-page-profile-returned instead of reputation-resolved, never both.
`includeCategories`	No	Has no effect on the default route: Trustpilot publishes categories only on its public company page, so trustpilot_categories is null unless publicPageAccess is unblocker. Kept so saved configurations keep working. Sent as a string for Clay compatibility.
`trustpilotBusinessUnitId`	No	The 24 character Trustpilot business unit id, for example 57da77be0000ff000594bcdb. The fastest and most reliable input: supplied here it always resolves. Find it in the page source of any site running a Trustpilot widget, as data-businessunit-id, or reuse trustpilot_business_id from an earlier row. Leave it empty and the actor looks for it on the company's own site.

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv1.0.1Oct 15, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

changedInput schema / properties / company_domain / description

Previous value: -"Bare company domain, for example stripe.com. Trustpilot business units are keyed on the company website domain, so this is the correct and only lookup key."New value: +"Bare company domain, for example monzo.com. Used to look for a Trustpilot business unit id in the company's own widget embed. Supplying trustpilotBusinessUnitId instead skips this step and always resolves."

changedInput schema / properties / company_name / description

Previous value: -"Optional. Carried through to the output row for joining. The Trustpilot lookup is keyed on the domain, so the name does not change which business unit is returned."New value: +"Optional. Carried through to the output row for joining. The lookup is keyed on the business unit id, so the name never changes which business is returned."

changedInput schema / properties / includeCategories / description

Previous value: -"When \"true\" (default) the Trustpilot categories the business is listed under are returned. They are a useful cheap proxy for what a company actually sells, which is often not what its homepage says. Sent as a string for Clay compatibility."New value: +"Has no effect on the default route: Trustpilot publishes categories only on its public company page, so trustpilot_categories is null unless publicPageAccess is unblocker. Kept so saved configurations keep working. Sent as a string for Clay compatibility."

changedInput schema / properties / minReviewCount / enum

Previous value: -[
-  "none",
-  "10",
-  "50",
-  "100",
-  "500"
-]New value: +[
+  "10",
+  "50",
+  "100",
+  "500",
+  "none"
+]

addedInput schema / properties / publicPageAccess

Added value: +{
+  "description": "Leave at \"off\" (default) to read only Trustpilot's public TrustBox data endpoint, which Trustpilot's robots.txt allows. Set \"unblocker\" to read Trustpilot's public company pages through Apify Unblocker, which resolves any domain with no business unit id and also returns categories, claimed status, and verification. Trustpilot's robots.txt disallows those pages to automated agents, so this is the caller's call, and it spends Unblocker units from the caller's Apify account. A row resolved this way charges public-page-profile-returned instead of reputation-resolved, never both.",
+  "enum": [
+    "off",
+    "unblocker"
+  ],
+  "type": "string"
+}

changedInput schema / properties / skipCache / description

Previous value: -"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."New value: +"When \"false\" (default) a successful lookup is cached for seven days and reused, which costs nothing on a repeated run. Set \"true\" to force a fresh fetch. Sent as a string for Clay compatibility."

changedInput schema / properties / sources / description

Previous value: -"Which review sources to query. v1 serves Trustpilot only. G2, Capterra and Glassdoor appear as columns and always report skipped, with the reason on the row, because all three refused every documented route and none publishes an API we can use as documented. This setting exists so a saved configuration keeps working when a source is added. Sent as a string for Clay compatibility."New value: +"Which review sources to query. This version serves Trustpilot only. G2, Capterra, and Glassdoor appear as columns and always report skipped, with the reason on the row. This setting exists so a saved configuration keeps working when a source is added. Sent as a string for Clay compatibility."

removedInput schema / properties / trustpilotApiKey

Removed value: -{
-  "description": "YOUR OWN Trustpilot API key, free to create at developers.trustpilot.com. REQUIRED: the Business Units API is not open, so without a key this actor reports skipped rather than guessing. Marked secret, so the value never renders on this page.",
-  "type": "string"
-}

addedInput schema / properties / trustpilotBusinessUnitId

Added value: +{
+  "description": "The 24 character Trustpilot business unit id, for example 57da77be0000ff000594bcdb. The fastest and most reliable input: supplied here it always resolves. Find it in the page source of any site running a Trustpilot widget, as data-businessunit-id, or reuse trustpilot_business_id from an earlier row. Leave it empty and the actor looks for it on the company's own site.",
+  "type": "string"
+}

First observedv1.0.0Sep 8, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover read-only/idempotent safety, but the description adds substantial depth beyond them: endpoint choice and robots.txt implications, unblocker costs and billing differences, the blocked vs not_found status semantics, caching and credit consumption, APIFY_TOKEN requirement, and the fixed row shape with skipped G2/Capterra/Glassdoor columns.

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-loads the return shape, then covers inputs, route behavior, and constraints in a dense but organized passage. It is long for a single tool, but every sentence carries operational weight with little redundancy.

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 tool with 8 parameters, no output schema, and multiple routing/pricing/auth behaviors, the description is thorough: it explains resolution guarantees, cost implications, error statuses, caching, and the fixed column contract. An agent can call it correctly across all routes without external documentation.

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 coverage is already 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the purpose of trustpilotBusinessUnitId ('always resolves' vs domain-only widget dependency), the feedback loop of trustpilot_business_id, and the routing rationale behind publicPageAccess, though the remaining parameters are largely left to their own schema descriptions.

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 specific verb+resource (Trustpilot reputation aggregate) and precisely enumerates what is returned: rating, review count, star score, and star breakdown. It explicitly excludes review text, drawing a firm boundary around what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives strong contextual guidance: when to pass trustpilotBusinessUnitId vs rely on domain, and when to switch publicPageAccess to unblocker. It states what not to use it for (review text). No sibling tools exist to differentiate against, and it does not spell out when to prefer skipCache or minReviewCount settings.

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

get_trustpilot_reputationA