How do I use Review Guru MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Review Guru MCP Server Find top-rated restaurants in Colombo" 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.

Review Guru MCP Server

by kapruka

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Review Guru MCP Server

PyPI License: MIT

An MCP server that exposes Sri Lankan business reviews and doctor profiles from Review Guru to Claude Desktop, Cursor, Cline, or any MCP-aware AI agent.

No API key. No scraping. Calls a public, cached, rate-limited HTTPS endpoint.

What you get

Tool	What it does
`list_businesses(city?, category?, min_rating?, sort?, limit?)`	Ranked list of businesses. Sort: `top`, `most-reviewed`, `newest`.
`get_business(slug)`	Full profile: address, phone, hours, categories, rating breakdown, top 10 reviews.
`get_reviews(slug, sort?, limit?)`	Paginated reviews. Sort: `newest`, `highest`, `lowest`, `helpful`.
`search(query, limit?)`	Full-text search (FTS5) across every business and doctor.
`list_categories()`	Top-level categories + sub-categories with slugs.
`list_cities()`	Sri Lankan cities with business counts.

Plus a reviewguru://about resource that returns live counts.

Data covers restaurants, hotels, shops, salons, hospitals, Sri Lankan doctors with specialty + practice locations, and more — all with patient/ customer reviews.

Related MCP server: Local Business Data MCP Server

Install

With uv (recommended)

uvx reviewguru-mcp

With pipx

pipx install reviewguru-mcp
reviewguru-mcp

With pip

pip install reviewguru-mcp
reviewguru-mcp

The server speaks MCP over stdio — invoke it from any MCP client config.

Wire it up

Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json (Mac) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "reviewguru": {
      "command": "uvx",
      "args": ["reviewguru-mcp"]
    }
  }
}

Restart Claude Desktop. The 🔌 icon in chat will show the Review Guru tools.

Cursor

Settings → MCP → Add new MCP server:

Command: uvx
Args: reviewguru-mcp

Cline (VS Code)

Cline → Settings → MCP Servers → Add:

{
  "reviewguru": {
    "command": "uvx",
    "args": ["reviewguru-mcp"]
  }
}

Try it

Once wired up, ask your assistant things like:

Find me three highly-rated cardiologists in Colombo and tell me which hospital each one consults at.

What are people saying about Ministry of Crab? Pull the most recent five reviews.

I'm a vegetarian visiting Galle for a weekend — recommend two restaurants.

The model will pick the right tools and stitch the answers together.

Configuration

Environment variables (all optional):

Variable	Default	Effect
`REVIEWGURU_API`	`https://reviewguru.lk`	API base URL — point at staging or a fork.
`REVIEWGURU_URL`	`https://reviewguru.lk`	Used to render business URLs in tool output.
`DATABASE_URL`	(none)	If set to an existing SQLite path, server uses local DB instead of HTTP. Maintainer-only.

Rate limits + acceptable use

The public API is shared and lightly rate-limited (60 req/min per IP). For heavier usage, set REVIEWGURU_API to your own deployment.

Reviews are licensed for citation with attribution to Review Guru and a link back to the specific business URL. See reviewguru.lk/llms.txt for full LLM-usage guidelines.

Self-hosting

Want to fork? The server is one Python file (server.py). It auto-detects:

HTTP mode (default) — calls /api/v1 endpoints. Works anywhere.
SQLite mode — if data/reviewguru.db is present in the parent dir. Used by the maintainers for sub-millisecond local queries.

git clone https://github.com/kapruka/reviewguru-mcp
cd reviewguru-mcp
pip install -e .
reviewguru-mcp

License

MIT — see LICENSE.

Available Tools

6 tools

get_businessA

Get full details of a single business by slug, including location, contact info, categories, and the top 10 recent reviews.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations provided, the description carries full transparency burden. It discloses that only the top 10 reviews are returned, which is a key behavioral trait. However, it does not mention any side effects, authorization requirements, or other behavioral aspects beyond what is listed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that efficiently captures the tool's purpose and key outputs. No redundant or unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and a simple single-parameter input, the description is largely complete. It covers the main return elements, though it omits details like slug case sensitivity or uniqueness. The output schema can supplement return value details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one parameter (slug) with zero description coverage. The description only says 'by slug' without explaining what a slug is, its format, or how to obtain it. This provides minimal added meaning; the agent would need external knowledge to use the parameter correctly.

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?

