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 (23 wire-free and RTK robot mowers across 9 brands, 19 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 and falls back to a bundled snapshot 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 Husqvarna Automower 450X and the Segway Navimow i105E", "Which RTK mowers handle a 40% slope?"
Related MCP server: ai-orders-agent
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. 'Husqvarna Automower 450X' 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 burden of behavioral disclosure. It does disclose the return contents (spec sheet, sub-scores, cited sources) and implies a read-only operation via 'Get', but it does not describe behavior on unrecognized model names, ambiguous matches, or any side effects. This is adequate but not rich.
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, well-structured sentence with no filler. It front-loads the key return information and then states the selection criterion, saying everything necessary in few 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 lookup tool with no output schema, the description adequately covers what the tool returns and how to identify the target mower. It does not address not-found or ambiguity behavior, but the core information an agent needs to invoke the tool correctly is present.
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 schema already documents the query parameter with examples. The description slightly reinforces the parameter's role as the identifier for a single mower, but it does not add significant meaning beyond the structured schema, so the baseline score of 3 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 uses a specific verb ('Get') and resource ('full spec sheet, sub-scores and cited sources for one robot lawn mower'), and the qualifier 'for one' clearly distinguishes it from the sibling tools that list, compare, or recommend mowers. An agent can tell exactly what this tool does without opening the schema.
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 clearly establishes the context: use this when you need detailed information for a single known mower identified by model name or slug. It does not explicitly name alternatives or exclusions, but the sibling names and the 'one robot lawn mower' scope make the intended use relatively clear.
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, max 23). | |
| 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 bears the full burden of behavioral disclosure. It states the action (list and filter) and mentions sort/filter options, but it does not disclose return format, pagination, read-only status, rate limits, or side effects. For a read-operation that ostensibly returns a list of mowers, this is minimal disclosure; an agent must infer safety and output structure.
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, well-structured sentence that front-loads the primary action ('List and filter') followed by an enumeration of filter and sort options. It contains no fluff, tautology, or unnecessary detail. Every word contributes to the tool's purpose.
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 8 parameters and no output schema, the description covers the main capabilities but leaves out return format (list of objects? fields?), pagination (though limit is in schema), and any behavioral nuances. For a list/filter tool, it is adequate but lacks explicit details about what the result looks like or any constraints like 'returns up to limit results.' Given complexity, it could be richer.
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%, so the baseline is 3. The description adds a concise summary of filter and sort capabilities (e.g., 'brand, navigation type, price, lawn coverage, slope handling and minimum score') that aligns with the parameters but does not introduce new meaning beyond the schema. It fails to clarify the 'value' sort option (price_per_m2) beyond what the schema already states, so no significant added value.
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 clearly states the tool's purpose: 'List and filter robot lawn mowers from the BestRobotMower.co dataset.' This is a specific verb (list/filter) plus a resource (robot lawn mowers) and a dataset source. It implicitly distinguishes from siblings like get_robot_mower (retrieves a single mower) and compare_robot_mowers (compares), as listing is a distinct operation. No ambiguity.
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 this tool is for browsing/filtering the dataset, but it does not explicitly mention when to use it versus the sibling tools. There is no 'when-not-to-use' or alternative naming. The context is clear enough that an agent would infer this is the right tool for listing/filtering, but it lacks explicit guidance 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.0.0compare_robot_mowersget_robot_mowerlist_robot_mowersrecommend_robot_mowerScored across 4 tools
Each tool has a clearly distinct purpose: listing/filtering, retrieving details, comparing, and recommending. There is no overlap in what an agent would use each tool for.
All tool names follow a consistent verb_noun pattern: list_robot_mowers, get_robot_mower, compare_robot_mowers, recommend_robot_mower. The pattern is predictable and uniform.
Four tools is well-scoped for a niche product dataset: browse, inspect, compare, and recommend. Each tool earns its place without redundancy or bloat.
The surface covers the full consumer workflow: discover, detail, compare, and get personalized recommendations. Minor gaps like explicit review retrieval or accessory filtering exist, but they are not essential to the core purpose.
Google Shopping products, prices, sellers, and deals as structured data via a hosted MCP server.
Open, verified shop database for AI agents: products, offers, price comparison, trust and coupons.
MCP server for structured Dutch vehicle data and license plate intelligence. Access RDW-based vehicle specifications, registration details, APK information, fuel and emissions data, weights, dimensions, ownership-related signals and other vehicle knowledge through KentekenKompas.nl. Built for AI assistants, agents and applications that need reliable, machine-readable information about vehicles registered in the Netherlands.
Hosted MCP for e-commerce: live product catalog, stock, and pricing for AI agents.
