Skip to main content
Glama

Check whether a Google review is removable

check_review_removability
Read-onlyIdempotent

Free and read-only. Tells a business owner whether a Google review matches one of Google’s named review rules, the same verdict as the free checker on essentras.com. Ask the person for facts only, never the review text, a name or a link: whose review it is, whether the reviewer was a real customer, what the review contains, whether they can show it, and where they are in Google’s process. Returns the verdict (strong match, arguable, or no policy match), Google’s rule with its policy link and the date it was read, where to report, the evidence to attach, Google’s stated timing, the appeal path, report and reply templates, and the Essentras service with its current price only when the page offers it. A genuine negative review gets “No policy match”: Google does not remove a review for being negative, and the tool says so. Google decides every removal.

Input Schema

NameRequiredDescriptionDefault
statusNoWhere are you in the process? not-reported = Not reported yet; pending = Decision pending; no-violation = Report reviewed - no policy violation; escalated = Escalated - check your email for updates; appeal-denied = Appeal decided, review still up; removed = Removed.not-reported
containsNoWhen ownership is business. What does the review contain? Select all that apply. Not a genuine experience: conflict = Written by a competitor, a current or former employee, a relative, or someone else with a conflict of interest; incentivized = Paid for or incentivized by anyone (money, discount, free product or service); burst = Part of a sudden burst of similar reviews from accounts you cannot match to customers; duplicate = The same or near-identical text posted more than once, from 1 account or several; impersonation = Posted by someone pretending to be another person, a business or an official. Breaks a rule in the text itself: harassment = Threats, doxxing, or sexualized remarks about a person; hate = Slurs, or calls for violence against a protected group; profanity = Profanity or obscenity used to offend; personal-info = A private person’s home address, phone number, photo, or financial, medical or ID details; advertising = An advert, a phone number or a link; wrong-business = About a different business or location; gibberish = Meaningless characters. Judgment calls (decided case by case): staff-name = Names a staff member or another private person by full or last name (not a first name alone); accusation = Accuses you or your staff of a crime or unethical conduct, with nothing to back it up; false-claims = Describes what you sell or do in a way that is false; rant = Political or social commentary, or a rant that is not about a visit. Not a rule violation: genuine = A real customer describing a bad experience; harsh = Harsh, exaggerated or unfair, but based on a real visit; old = Old, and the business has changed since; star-only = A low star rating with no text, from a real customer. Also happening: extortion = Someone demanded money or a favor to remove, or not post, reviews.
customerNoWhen ownership is business. Was the reviewer a real customer? Search bookings, orders, invoices and your CRM by name, email, phone and the dates the review mentions. yes = Yes, I can match them to a visit or order; no-record = No record after searching; unsure = Not sure yet.
evidenceNoCan you show it? Only for selected items that need proof: yes = the owner has it now, not-yet = not yet. A missing answer counts as not-yet. Items whose proof is the review text itself need no answer.
ownershipYesWhose review is it? mine = I wrote it; business = It is about my business; other = It is about another business.
false_factsNoDoes it state specific facts about your business that are false? no = No, it is opinion or a real experience; docs = Yes, and I have documents that prove it; no-docs = Yes, but no documents yet.no

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real behavioral context: it is free, it will not remove anything ('Google decides every removal'), and it explicitly discloses the negative-result rule ('A genuine negative review gets No policy match'). It does not discuss any rate limits or auth, but none appear to apply.

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?

It is front-loaded with the most decision-relevant facts ('Free and read-only', what it tells the owner) and no sentence is pure filler. The second sentence is a long colon-list that essentially restates the schema fields, making the passage denser than it needs to be, but overall the size is justified by what it communicates.

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?

There is no output schema, so the description carries the full burden of describing returns, and it does: verdict, Google's rule with policy link and read date, where to report, evidence to attach, timing, appeal path, templates, and the paid service only when offered. For a 6-parameter, nested-enum tool this is complete enough for an agent to run it correctly.

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 100%, so a 3 is the baseline, but the description adds meaning by turning the fields into a conversational sequence: whose review, whether the reviewer was a real customer, what it contains, whether they can show it, and where they are in Google's process. That ordering and the emphasis on collecting facts rather than the review text is guidance the schema alone does not convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: it tells a business owner whether a Google review matches one of Google's named review rules, and it even identifies the scope of the verdict (strong match, arguable, no policy match). That is far more precise than a restated name. It never names a sibling such as find_removal_route, so an agent comparing candidates still has to infer the boundary between 'judge removability' and 'find a removal route.'

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

Usage Guidelines3/5

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

It gives strong operational guidance for the interaction ('Ask the person for facts only, never the review text, a name or a link'), which implies the usage context. However, it never states when to choose this tool over siblings like find_removal_route, nor any exclusions or prerequisites beyond that one instruction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.