Description clearly states the tool retrieves full details of a single business using its slug, enumerating included fields (location, contact info, categories, top 10 reviews). This distinguishes it from siblings like get_reviews (focused on reviews) and list_businesses (lists multiple businesses).

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?

Usage is implied: use when you need a specific business's details given its slug. However, no explicit guidance is provided on when not to use this tool (e.g., if slug is unknown, search would be better) or comparisons with sibling tools.

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

get_reviewsB

Get reviews for a business.

Args: slug: Business slug. sort: "newest", "highest", "lowest", or "helpful". limit: Max reviews, 1-100 (default 20).

ParametersJSON Schema

Name	Required	Default
`slug`	Yes
`sort`	No	newest
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided; description does not indicate read-only nature, authorization needs, or side effects. As a 'get' operation, it's likely non-destructive, but the description should clarify this given lack of annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is brief and includes a structured args list, but it redundantly restates schema defaults (sort, limit). The verb 'Get' could be more precise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers basic usage with parameters, but lacks details on response format, error handling, or rate limits. Output schema exists but is not referenced.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Description provides clear meaning beyond schema: specifies allowed values for 'sort' (newest, highest, lowest, helpful) and range for 'limit' (1-100, default 20). This compensates fully for the 0% schema description coverage.

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?

Description states 'Get reviews for a business' with a specific verb and resource, clearly distinguishing from siblings like 'get_business' which retrieves business details. However, it doesn't explicitly differentiate from other review-related siblings if any existed.

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?

No explicit guidance on when to use this tool versus alternatives like 'get_business' or 'search'. The purpose is implied but not contrasted with siblings.

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

list_businessesA

List Sri Lankan businesses with optional filters.

Args: city: City slug (e.g. "colombo", "nugegoda", "dehiwala"). Use list_cities() to discover. category: Category slug (e.g. "restaurants", "shopping", "doctors"). Use list_categories() to discover. min_rating: Minimum average rating 1-5. sort: "top" (Bayesian-weighted best), "most-reviewed", or "newest". limit: Max results, 1-100 (default 25).

ParametersJSON Schema

Name	Required	Default
`city`	No
`category`	No
`min_rating`	No
`sort`	No	top
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It covers parameter ranges and defaults but does not disclose pagination behavior, rate limits, or whether the list is exhaustive. Output schema exists but description lacks detail on response structure.

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?

The description is concise with a clear docstring format, front-loading the purpose. Each parameter gets a single line. Minor room for improvement in formatting compactness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 optional parameters and no annotations, the description covers purpose, parameter semantics, and related tools. Missing pagination details, but output schema provides return structure. Mostly complete for a listing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description adds substantial meaning by providing examples, valid ranges, and usage tips for each parameter (e.g., city slugs, sort options, limit bounds). This goes far beyond the schema's types and titles.

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?

The description clearly states 'List Sri Lankan businesses with optional filters,' specifying the verb (List) and resource (businesses). It distinguishes itself from siblings like get_business and search by emphasizing filtering capabilities.

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?

The description provides clear context for use with filters and references list_cities() and list_categories() for discovering slugs, but does not explicitly state when not to use this tool or mention alternatives.

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

list_categoriesA

List all categories with their parent/child hierarchy.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

No annotations, but description clearly indicates a read operation ('list') with scope 'all categories' and includes hierarchy detail. Simple behavior, no side effects expected, though permission needs or limits are not mentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with verb 'List', no extraneous words. Highly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a zero-parameter list tool with output schema. Could mention output schema structure but not necessary. Covers the core purpose well.

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?

No parameters, so baseline is 4. Description adds meaning by specifying 'with hierarchy', which is not in schema. Schema coverage is trivially 100%.

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?

Description clearly states 'List all categories with their parent/child hierarchy', providing a specific verb and resource, and distinguishes from sibling tools like list_businesses or get_reviews.

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?

No explicit guidance on when to use vs alternatives. The context is implied by the resource name and siblings, but no when-not-to-use or alternatives mentioned.

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

list_citiesA

List all cities on the platform with counts of listed businesses.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations, the description only mentions returning counts, but lacks details on side effects, auth requirements, or data freshness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded, with no unnecessary words; efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple list tool with output schema; minor gaps like missing pagination or auth notes, but overall sufficient.

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?

No parameters exist, so baseline is 4; description adds value by specifying 'with counts of listed businesses' beyond the empty 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?

