MCP server

Brila speaks the Model Context Protocol, so you can connect your account to an AI client — Claude, Cursor, or anything else that speaks MCP — and ask about your discount codes in plain language instead of writing API calls.

https://mcp.brila.me

It is the same data as the REST API, authenticated with the same personal access tokens, enforcing the same scopes. What changes is the shape: the tools are written to be read by a model rather than post-processed by your code.

What you can do with it today

Every tool is read-only:

Tool	Scope	Answers questions like
list_discount_codes	discount_codes:read	"What codes do I have live?" · "Which of mine expired?"
list_saved_discount_codes	saved_codes:read	"Which saved codes expire soon?" · "What was that code I saved from Studio Wren?"

Nothing here can change your account. Creating and editing codes still goes through the web app or POST /api/v1/profiles/{handle}/discount_codes.

Connecting

1. Create a token

In Brila, go to Settings → API Tokens and create a token with the scopes you want the assistant to have. Granting only discount_codes:read and saved_codes:read is enough for both tools, and means the token can do nothing else even if it leaks.

You'll see the token once. It starts with brla_.

2. Point your client at it

Brila authenticates with a bearer token rather than an OAuth "Connect" button, so you paste the token into your client's config.

Claude Code

claude mcp add --transport http brila https://mcp.brila.me \
  --header "Authorization: Bearer brla_your_token_here"

Claude Desktop, Cursor, and most other clients take a JSON config:

{
  "mcpServers": {
    "brila": {
      "type": "http",
      "url": "https://mcp.brila.me",
      "headers": {
        "Authorization": "Bearer brla_your_token_here"
      }
    }
  }
}

Restart the client and ask it something like "what discount codes do I have live on Brila?"

Discovery

If you are building a client or a registry rather than configuring one, you do not have to be told the URL. Brila publishes three documents:

Document	Standard	What it gives you
https://mcp.brila.me/server-card	SEP-2127	The server's name, version, transport and the protocol revisions it speaks
https://brila.me/.well-known/ai-catalog.json	AI Catalog 1.0	An entry pointing at that card, so the domain alone is enough to find it
https://brila.me/.well-known/api-catalog	RFC 9727	A linkset pointing at the OpenAPI document and these docs

The server card needs no authentication — you read it to find out how to authenticate — and it is served with Access-Control-Allow-Origin: *, so a browser-based client can fetch it directly.

It deliberately carries no tool list. What tools/list returns depends on the scopes of the token you present, so a static document could only be wrong for most callers. Connect and ask the server.

Reading the results

Each code comes back with a single status rather than a set of flags:

status	Meaning
usable	Works right now
expired	Past its end date
scheduled	Starts in the future

Both tools default to usable only. That's deliberate: the most expensive mistake either tool could make is confidently handing someone a dead code, so you have to ask for the others explicitly — "including expired ones", or status: "all".

When codes are filtered out, the response says so:

{
  "codes": [{ "code": "LIVE10", "status": "usable", "...": "..." }],
  "returned": 1,
  "hidden": { "expired": 12, "scheduled": 1 }
}

That hidden block is what lets an assistant tell "you have no expired codes" apart from "you didn't ask about expired codes". Without it, a filtered list reads as a complete one.

Limits

MCP calls count against the same quotas as the REST API — see Rate limits. They're billed against your read burst budget, since every tool here is a read.

The quota counts requests, not just tool calls. Connecting spends a few on its own (the client asks what the server is and what tools it has), and it spends them again each time it reconnects — so restarting your AI client several times in a day costs you calls without any tool having run.

Some fields you'll find in the REST responses (icon, image_url, country) aren't in the tool results. They're presentation details an assistant can't act on, and every field costs context on every call.

Troubleshooting

"Missing the discount_codes:read scope" — the token was created without it. Scopes can't be added to an existing token; create a new one with the scopes you need and swap it in.

401 from the server — the token is wrong, revoked, or expired. Check it still appears under Settings → API Tokens.

"This Brila account has no profile yet" — list_discount_codes reads the codes on your profile, so you need to finish setup first. Saved codes work without a profile.

A note on OAuth

The MCP specification expects public, user-facing servers to support OAuth 2.1, which would replace the token paste with a "Connect Brila" button and let Brila appear in client directories. That's planned, not shipped. Bearer tokens work today in every client that lets you set a header.