# RiLiGar Messages — MCP Server

Transactional e-mail, domains, templates and suppressions, per project.

Endpoint: `https://messages.worker.myinfrastructure.click/mcp/<projectId>`
Protocol: MCP revision 2026-07-28, Streamable HTTP, stateless. `POST` only —
`GET` and `DELETE` answer 405.

## Authentication — OAuth 2.1, and nothing else

```
Authorization: Bearer <OAuth access token>
```

The token is issued by RiLiGar Auth and identifies a PERSON. Your client
discovers the authorization server on its own: call the endpoint without a
credential, read the 401, follow the challenge.

```
WWW-Authenticate: Bearer
  resource_metadata="https://messages.worker.myinfrastructure.click/.well-known/oauth-protected-resource",
  scope="messages:read messages:write messages:admin"
```

**API keys do not authenticate here.** RiLiGar Messages's key is the credential of the
REST API; sending it to this endpoint returns 401. MCP is for people, the REST
API is for machines — and the token, unlike a key, says which person and with
which consent.

### The audience is what isolates one server from another

The token's `aud` must be this project's resource — `https://messages.worker.myinfrastructure.click/mcp/<projectId>`.
A token issued for another RiLiGar MCP is refused here even carrying the same
scope names (RFC 8707). It is the audience, not the scope name, that separates
one service from the next.

### Connecting

```bash
claude mcp add --transport http messages https://messages.worker.myinfrastructure.click/mcp/<projectId>
```

No key in the command, and no secret in a config file: you approve in the
browser and the client stores the token.

## Tools — 12 in total

The catalogue is filtered by the token's scopes: a tool outside them is not
registered, so it does not appear in `tools/list` and calling it by name fails.

The project always comes from the address, never from a tool argument — that is the defence against prompt injection.

### Read — scope `messages:read`

- `messages_get_email`
- `messages_get_metrics`
- `messages_get_project`
- `messages_list_domains`
- `messages_list_emails`
- `messages_list_suppressions`

### Write — scope `messages:write`

- `messages_add_domain`
- `messages_create_template`
- `messages_send_email`
- `messages_verify_domain`

### Admin — scope `messages:admin`

- `messages_remove_suppression`
- `messages_set_notify_email`
Lifting a suppression or redirecting the alerts affects the account’s reputation.

## Errors

A business error is a RESULT, not a transport failure: HTTP 200 with
`isError: true` and a readable reason. The agent needs the refusal as an
answer it can act on.

Transport and authentication failures do use HTTP status:

| Status | Meaning |
|---|---|
| 401 | No credential, an invalid token, or an API key sent instead of a token |
| 403 | Identity known, scope missing |
| 404 | No `projectId` in the address |
| 405 | `GET` or `DELETE` — this revision has no session |

## Also see

- `https://myinfrastructure.click/products/messages/llms.txt` — the REST API, where the API key belongs
- `https://myinfrastructure.click/products/auth/llms-mcp.txt` — Auth as the authorization server