Read and reply to reviews from Google, Trustpilot, the App Store, Google Play, Judge.me and 40+ more platforms in one format, with your Prisma API key (test keys return sample data). Replies are published exactly as you approve them.
Scored across 9 tools
Each tool targets a clearly distinct resource or action: reviews, stats, usage, connections, locations, platforms, connect links, and replies. The closest pair, list_connections vs. list_platforms, is well separated by descriptions (connected accounts vs. all supported platforms and their connection requirements).
Nearly all tools follow a consistent snake_case verb_noun pattern (create_connect_link, get_review, list_reviews, etc.). reply_to_review is a minor deviation with a verb-preposition-noun form, though it remains clear and idiomatic.
Nine tools is well-scoped for a multi-platform review management service. Each tool covers a necessary part of discovery, onboarding, review reading, replying, and account usage without obvious redundancy.
The surface covers the main lifecycle: discover platforms, connect accounts, list locations, read reviews, reply, view stats, and check usage. Minor gaps exist around disconnecting/reauthenticating connections and explicit reply deletion, but core workflows are covered or workable through existing tools.
A link the business owner opens in a browser to connect a platform themselves (sign in with the platform, no Prisma account needed). Valid for a few days.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | Optional: open the link on this platform. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a non-destructive mutation in a closed world, so the bar is lower. The description still adds real behavioral context: the link expires after 'a few days' and the recipient needs no Prisma account, both of which affect how an agent should present and time-limit the output. It does not say whether re-invoking invalidates previous links or whether the URL is returned directly.
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, no filler, and the most decision-relevant facts (who opens it, no account required) come first. It would be marginally better front-loaded with the action ('Creates a link that...') rather than a bare noun phrase.
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 single optional-parameter creation tool with annotations covering the safety profile and no output schema, the description covers purpose, audience, and lifetime adequately. The main residual gap is the return value (presumably a URL) and what the agent should do with it, which matters slightly more given 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?
There is exactly one optional parameter and the schema documents it at 100% coverage, including the full platform enum, so the schema carries the meaning. The description never references the platform argument or explains what happens if it is omitted, so it adds nothing beyond the schema — baseline 3.
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 paints a concrete picture of the resource: a browser link the business owner opens to sign in to a platform without a Prisma account. It clearly distinguishes this self-serve onboarding artifact from the inspection-style siblings (list_connections, list_platforms), though it never states the verb 'creates' and relies on the name/title for that.
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 phrase 'connect a platform themselves ... no Prisma account needed' implies the situation in which to use it (self-serve owner onboarding). However, there is no explicit when-not guidance, no mention of alternatives for cases where the owner cannot or will not self-connect, and no prerequisites or sequencing described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One review by id, with its reply and the reply status.
| Name | Required | Description | Default |
|---|---|---|---|
| review_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description usefully adds what the record contains beyond the schema — the nested reply and reply status — but says nothing about behavior for a missing id or a review with no reply.
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?
One short sentence, front-loaded with the resource and scope, with zero filler. 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 single-record read with no output schema, the description does say what comes back, which is the key gap filler. It still leaves error/null-reply behavior and identifier format unaddressed.
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?
Only one parameter with 0% schema coverage, so the description carries the burden; 'by id' confirms review_id is an identifier but gives no format, source, or validity rules. Marginal value over the schema's name and required flag.
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 (get), resource (review) and scope (one, by id), and adds that the payload carries the reply and reply status. It is clearly separable from list_reviews, though it doesn't name siblings explicitly.
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?
'By id' implies the caller must already hold a review id, implicitly steering agents to list_reviews when they don't — but that is inference, not stated guidance. No when-not or alternative is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Average rating, review count, rating distribution and reply rate, for everything or one location or platform. Default period: the last 12 months.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | A date (2026-10-01) or an ISO 8601 timestamp. | |
| until | No | A date (2026-10-01) or an ISO 8601 timestamp. | |
| platform | No | ||
| location_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context by disclosing the default period of the last 12 months and enumerating the aggregated metrics returned, which compensates for the absent output schema.
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?
A single tight sentence that leads with the returned metrics and ends with the default-period behavior. Nothing is padded and nothing repeats the title.
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 does the important work of enumerating the return fields. Remaining gaps are minor: whether metrics respect reply state, and how location_id interacts with platform, are unstated.
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 only 50% and location_id has no schema description, but the description clarifies that platform/location_id scope the aggregation and that since/until form a period with a 12-month default. That meaningfully complements the date-format hints already in 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?
Names the exact metrics returned (average rating, review count, rating distribution, reply rate) and the aggregation scope (everything, one location, or one platform). This is specific enough to distinguish it from get_review and list_reviews, though the description never explicitly says so.
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?
'For everything or one location or platform' implies the scoping choice, and the default 12-month period tells the agent what happens when no dates are supplied. It gives no explicit when-to-use versus get_usage or list_reviews, and no caveats about mixing location_id and platform.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plan, locations used and allowed, requests and replies this month, and paid reads.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description's value-add is naming the data the call surfaces (plan/location limits, monthly request/reply counts, paid reads), which is useful since there is no output schema, but it says nothing about aggregation period, freshness, or scope beyond 'this month'.
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?
One compact sentence with no filler, and the most relevant content (plan limits, usage counts) is up front. It reads as a sentence fragment rather than a statement of action, which slightly hurts clarity but not length.
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 zero parameters and no output schema, the description must carry the job of explaining what comes back, and it does so only as a terse list of metric names without structure or units. Adequate to know roughly what to expect, but thin for a reporting tool an agent may want to summarize.
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 tool takes no parameters, so the schema carries no burden and the baseline is 4. Nothing in the description conflicts with the empty input 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?
The description is a bare noun list ('Plan, locations used and allowed, requests and replies this month, and paid reads') that conveys the resource being reported but never states a verb or that this is a read of the account's usage. An agent can infer it returns usage data, and it is distinguishable from siblings like get_stats and list_reviews, but the purpose is only implied.
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?
There is no statement of when to call this versus get_stats or list_connections, and no prerequisites or exclusions. The agent must infer the use case entirely from the field list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Platform accounts connected to Prisma and their status (active, pending, reauth_required…).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful substance beyond that by enumerating the status values (active, pending, reauth_required), but says nothing about ordering, empty results, or pagination.
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?
A single front-loaded sentence with no filler; the status vocabulary is the most decision-relevant detail and it sits in the payload clause. It is a noun fragment rather than a full statement of action, which slightly blunts the lead.
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 zero-parameter, read-only list tool with no output schema, the description covers the essentials by naming the two returned attributes and the status domain. Missing only minor operational details such as empty-state behavior or ordering.
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 tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. The schema is 100% covered and empty, so no compensation is needed.
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 names the resource ('platform accounts connected to Prisma') and the payload ('their status'), which maps directly onto list_connections. It implicitly separates itself from list_platforms (available platforms vs. accounts already connected), though it never states 'list' as a verb or names a sibling explicitly.
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 this is the tool for checking whether a platform is already linked and in what state. There is no explicit when-to-use, no exclusions, and no pointer to create_connect_link for accounts that are not yet connected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The connected locations (a business, app, shop or listing on one platform), with their id, platform and status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the returned fields (id, platform, status), which is useful given there is no output schema, but says nothing about ordering, pagination, or whether all locations are returned unfiltered.
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?
A single compact sentence with the resource definition and return fields front-loaded. It is a noun fragment rather than a full statement of action, but nothing is wasted.
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 no-param read tool with no output schema, the description is the only source of return-value information, and it only partially covers that (three fields, no notion of result size or ordering). It is adequate to invoke but not fully self-sufficient.
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 tool takes zero parameters, so the baseline is 4. The description correctly implies an unfiltered list rather than suggesting any input is available.
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 names the resource precisely and even defines it ("a business, app, shop or listing on one platform"), which removes ambiguity about what a 'location' is. It does not distinguish itself from near-siblings like list_connections or list_platforms, so an agent must infer the boundary.
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?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as list_connections or list_platforms, which an agent could easily confuse with this tool. Usage is only implied by the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every supported platform: whether replies are supported, whether this account can connect it now, and the fields and steps needed to connect it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds value by disclosing what each entry contains (reply support, connectability for this account, required connection fields/steps). It stops short of describing the response shape or ordering, but for a static zero-param catalog that is a minor gap.
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?
A single tightly-packed sentence with the resource front-loaded and zero filler. Every clause contributes a distinct returned attribute.
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 content, and it does so at the property level (reply support, connectability, fields/steps). It could go one step further in clarifying the shape of the 'fields and steps' payload, but nothing needed to invoke the tool 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?
The tool takes zero parameters, so the baseline is 4. The description correctly adds no parameter commentary because there is nothing to document.
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 names a specific resource (supported platforms) and enumerates the attributes returned: reply support, per-account connectability, and the fields/steps to connect. That makes it distinguishable from list_connections (existing links) and list_locations. The list verb is only implied via the name/title, but the scope 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?
Usage is implied rather than stated: an agent can infer this is the discovery step before create_connect_link, but the description never says when to call it versus list_connections or when not to. No prerequisites or ordering guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reviews, newest first, in the same format for every platform. Filter by location, platform, date or whether they have a reply. Use next_cursor for the next page.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | No | Only reviews created on or after this date. | |
| cursor | No | next_cursor from the previous page. | |
| platform | No | ||
| has_reply | No | true: only answered reviews; false: only unanswered ones. | |
| location_id | No | Only this location (from list_locations). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; beyond that the description adds genuinely new behavior: default sort is newest-first, results are normalized to one shape across every platform, and paging is cursor-based. It omits rate limits and whether the default limit of 20 is enforced server-side, so it falls short of a 5.
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 short sentences, front-loaded with what the tool returns and how it is sorted, followed by filters and pagination. No filler and nothing buried.
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 should carry more of the return-value burden; it hints that reviews are normalized across platforms and that a next_cursor comes back, but says nothing about the review fields returned or result ordering ties. Adequate for a simple read tool, but the response shape is left to inference.
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 67%, and the four described parameters (since, cursor, has_reply, location_id) already explain themselves in the schema; the description merely restates the filter set. The undescribed 'limit' and 'platform' enum are not compensated for — neither the max of 100 nor the default of 20 is mentioned in the description.
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?
Names the resource (reviews), states default ordering (newest first), and adds a distinguishing property: a normalized output format across all platforms. It does not explicitly contrast with get_review or list_locations, so the boundary with siblings is left implicit.
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?
Enumerates the available filter axes (location, platform, date, has_reply) and tells the agent how to paginate, which is clear usage context. It never says when to prefer this over get_review or get_stats, and 'next_cursor' does not match the actual parameter name 'cursor', which could momentarily confuse an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publishes a reply on the platform, through its official API, with the exact text given (it replaces an existing reply where the platform allows editing). Only call this with text the user has approved. Read-only platforms return an error with the link to answer there.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The reply, exactly as it will be published. | |
| review_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations it discloses the key mutation semantics: the reply replaces an existing one where editing is allowed, the text is published verbatim, and read-only platforms fail with a link to answer externally. That is the overwrite/error behavior an agent needs and annotations alone (readOnlyHint=false, idempotentHint=true) would not 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 short sentences, each carrying distinct information: the action, the approval constraint, and the failure mode. The overwrite caveat is front-loaded in the first sentence rather than buried.
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 two-parameter mutation with no output schema, the description covers action, safety constraint, overwrite behavior and error handling. It stops short of saying what a successful call returns or what review_id must refer to, which leaves a small 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 coverage is 50%; the text parameter is already documented in the schema and the description only restates that it is published exactly as given. review_id is undocumented in both schema and description, so the description does not compensate for the coverage gap.
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 names a specific verb and resource ('Publishes a reply on the platform') and adds the channel ('through its official API'), which distinguishes it cleanly from read-only siblings like get_review and list_reviews. An agent can tell immediately that this is the only write-to-review tool in the set.
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 gives an explicit precondition ('Only call this with text the user has approved') and a when-not condition ('Read-only platforms return an error with the link to answer there'). There is no alternative reply tool to route to, so the lack of named alternatives is acceptable, but it does not spell out when to reply versus e.g. ignore a review.
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.
create_connect_linkget_reviewget_statsget_usagelist_connectionslist_locationslist_platformslist_reviewsreply_to_review
Add one secure layer between your agents and this server.