The description clearly states it lists all cities with business counts, distinguishing it from sibling tools like list_businesses or list_categories.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like list_businesses or search; no context on typical use cases.

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

searchA

Full-text search across all businesses. Uses SQLite FTS5 server-side.

Args: query: Free text — name, cuisine, neighborhood, doctor specialty, etc. limit: Max results, 1-50 (default 20).

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It only mentions the use of SQLite FTS5, but does not disclose behavioral traits such as case sensitivity, ranking, pagination, rate limits, or performance implications. More detail is needed for a search tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise: two sentences and a brief argument list. Every word serves a purpose, and the structure is front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists, the description does not need to explain return values. It covers the search scope and parameter details. However, it could add more on how FTS5 affects search behavior (e.g., stemming, stopwords) for full completeness.

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 0%, so the description must compensate. It explains the query parameter with examples (free text for name, cuisine, etc.) and the limit parameter with valid range and default. This adds meaningful context beyond the raw 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?

The description states 'Full-text search across all businesses' and specifies that it uses SQLite FTS5. This is a specific verb-resource combination that clearly distinguishes it from sibling tools like get_business or list_businesses.

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?

The description provides clear context for use (searching across businesses with free text) and gives examples (name, cuisine, etc.). However, it does not explicitly state when not to use it or which sibling tools are alternatives, though the distinction is implied.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv0.1.2May 26, 2026
- First observedget_business
- First observedget_reviews
- First observedlist_businesses
- First observedlist_categories
- First observedlist_cities
- First observedsearch

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-05-26 21:00 across 6 tools

Disambiguation5/5

Each tool serves a clearly distinct purpose: get a single business, get reviews, list businesses with filters, list categories, list cities, and search. No overlap in functionality.

Naming Consistency4/5

Most tools follow a verb_noun pattern (get_business, get_reviews, list_businesses, list_categories, list_cities), but 'search' lacks a noun suffix, creating a minor inconsistency.

Tool Count5/5

Six tools is an appropriate number for a review server, covering discovery, search, and details without unnecessary bloat or deficiency.

Completeness5/5

The set provides full read-only coverage: discover categories/cities, list and search businesses, get details, and retrieve reviews. No missing operations for a read-only API.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

ReputeMap A
com.reputemap
Read and filter your Google Business Profile reviews, get stats, and send review requests.
Marketing Customer Support
71
monitoringOAuth
com.repuso
Google reviews API - fetch reviews from Google, Trustpilot, TripAdvisor, G2 + 50 platforms
Monitoring Web Scraping Product Management
1
Pod AOAuth
io.github.Marvy101
Search and share firsthand reviews of products, APIs, services, places, and organizations.
Search
1
revieworacle B
io.tooloracle
ReviewOracle - 8 review intel tools: sentiment, themes, competitors, response drafts.
Customer Support Marketing Product Management
82

Related MCP Servers

MercadoLibre MCP Server
E-commerce & Retail Search
lumile
A
license
B
quality
D
maintenance
Enables interaction with MercadoLibre's API for product search, reviews, descriptions, and seller reputation insights.
Updated a year ago (2025-05-28 17:28 UTC)
3
11 npm
7
MIT
Local Business Data MCP Server
Location Services Search
BACH-AI-Tools
A
license
B
quality
D
maintenance
Enables access to Google Maps business data including search, reviews, photos, and geocoding. Supports searching businesses by location, area, or coordinates, retrieving detailed business information, reviews, and performing reverse geocoding operations.
Updated 9 months ago (2025-12-07 20:33 UTC)
13
MIT
OpenReview MCP server
Research & Data Open Data AI & Machine Learning
anyakors
A
license
Not graded
quality
D
maintenance
Enables searching for users, fetching papers, and exporting research data from OpenReview conferences like ICML, ICLR, NeurIPS.
Updated 8 months ago (2026-01-16 00:12 UTC)
12
MIT
tripadvisor-mcp
Travel & Transportation Location Services Search
chrischall
A
license
A
quality
A
maintenance
Enables search and retrieval of travel data from TripAdvisor, including hotels, restaurants, and attractions, with details, photos, and reviews.
Updated 2 days ago (2026-09-15 19:20 UTC)
8
518 npm
MIT

Review Guru MCP Server

What you get

Install

With uv (recommended)

With pipx

With pip

Wire it up

Claude Desktop

Cursor

Cline (VS Code)

Try it

Configuration

Rate limits + acceptable use

Self-hosting

Links

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers