RuralCheck MCP server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RURALCHECK_WAIT_S | No | How long one tool call waits for a report before handing back an id. | 45 |
| RURALCHECK_API_KEY | Yes | Your RuralCheck API key, for stdio. Required. | |
| RURALCHECK_AUTH_URL | No | The OAuth authorization server. Defaults to the public URL. | |
| RURALCHECK_BASE_URL | No | Where the API is. | https://ruralcheck.eu |
| RURALCHECK_PUBLIC_URL | No | Where the hosted server is reached, for its OAuth metadata. | https://ruralcheck.eu |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| find_placeA | Turn a village, town, region, country or postcode in Europe into coordinates. Also reads plus codes and map links. A region, country or postcode comes back
with |
| check_coverageA | Whether RuralCheck can analyse this point, and how finely the ground is measured.
|
| list_checksA | Every check a report can run: its name, what it answers, roughly how long it
takes, and whether the free plan runs it ( |
| analyse_plotA | Analyse a plot of rural land in Europe and return the result of each check. Checks a chosen one depends on run too and are returned with it. Most answers take a few seconds. If one runs longer than this call waits, the answer carries an id to pass to get_report. An account can start one new report a minute, so name every check needed in one call. Fetching a report with get_report does not count. Show the |
| get_reportA | Fetch a report analyse_plot started, by its id. Waits if it is still running. |
| sample_reportA | The public sample: a real full report for 4 ha of land at Trémolat in the Dordogne valley, France. Use it to see what each check returns before asking for a report of your own. |
| upload_listingsA | Send an estate agent's listings to RuralCheck. Professional plan. Each listing becomes a saved plot with a full report and a share link the agent can put in the listing. Reports run one after another on the server, about half a minute each, and wait for anyone using the site, so this returns at once with the upload's id. Follow it with get_listing_upload. Up to 100 listings run from one upload. A listing that is not run comes back with the reason, for example no position, outside the area covered, or past the limit. A listing already saved with a current report is not run again. One upload runs at a time on an account. |
| get_listing_uploadA | An upload's progress: for each listing its status, its share link once its
report is done, or the reason it was not run. |
| list_listing_uploadsB | The account's listing uploads, newest first, with how far each has got. |
| list_plotsA | The plots this account keeps, newest first, with the key figure of each check, and the account's folders. Plots in the Trash are left out unless in_trash is true. Each one there has a
|
| get_plotA | One kept plot with its report, as it was when it was kept.
|
| save_plotA | Keep a finished report in My plots. Only a report that ran every check of the account's plan can be kept, so call analyse_plot without naming checks first. Keeping the same point again replaces its report, keeps its name and note, and takes it out of the Trash if it was there. |
| update_plotA | Rename a kept plot or replace its note. A plot in the Trash must be restored first. |
| file_plotA | Put a kept plot in a folder, or take it out of the one it is in. |
| delete_plotA | Move a kept plot to the Trash. It can be restored with restore_plot until its |
| restore_plotA | Take a plot out of the Trash, back into its folder if that still exists. |
| list_foldersB | The account's folders, each with how many plots are in it. |
| create_folderA | Make a folder for kept plots. Each name can be used once, whatever the case. |
| rename_folderC | Rename a folder. |
| delete_folderA | Delete a folder. Its plots stay in My plots, in no folder. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 20 tools
Most tools target distinct resources or lifecycle stages: plot management, folder management, uploads, checks/reports, and geography. The main potential overlap is find_place versus check_coverage, since find_place also returns `served`, but check_coverage is clearly framed as the analysis eligibility check. get_report, get_plot, and get_listing_upload are also separable by their resource names.
The set is predominantly consistent snake_case with a verb_noun pattern across CRUD and lifecycle tools: list_plots, get_plot, save_plot, update_plot, delete_plot, create_folder, etc. Minor deviations like sample_report and the plural-heavy list_listing_uploads are readable and do not undermine the overall convention.
At 20 tools, the surface is at the heavy end of the recommended range, partly because plot CRUD and folder CRUD are expanded into many individual operations. Each tool has a coherent role, but the count is borderline for the server's scope and could tempt consolidation.
Core workflows are well covered: place lookup, coverage checking, report analysis, report fetching, sample reports, upload progress, plot lifecycle including trash/restore, and folder CRUD. Minor gaps exist, such as no explicit upload cancellation or per-listing retry operation, but they are unlikely to block typical agent workflows.