MCP or REST API: which should you use for brand context?

Start with the caller

MCP (Model Context Protocol) lets AI assistants discover and use a service’s tools; a REST API gives your code endpoints to call. For brand context, ask who makes the call and who decides which call to make.

A chat-app user can’t call REST without someone writing code, and a coding agent calling it from a shell needs an API key in its environment; over MCP, each person signs in. A scheduled job has no model to make choices, so MCP’s run-time discovery adds nothing for it. An agent you build is covered below.

What MCP and REST are

The MCP spec calls tools “model-controlled”: a client fetches them with tools/list, the model decides which to call, and host apps should let a person deny a call.

The 2026-07-28 revision removed protocol-level sessions: each request carries its own version, and multi-call work is tracked by IDs in tool arguments, as in REST. Clients still support earlier, stateful servers; the AI SDK’s MCP client can reattach to a saved session.

What brand context asks of either

Whichever interface you use, the model has to see logos, references and type specimens; each task needs its own share of the brand, which takes work to choose; and an assistant and a pipeline reading different copies drift at the first brand change, so keep one brand behind both.

Rainbrand serves both callers from the same brand, through an MCP server and a REST API with matching operations: create_brief and get_brief over MCP, POST /briefs and GET /briefs/{id} over REST. Both return a Brief, the guidance and files selected for one task.

• Over MCP, a Brief’s images come back after the JSON when they fit the size limit; REST returns asset URLs. Font files are links either way, and Best MCP servers for brand guidelines shows both kinds of entry.
• You can add a brand through the API and give your agents MCP access to it, on the same account credits.

Discovery and control

With MCP, the client learns the tools at run time, so a new server tool reaches connected agents without a client change. The cost is that the model decides whether to request brand context and fills in the arguments, so two runs of one prompt can differ, and every tool definition takes context.

Hosted model APIs let you narrow the list, with OpenAI’s allowed_tools and the allowlists in Anthropic’s MCP connector. The spec also says to treat tool annotations, such as a read-only hint, as untrusted unless the server is trusted.

Rainbrand publishes an OpenAPI specification for generating a typed client, and lists its MCP tools.

Sign-in and customer access

A remote MCP server that uses authorization should follow the spec’s OAuth 2.1 profile: the client signs in through a browser with PKCE and gets a token for that server alone, and never sends it tokens from elsewhere. A local server reads credentials from the environment. A person signs in once, and the agent sees the brands they can access.

Rainbrand’s REST API takes two kinds of credential:

• An API key for server-side requests for your own account. Keep it in your environment or secret manager, and rotate it if it’s exposed.
• An OAuth access token, using Authorization Code with PKCE, when people connect their own Rainbrand accounts to your product.

Rainbrand’s MCP server also accepts an API key from clients that set a header, for an agent on your server with nobody to sign in. A key acts as the account that created it, so an agent using one can reach every brand that account can, including its teams’ brands. If one agent serves many customers, don’t let the model choose the brand: wrap REST endpoints as your own tools, set the brand from the signed-in customer and check on your server that they may use it (managing your customers’ brands covers the mapping).

Key requests count toward the same limits over both interfaces; keep keys out of prompts and project files, as the troubleshooting guide advises.

Jobs that take a while

Adding a brand, preparing a Brief or reviewing work can outlast a request; the MCP Tasks documentation notes many clients and network intermediaries time out first. MCP’s own answer is Tasks: the server returns an ID at once and the client checks back. In 2026-07-28 Tasks became an official extension that both sides must opt into, and host support varies.

The pattern that works everywhere is REST’s: one call starts the job and returns an ID, another reads its status. In Rainbrand, get_brief with wait holds the read until the Brief completes, fails or times out; over REST, Get a Brief with wait=true does the same. Three habits keep it safe:

1. Retry the read, not the start (create_brief or POST /briefs). A wait can time out while the work continues, and starting again can create a duplicate.
2. Send an idempotency key when you request a Brief, over REST or MCP, so a retry after a network error doesn’t start a second Brief; reuse it only with the same request. A failed Brief’s error says whether a new attempt may succeed; a new attempt needs a new key.
3. Store the ID with whatever you’re making, so a crashed job can pick up where it stopped.

Repeatability and logs

In a chat app, the record of which tools ran lives in the conversation, which is thin for an audit. With REST you write the logs, including each failure’s error.code and rate-limit retry timing.

Running the MCP client yourself closes most of the gap. The 2026-07-28 spec reserves traceparent, tracestate and baggage for OpenTelemetry, so a client and server that both support it can put tool calls in your traces. Its tools section also recommends logging tool usage.

For brand work, also keep track of the brand itself:

• A Rainbrand Brief records the Brand Skill version it was prepared from (skillId over REST, skill_id over MCP), so you can tell whether an image came before or after a palette change.
• For a reproducible run, reuse one completed Brief across closely related work, or record the ID of a Brand Skill, a copy of the whole brand that won’t change under you.
• Brief asset URLs open for anyone with the link, so keep logs that contain them private.

The interfaces also change differently: REST breaking changes come per endpoint with deprecation headers, while an MCP tool list can change between runs, which can surprise code that hard-codes tool arguments.

If you’re building the agent

An agent you build can reach brand context in three ways, from most freedom for the model to least:

Connect it to the MCP server

The agent decides when to request context. The AI SDK’s MCP client can load only the tools you name.

Wrap a few REST endpoints as your own tools

You write the descriptions and choose which arguments the model controls, so code can set the Brand ID from the signed-in customer.

Fetch brand context before the agent runs

Your code requests a Brief and puts its guidance and files in the agent’s context, so the model can’t skip the step. This suits a fixed job.

You can mix them: fetch a Brief up front and give the agent a tool for follow-ups. How agents retrieve brand context at runtime covers when to fetch and what to cache. If you haven't settled on an interface, ask your coding agent:

Here’s how our product or agent uses brand context today: [who calls it, from where, and for which customers]. Using Rainbrand’s MCP and REST API docs, tell me which interface fits, what we’d have to build for each, and what could break.

Check the property you chose the interface for

Test the property each route was chosen for before you rely on it:

• If code must guarantee brand retrieval, make the Brief fail in a test run and confirm the producing step stops.
• If the agent chooses its own tools, give it a few varied tasks and read the tool log: did it request a Brief, for the right brand, before making anything?
• If one agent serves many customers, sign in as one customer and confirm no request can reach another customer’s Brand ID.

To start, sign up and follow the MCP quickstart or the setup page for Claude, ChatGPT, Codex or Cursor for assistants, or the API quickstart for code.