# MCP server

> Connect Claude, Cursor, Codex or any MCP client to a restaurant's compliance records with one URL and your API key.

Source: https://developers.backresto.com/en/docs/mcp

BackResto runs a **Model Context Protocol** server at
`https://api.backresto.com/mcp`. Connect your AI tool to it with your API key
and you can ask questions of a restaurant's records in the tool's own
interface: no code, nothing to install on our side, nothing to host on yours.

It reads through the same Partner API as everything else, with the same key.
**It cannot see anything the key could not already see**: the restaurant and
scope grants are enforced by the API, not by the tool you connect.

## Connect your tool

You need a key first; see [Getting a key](https://developers.backresto.com/en/docs/access). Then pick your tool:

### Claude

1. **Add a custom connector**: In Claude, on the desktop app or on claude.ai, open Customize, then Connectors, and click Add custom connector. On a Team or Enterprise plan, an owner adds it once in the organisation settings first.

2. **Name it and paste the address**: Call it BackResto and paste this URL. Under Authentication and OAuth client, Claude detects our server and preselects Sign in now and Register automatically: keep those two. Don't enter a client ID or a secret. Then click Add.

```
https://api.backresto.com/mcp
```

3. **Connect with your key**: Click Connect. A BackResto page opens: paste your key, starting with brp_, and click Connect. Claude comes back with the connector switched on, with five tools.

4. **All done**: Ask about your records in plain words: temperatures, cleaning, deliveries, labels. The key already knows which restaurant is yours.

### Claude Code

1. **Register the server**: Open a terminal and run this command, with your key in place of brp_YOUR_KEY.

```sh
claude mcp add --transport http --scope user backresto \
  https://api.backresto.com/mcp \
  --header "Authorization: Bearer brp_YOUR_KEY"
```

2. **Check the connection**: Start Claude Code and type /mcp. backresto is listed as connected, with five tools.

3. **All done**: Ask about your records in plain words: temperatures, cleaning, deliveries, labels. The key already knows which restaurant is yours.

### Cursor

1. **Open the MCP settings**: In Cursor, go to Settings, then Tools & MCP, and click New MCP Server. That opens mcp.json.

2. **Add the server**: Paste this into mcp.json, with your key in place of brp_YOUR_KEY. The server appears in the list with five tools.

```json
{
  "mcpServers": {
    "backresto": {
      "type": "http",
      "url": "https://api.backresto.com/mcp",
      "headers": {
        "Authorization": "Bearer brp_YOUR_KEY"
      }
    }
  }
}
```

3. **All done**: Ask about your records in plain words: temperatures, cleaning, deliveries, labels. The key already knows which restaurant is yours.

### Codex

1. **Put your key in the environment**: Codex reads a bearer token from an environment variable rather than from its configuration file. Add this line to your shell profile, with your key in place of brp_YOUR_KEY.

```sh
export BACKRESTO_API_KEY="brp_YOUR_KEY"
```

2. **Register the server**: Then run this once. Codex will send the variable's value as the Authorization header.

```sh
codex mcp add backresto \
  --url https://api.backresto.com/mcp \
  --bearer-token-env-var BACKRESTO_API_KEY
```

3. **All done**: Ask about your records in plain words: temperatures, cleaning, deliveries, labels. The key already knows which restaurant is yours.

### Other

1. **Open your tool's MCP settings**: Find the MCP or integrations section and add a remote server using Streamable HTTP. If your tool asks only for a URL, it opens a BackResto page where you paste the key, and you can skip the header.

2. **Enter the address**: This is the server URL.

```
https://api.backresto.com/mcp
```

3. **Add your key as a header**: Send it with every request as the Authorization header.

```
Authorization: Bearer brp_YOUR_KEY
```

4. **All done**: Ask about your records in plain words: temperatures, cleaning, deliveries, labels. The key already knows which restaurant is yours.

## The tools

Five tools: one that finds the restaurant, and four that read its
[collections](https://developers.backresto.com/en/docs/collections).

| Tool | What it does |
| --- | --- |
| `backresto_list_restaurants` | Lists the restaurants the key reaches, with its scopes on each. |
| `backresto_list_collections` | Lists the collections this key was granted, with the scope that opened each. The right first call when you do not know what the key reaches. |
| `backresto_list_records` | Reads a page of records from one collection, tombstones included. Takes `collection`, optional `limit` (1-100, default 50) and `cursor`. |
| `backresto_get_record` | Fetches one record by `collection` and `recordId`. |
| `backresto_list_record_assets` | Lists the files attached to a record (`cleaning-task-pictures`, `delivery-pictures`, `traceability-labels` or `drive-files`) as signed URLs, and shows photographs to the model as images it can look at. |

Deliveries are two of those collections, `deliveries` and `delivery-pictures`,
read with the same tools as everything else. See [Deliveries](https://developers.backresto.com/en/docs/deliveries)
for what their fields mean.

`restaurantId` is optional everywhere. Leave it out and the key's own restaurant
is used, so a restaurant with one key never has to know its identifier. Only a
key that reaches several restaurants is asked to choose, and the error names the
choices.

All five are declared read-only and idempotent, so a well-behaved client will
not ask permission for each call the way it does for a tool that writes.

Two practical limits. Photographs are inlined for the model up to **ten images
and about 7.5 MB** per call to `backresto_list_record_assets`; anything beyond that still appears in the summary,
with its URL and the reason it was not shown. And the whole endpoint shares the
Partner API [budget](https://developers.backresto.com/en/docs/rate-limits) of 300 requests a minute per key: one
tool call is one request, which a conversation will never approach and a loop
will.

## Keeping the key safe

The key is the whole of your access, and an MCP client's configuration is an
ordinary file on a laptop.

- **Never commit that file.** If your tool keeps its configuration in a
  repository, reference an environment variable or an OS secret store instead,
  as the Codex setup above does.
- **Give each machine its own key.** One key per laptop means a lost laptop is
  one revocation, not a rotation across every integration you run.
- **Ask us when a key was last used** if you suspect a copy is still live
  somewhere you thought it was gone. We can see when each key last
  authenticated, and a revocation is the same email.

## Connecting by URL alone

Claude (desktop and claude.ai), ChatGPT and other tools that take only a server
URL connect through OAuth: they register with BackResto on their own, then open
a BackResto page where you paste your key once. Nothing to install and no
configuration file. The tool keeps the key and sends it for you, so it reaches
exactly what the key reaches, and revoking the key disconnects it.

There is no sign-in with a BackResto account yet: the key is still the
credential. If signing in with your account is what stands between you and an
integration, say so: it moves up the list.

## What it is good at

Concretely, with the tools connected, an operations lead can ask:

- *"Which deliveries were refused last month, and why?"*
- *"Show me every chicken delivery above 4 °C this quarter."*
- *"Show me the photos of the delivery refused on Tuesday: is the damage visible?"*
- *"Which fridges went out of range most often, and in which area?"*
- *"Did the cooling cycles all come down in time last week?"*
- *"Which cleaning tasks were skipped, and which have no photograph?"*

The first three read the `deliveries` and `delivery-pictures` collections, the
rest read other [collections](https://developers.backresto.com/en/docs/collections), and every one of them only
what your key was granted. The
answers come from the same records an inspector would read, through the same
grants the restaurant issued.

A model reading collections should be told what it is reading: a snapshot of
what the API received, not a guaranteed-complete history. If you put this in
front of a customer, put that sentence next to it.