This MCP server gives MCP clients live access to a curated robot lawn mower dataset (70 wire-free models, 15 brands) for specs, prices, scores and buying recommendations.
List and filter mowers (list_robot_mowers): by brand, navigation type (RTK, wire, vision, GNSS), max price, minimum coverage, minimum slope handling and minimum 0-5 score; sort by score, price, coverage or price per m², with a configurable result limit.
Look up one mower (get_robot_mower): full spec sheet, sub-scores and cited sources by model name or slug.
Compare mowers (compare_robot_mowers): side-by-side comparison of 2 to 4 models on price, navigation, coverage, slope, cutting specs and scores.
Get tailored recommendations (recommend_robot_mower): best-fit picks from lawn size (m²) plus optional slope, budget and obstacle-avoidance requirement.
Answer real buying questions, e.g. the best mower under $1500 for a 700 m² lawn, or which RTK mowers handle a 40% slope.
Connect without installing anything via the hosted Streamable HTTP endpoint at https://bestrobotmower.co/api/mcp, or run locally over stdio with npx -y github:yumaheymans/bestrobotmower-mcp (Node.js 18+, no API key).
Stay current: queries the live dataset API on start and falls back to a bundled snapshot when offline.
Provides detailed specs, dated prices, and 0-5 scores for Ecovacs Goat robot lawn mowers from the BestRobotMower.co dataset, enabling assistants to look up, compare, and recommend Ecovacs models against other brands.
Provides detailed specs, dated prices, and 0-5 scores for Husqvarna robot lawn mowers from the BestRobotMower.co dataset, enabling assistants to look up, compare, and recommend Husqvarna models against other brands.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@BestRobotMower MCP Server Recommend a robot mower for a 600 m2 lawn with a 25% slope."
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.
A Model Context Protocol server that gives any MCP client (Claude, ChatGPT, Cursor, VS Code, Ollama, and others) direct access to robot lawn mower specs, prices, transparent 0-5 scores and buying recommendations, so your assistant answers from a curated, cited dataset instead of guessing from stale training data.
It is powered by the open BestRobotMower.co dataset (76 wire-free robot mowers across 15 brands as of October 2026: Segway Navimow, Mammotion Luba and Yuka, MOVA LiDAX, Ecovacs Goat, Dreame, Roborock, Anthbot, Airseekers, Sunseeker, Husqvarna, Worx Landroid, Yarbo, eufy, Lymow and EcoFlow; 30+ fields per model, dated prices and a documented scoring methodology, published under CC BY 4.0). The server queries the live dataset API on start, so prices and new models are current, and falls back to a bundled snapshot (2026-10-05) when offline.
Tool | What it does |
| List and filter mowers by brand, navigation type, price, coverage, slope and minimum score; sort by score, price, coverage or value. |
| Full spec sheet, sub-scores and cited sources for one mower by name or slug. |
| Side-by-side comparison of 2 to 4 mowers on price, navigation, coverage, slope, cutting specs and scores. |
| Best-fit picks for a specific yard: give the lawn size (m2) and optionally slope, budget and whether obstacle avoidance is required. |
Example questions your assistant can now answer: "What is the best robot mower under $1500 for a 700 m2 lawn?", "Compare the Mammotion Luba 3 AWD and the Segway Navimow X4", "Which RTK mowers handle a 40% slope?"
Related MCP server: ai-orders-agent
The server also runs as a hosted, remote MCP server, so clients that support remote MCP over Streamable HTTP can connect with nothing to install:
https://bestrobotmower.co/api/mcpIt is listed in the Official MCP Registry as io.github.yumaheymans/bestrobotmower-mcp. Example client config:
{
"mcpServers": {
"bestrobotmower": { "url": "https://bestrobotmower.co/api/mcp" }
}
}Prefer to run it locally instead (or use a client without remote support)? Use the stdio install below.
No API key required. Requires Node.js 18+.
Run directly from GitHub:
npx -y github:yumaheymans/bestrobotmower-mcpOr clone and run:
git clone https://github.com/yumaheymans/bestrobotmower-mcp.git
cd bestrobotmower-mcp
npm install
node index.jsAdd to your MCP client config (for example Claude Desktop's claude_desktop_config.json):
{
"mcpServers": {
"bestrobotmower": {
"command": "npx",
"args": ["-y", "github:yumaheymans/bestrobotmower-mcp"]
}
}
}The mower data is the BestRobotMower.co Robot Lawn Mower Specs & Scores dataset, licensed CC BY 4.0. If you build on it, attribute BestRobotMower.co and link to https://bestrobotmower.co/dataset.
Live feeds: mowers.json and mowers.csv.
Scoring methodology: https://bestrobotmower.co/methodology.
This server's code is released under the MIT License.
Built and maintained by BestRobotMower.co.
Compare 2 to 4 robot lawn mowers side by side on price, navigation, coverage, slope, cutting specs and scores.
| Name | Required | Description | Default |
|---|---|---|---|
| models | Yes | Model names or slugs to compare. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It says the tool compares models side by side, which implies a read-like behavior, but it does not explicitly confirm no side effects, explain the origin or reliability of scores, or describe any output behavior beyond the comparison.
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 states the action, count, and comparison dimensions with no filler or repetition. Every phrase carries information.
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 only one required array parameter and a clear schema, the description is sufficient to build a valid call. Still, with no output schema, it does not specify the return format, how scores are derived, or how invalid model names are handled, leaving modest gaps for an agent.
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 description coverage is 100%: the schema already documents models as an array of model names or slugs with min 2 and max 4. The description underscores these constraints and adds the compared attributes, but it does not add crucial parameter-level detail beyond the schema, so the baseline applies.
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 an explicit verb, Compare, a clear resource, robot lawn mowers, a cardinality range of 2 to 4, and a concrete list of comparison dimensions. This clearly distinguishes it from siblings list_robot_mowers, get_robot_mower, and recommend_robot_mower.
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 description implies usage when a user needs multi-model comparisons rather than listing, fetching one model, or getting a recommendation. However, it does not explicitly name the sibling alternatives or state when not to use this tool, leaving the routing decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full spec sheet, sub-scores and cited sources for one robot lawn mower by model name or slug.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Model name or slug, e.g. 'Mammotion Luba 3 AWD' or 'segway-navimow-i105e'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It helpfully discloses return contents (spec sheet, sub-scores, cited sources), but does not address read-only nature, error behavior for unknown models, authentication, or other operational traits.
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, front-loaded with the verb and resource, then the returned payload and lookup key. No wasted words.
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 simple one-parameter retrieval tool with no output schema, the description sufficiently states what is returned and how to identify the mower. Minor gaps remain around miss/error behavior, but nothing essential for correct invocation 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?
Schema description coverage is 100% and the single 'query' parameter is already documented with examples. The description only restates that lookup is by model name or slug, adding no format or matching details beyond 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?
The description names a specific verb ('Get'), resource ('robot lawn mower'), and scope ('one'), plus what is returned: full spec sheet, sub-scores, and cited sources. This clearly separates it from list_robot_mowers and compare_robot_mowers by cardinality, though it does not explicitly name an alternative sibling.
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: call this when you need details for a single mower identified by model name or slug. There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance naming list, compare, or recommend tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List and filter robot lawn mowers from the BestRobotMower.co dataset. Filter by brand, navigation type, price, lawn coverage, slope handling and minimum score; sort by score, price, coverage or value.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | Filter by brand, e.g. Husqvarna, Segway, Worx (case-insensitive substring). | |
| limit | No | Max results to return (default 10, up to the whole catalog). | |
| sort_by | No | Sort key. Default 'score' (best first). 'price' and 'price_per_m2' ascend; 'coverage' and 'score' descend. | |
| min_score | No | Only mowers with at least this BestRobotMower Score (0-5). | |
| navigation | No | Filter by navigation type substring, e.g. 'RTK', 'wire', 'vision', 'GNSS'. | |
| max_price_usd | No | Only mowers at or below this USD price. | |
| min_slope_pct | No | Only mowers that handle at least this slope (percent grade). | |
| min_coverage_m2 | No | Only mowers that cover at least this many square meters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing beyond what the schema already encodes. It does not state that this is a read-only operation, whether results are paginated, how the default limit interacts with the full catalog, or what the response shape looks like.
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 with the resource and dataset front-loaded and the filter/sort surface enumerated immediately after. No filler, though the second sentence reads as a schema restatement rather than new information.
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 an 8-parameter tool with no annotations and no output schema, the description covers the input surface adequately but says nothing about the returned records (fields, pagination, tie-breaking), which the agent would need since 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?
Schema coverage is 100%, so every parameter is already documented with examples and sort-direction semantics in the schema itself. The description restates the filter axes (brand, navigation, price, coverage, slope, score) but adds no new syntactic or semantic detail, making the baseline 3 appropriate.
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 (list) and resource (robot lawn mowers) plus the source dataset, so the agent knows exactly what it returns. It doesn't explicitly contrast itself with siblings like get_robot_mower or compare_robot_mowers, but the 'list and filter' framing is clear enough to distinguish it from a single-record lookup.
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 by the filter/sort enumeration — this is the tool for browsing or narrowing the catalog. However, there is no explicit guidance on when to prefer it over recommend_robot_mower or compare_robot_mowers, and no stated prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend the best-fitting robot lawn mowers for a specific yard: give the lawn size and optionally slope, budget and whether obstacle avoidance is needed.
| Name | Required | Description | Default |
|---|---|---|---|
| budget_usd | No | Maximum budget in USD (optional). | |
| lawn_area_m2 | Yes | The lawn size to cover, in square meters. | |
| max_slope_pct | No | The steepest slope in the yard, percent grade (optional). | |
| needs_obstacle_avoidance | No | Set true to require built-in obstacle avoidance (optional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of disclosing behavior. It indicates a recommendation action but does not state that it is read-only (no side effects), does not explain how the recommendation is computed, and does not mention what happens when no mower matches the criteria. The word 'recommend' implies non-mutating, but this is not explicitly stated.
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?
The description is a single, front-loaded sentence that states the purpose first and then lists the key inputs. There is no fluff or redundancy; every word contributes to understanding the tool's function.
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 and no annotations, the description should explain what the tool returns (e.g., a ranked list, a single top pick, or a set of options). It does not describe the output format, nor does it mention edge cases like oversized yards or incompatible slopes. An agent cannot fully anticipate the tool's behavior beyond the basic recommendation intent.
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 100%, so the baseline is 3. The description rephrases the parameters ('lawn size', 'slope', 'budget', 'obstacle avoidance') without adding new meaning beyond the schema's own parameter descriptions. It does not clarify units or format, but the schema already covers those (e.g., slope in percent grade, budget in USD).
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 states a specific verb (recommend), a resource (robot lawn mowers), and the context (best-fitting for a specific yard). It clearly differentiates from siblings: list_robot_mowers (listing), get_robot_mower (retrieving one), and compare_robot_mowers (comparing) – this tool produces a tailored recommendation based on yard parameters.
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 description tells the agent what inputs to provide (lawn size, optional slope, budget, obstacle avoidance) but does not explicitly state when to use this tool versus its siblings. It implies it is for recommendation scenarios, but there is no exclusion guidance such as 'use list_robot_mowers to browse all models' or 'use compare_robot_mowers for side-by-side comparisons.'
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.
v1.1.0get_robot_mower1 field changedInput schema / properties / query / descriptionPrevious value: -"Model name or slug, e.g. 'Husqvarna Automower 450X' or 'segway-navimow-i105e'."New value: +"Model name or slug, e.g. 'Mammotion Luba 3 AWD' or 'segway-navimow-i105e'."list_robot_mowers1 field changedInput schema / properties / limit / descriptionPrevious value: -"Max results to return (default 10, max 23)."New value: +"Max results to return (default 10, up to the whole catalog)."v1.0.0compare_robot_mowersget_robot_mowerlist_robot_mowersrecommend_robot_mowerScored across 4 tools
Each tool has a clearly distinct purpose: list (browse/filter), get (single full record), compare (2-4 side by side), and recommend (yard-specific matching). There is minimal risk of misselection since the resource+action combos don't overlap.
All four tools follow a consistent verb_noun pattern (list_robot_mowers, get_robot_mower, compare_robot_mowers, recommend_robot_mower). Plural/singular usage is predictable and readable.
Four tools is well-scoped for a read-only dataset server; each covers a distinct retrieval mode with no redundancy. Nothing feels missing or excessive for the stated purpose.
The query surface (browse, fetch, compare, recommend) fully covers a read-only dataset domain. Minor gap: no tool to enumerate available brands/navigation types/facets, though filters on list_robot_mowers allow agents to work around this.
Google Shopping products, prices, sellers, and deals as structured data via a hosted MCP server.
MowRouteWorks: the site's own MCP server — dataset; every answer cites the site.
Open, verified shop database for AI agents: products, offers, price comparison, trust and coupons.
Hosted MCP for e-commerce: live product catalog, stock, and pricing for AI agents.