---
title: "MCP or REST API: which should you use for brand context? | Rainbrand"
description: "Choose by who makes the call. People working in Claude, ChatGPT or Cursor should use MCP, your backend and pipelines want REST, and an agent you build can use either. Here’s how discovery, sign-in and customer access, long jobs, repeatability and logs differ under the current MCP spec."
url: "https://www.rainbrand.com/blog/mcp-vs-rest-api-for-brand-context/"
---

By [Tomas Ward](https://www.linkedin.com/in/tomasward1/)

Published 28 Oct 2026

12 min read

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

Choose by who makes the call. People working in Claude, ChatGPT or Cursor should use MCP, your backend and pipelines want REST, and an agent you build can use either. Here’s how discovery, sign-in and customer access, long jobs, repeatability and logs differ under the current MCP spec.

## TL;DR

Choose by who controls the call. People working in Claude, ChatGPT, Codex or Cursor should use MCP, which lets their agent discover brand tools and request context during its work. Backends and pipelines should use REST, which lets your code fix the order, handle long jobs and keep its own logs. An agent you build can use either or both; when it serves many customers, have your code choose the brand rather than the model. Keep one maintained brand behind both interfaces, so a chat assistant and an API job never work from different copies.

## Start with the caller

MCP (Model Context Protocol) lets AI assistants discover and use tools from a connected service. A REST API gives your code HTTP endpoints to call directly. Most “MCP vs API” explainers compare the two protocols. For brand context, the more useful questions are who is making the call and who decides which call to make. The same brand often needs both: a marketing team’s assistant and a product’s rendering job can draw on it on the same day.

| Caller | Who picks each call | Use |
| --- | --- | --- |
| A person in Claude, ChatGPT, Codex or Cursor | The model, with the person watching | MCP |
| Your backend, job or pipeline | Your code | REST API |
| An agent you build | Whichever you choose | Either, often both |

A person in a chat app can’t call a REST endpoint unless someone writes code for them, so MCP is their practical route. A coding agent such as Codex or Cursor could call the API from a shell, but it would need an API key in its environment; over MCP, each person signs in instead. A scheduled job has no model deciding anything, so MCP’s run-time discovery would be a layer it never uses. The agent you build yourself is the case that takes thought, and it has its own section below.

## What MCP and REST are

The [Model Context Protocol](https://modelcontextprotocol.io/specification/2026-07-28/basic/index) is an open standard for connecting AI applications to outside systems. A server publishes tools. The client, such as Claude, ChatGPT, Cursor or your own agent, fetches them with `tools/list` and gets each tool’s name, description and a JSON Schema for its inputs, and optionally its outputs. The [spec calls tools “model-controlled”](https://modelcontextprotocol.io/specification/2026-07-28/server/tools): the model decides which to call, and host apps should show when tools run and let a person deny a call.

A REST API is a set of HTTP endpoints, usually described in an OpenAPI file. Your code calls them in the order you wrote. An agent reaches one only through code: your application, a tool that wraps specific endpoints, or requests a coding agent writes and runs itself.

[MCP spec](https://modelcontextprotocol.io/specification/2026-07-28/changelog)

“Key Changes”, MCP specification 2026-07-28.

Several popular explainers describe MCP as a stateful session. That describes earlier versions, which clients still support: the [AI SDK’s MCP client](https://ai-sdk.dev/docs/ai-sdk-core/mcp-tools), for one, can reattach to a saved session on a server that uses them. The [current revision, 2026-07-28](https://modelcontextprotocol.io/docs/learn/versioning), removed the opening handshake and protocol-level sessions: each request carries its own version and capabilities, and work that spans calls is tracked by IDs passed as ordinary tool arguments. That’s how a REST client tracks a job too. An MCP server is also often a layer over the same API, so the choice is less exclusive than it sounds.

| | MCP | REST API |
| --- | --- | --- |
| Discovery | At run time, from `tools/list` | At build time, from docs and OpenAPI |
| Who decides | The model | Your code |
| Sign-in | OAuth, run by the host app | An API key, or OAuth you build |
| Long jobs | Start and check tools, or Tasks | Job IDs and polling you write |
| Logs | In the host app, or your own client | Yours |
| Images | Can come back in the result | URLs your code passes on |

## What brand context asks of either

Three things about brand context matter more than the protocol.

The model has to see it

Logos, reference images and type specimens do more work than descriptions of them. MCP tool results can include images directly; a REST response gives URLs that your code downloads or passes to the model.

It’s sized to the task

A launch email needs voice rules and product terms. A banner needs the palette, logo files and reference images. Choosing those takes work on the server, so task-specific guidance is often a job you start and then check, rather than an instant lookup.

It changes

If the marketing team’s assistant reads one copy and the product pipeline reads a Markdown file in the repo, they drift the first time the brand changes. Choose the interface per caller, but keep one brand behind both.

[MCP tools](https://docs.rainbrand.com/mcp/tools)

Tools, Rainbrand docs.

Rainbrand maintains brands for agents and products, and serves both kinds of caller from the same brand. It’s reachable through an [MCP server](https://docs.rainbrand.com/mcp/getting-started) for the agents people already use and a [REST API](https://docs.rainbrand.com/api/quickstart) for code, with matching operations: an agent calls `create_brief` and `get_brief`, and a pipeline calls `POST /briefs` and `GET /briefs/{id}`. Both return a [Brief](https://docs.rainbrand.com/guides/request-brief), the guidance and files selected for one task. Over MCP, the Brief’s images come back after the JSON when they fit the size limit, so the agent gets the pictures as well as links. Over REST you get asset URLs. You can [add a brand through the API and give your agents MCP access to the same brand](https://docs.rainbrand.com/getting-started/embed-into-your-product), and both interfaces draw on the [same account credits](https://docs.rainbrand.com/api/usage-limits).

A saved record from one of our demonstrations shows the first two points. We connected Claude to Rainbrand over MCP and asked it to invent a new flavour for Eager, a juice brand, and make the launch campaign. Claude asked for a single Brief covering the whole campaign, which completed about 100 seconds after the request: a job to start and check, not an instant lookup. Its wordmarks, carton photos and font specimens came back as images Claude could see. The font files came back as links, marked as not supported for inline delivery, so whatever sets the type still has to download them. [Which MCP servers provide brand guidelines and assets](https://www.rainbrand.com/blog/mcp-servers-for-brand-guidelines/) shows those entries from the record. It’s one Brief, not a benchmark of either interface.

## Discovery and control

MCP’s main advantage is that the client learns the tools at run time. Add a tool to the server and connected agents see it the next time they list tools, with no change to client code. For a person in a chat app that’s the point: they connect once and ask in plain words.

The cost is that the model chooses. It reads tool descriptions, decides whether to request brand context at all and fills in the arguments, so two runs of the same prompt can take different paths. Tool definitions also take up the model’s context, and every extra tool is one more to choose between. Hosted model APIs let you narrow the list: OpenAI’s [Responses API](https://developers.openai.com/api/docs/guides/tools-connectors-mcp) has an `allowed_tools` setting, and Anthropic’s [MCP connector](https://platform.claude.com/docs/en/agents-and-tools/mcp-connector) supports allowlists and denylists. The spec also tells clients to treat tool annotations, such as a read-only hint, as untrusted unless the server is trusted.

REST discovery happens once, when a developer or a coding agent reads the docs and writes the integration. After that the calls don’t change unless you change them, which is what a pipeline wants. Rainbrand publishes an [OpenAPI specification](https://docs.rainbrand.com/api/openapi) for generating a typed client or handing to a coding agent, and lists its [MCP tools](https://docs.rainbrand.com/mcp/tools) with the guide behind each.

## Sign-in and customer access

Authorization is optional in MCP, but a remote server that uses it should follow the [spec’s OAuth 2.1 profile](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization). The server publishes metadata pointing clients to its authorization server, the client runs a browser sign-in with PKCE, and the token is issued for that one server. Clients must not send it tokens from anywhere else. Servers that run as a local process should read credentials from the environment instead.

For a person, that means adding the server in their app and signing in once. The token belongs to them, so the agent sees the brands and teams they can access, and nobody pastes a secret into a chat.

[Authentication](https://docs.rainbrand.com/api/authentication)

Authentication, Rainbrand docs.

REST leaves the choice to you. Rainbrand’s API takes [two kinds of credential](https://docs.rainbrand.com/api/authentication):

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

The split isn’t strict. Rainbrand’s MCP server also accepts an API key from clients that let you set a header, which suits an agent running on your server with nobody there to sign in. A key acts as the account that created it, so an agent connected with one can list and use every brand that account can reach, including its teams’ brands. If your agent works for many customers, don’t leave the choice of brand to the model. Wrap a few REST endpoints as your own tools, as , so your code sets the brand from the signed-in customer, and check on your server that this customer may use it; [managing your customers’ brands](https://www.rainbrand.com/blog/manage-customer-brands-in-an-ai-product/) covers that mapping. API-key requests [count toward the same limits](https://docs.rainbrand.com/api/usage-limits) over REST and MCP. Either way, keep keys out of prompts and project files, as Rainbrand’s [troubleshooting guide](https://docs.rainbrand.com/mcp/troubleshooting) advises.

## Jobs that take a while

Adding a brand from its website, preparing a Brief, generating an image or reviewing one can all outlast a single request; the Eager Brief above took about 100 seconds. Holding the connection open until the work finishes is fragile: the [MCP Tasks documentation](https://modelcontextprotocol.io/extensions/tasks/overview) points out that many clients and network intermediaries time out long before slow work is done.

MCP’s own answer is Tasks: the server returns a handle, and the client polls until the work completes. In the 2026-07-28 revision, Tasks moved out of the core protocol into an [official extension](https://modelcontextprotocol.io/docs/extensions/overview) that client and server must both opt into, and host support varies. A server built for today’s chat apps can’t assume every host has it.

The pattern that works everywhere is the one REST APIs already use: one call starts the job and returns an ID, and another reads its status. Rainbrand uses it in both interfaces. `create_brief` returns a Brief ID, and `get_brief` with `wait` holds the read until the Brief completes, fails or reaches a timeout. Over REST, `POST /briefs` and a [Get a Brief](https://docs.rainbrand.com/api-reference/briefs/get-a-brief) read with `wait=true` do the same. Three habits keep it safe:

1. Retry the read, not the start. A wait can time out while the work continues, and [starting again can create a duplicate](https://docs.rainbrand.com/mcp/troubleshooting).
2. Send an idempotency key when you start the job, so a retry after a network error doesn’t create a second one. Rainbrand accepts one when you [request a Brief](https://docs.rainbrand.com/api-reference/briefs/request-a-brief), over REST or MCP; reuse a key only with the same request. If a Brief fails, its error says whether a new attempt may succeed, and 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

When MCP runs inside someone’s chat app, the record of what happened lives in that conversation: which tools ran, with which arguments, and what came back. That’s enough for one person’s work and thin for an audit. With REST, you write the logs: requests, timings, the `error.code` behind each [failure](https://docs.rainbrand.com/api/errors), and the retry timing a rate limit returns.

Running the MCP client yourself closes most of that gap. The [2026-07-28 spec](https://modelcontextprotocol.io/specification/2026-07-28/basic/index) reserves `traceparent`, `tracestate` and `baggage` in request metadata for OpenTelemetry trace context, so a client and server that both support it can put tool calls in the same traces as the rest of your services. The [tools section](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) also recommends that clients log tool usage for audit.

For brand work, record which version of the brand produced each output, as well as which call ran. 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 was made before or after the palette changed. When a run must be reproducible, reuse one completed Brief across closely related work instead of requesting a new one each time, or retrieve the [Brand Skill](https://docs.rainbrand.com/guides/use-brand-skill), an immutable snapshot of the whole brand, and record its ID with the run. Brief asset URLs open for anyone who has the link, without signing in, so keep logs and transcripts that contain them as private as the files themselves.

Contracts change differently too. Rainbrand handles REST breaking changes per endpoint, with [deprecation headers and migration guidance](https://docs.rainbrand.com/api/versioning). An MCP tool list can change between runs, which suits an agent that reads it fresh and 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 sees the tools and decides when to request brand context. The [AI SDK’s MCP client](https://ai-sdk.dev/docs/ai-sdk-core/mcp-tools) connects to a remote server with a header or an OAuth provider and can load only the tools you name. OpenAI’s Responses API, and Anthropic’s Messages API through its MCP connector (in beta), can call a remote server’s tools from inside a request. This suits open-ended assistants.

Wrap a few REST endpoints as your own tools

You write the descriptions and choose which arguments the model controls. A product agent that serves many customers can set the Brand ID in code from the signed-in customer’s account, so the model never chooses which brand to use.

Fetch brand context before the agent runs

Your code requests a Brief for the task, waits for it and puts the guidance and files into the agent’s context. The model can’t skip the step, and if you reuse one Brief, runs for the same task start from the same input. This suits a fixed job, such as drafting one kind of email.

You can mix them: fetch a Brief up front for the main task and give the agent a tool for follow-ups. [How agents retrieve brand context at runtime](https://www.rainbrand.com/blog/how-agents-retrieve-brand-context-at-runtime/) covers when to fetch and what to cache.

## Check the property you chose the interface for

Each route was chosen for a property, so test that property 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 rather than making work without brand context.
- **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 brand you meant, before making anything?
- **If one agent serves many customers,** sign in as one customer and confirm that no request can reach another customer’s Brand ID.

Record the Brief ID and brand version with each output either way, so you can tell later which guidance produced it. To start, follow the [MCP quickstart](https://docs.rainbrand.com/mcp/getting-started) for assistants or the [API quickstart](https://docs.rainbrand.com/api/quickstart) for code.

## More in Developers

[All 5 Developers articles](https://www.rainbrand.com/blog/topics/developers/)

- 28 Oct 2026 13 min read

    ### [Which APIs provide brand assets and guidelines?](https://www.rainbrand.com/blog/brand-apis-for-ai-agents/)

    Brand APIs return different things. Lookups describe any company’s public identity, platform APIs read the files a customer already stores, and a maintained brand returns guidance and files for each task. Compare what each returns, who keeps it current, how access works and how pricing differs.

- 28 Oct 2026 10 min read

    ### [How to add brand context to your AI product](https://www.rainbrand.com/blog/embed-brand-context-in-your-ai-product/)

    Follow a generation job from the customer’s task and authorized brand through guidance, assets, rendering and review. Keep future jobs current with saved brand versions and applied corrections.

- 28 Oct 2026 9 min read

    ### [How do agents retrieve brand context at runtime?](https://www.rainbrand.com/blog/how-agents-retrieve-brand-context-at-runtime/)

    Retrieve task-specific brand guidance and files, pass them to the tools making the work, and record the version used. Implement deliberate reuse and a visible failure path.

One brand, every agent.

[Connect your agents](https://docs.rainbrand.com/mcp/getting-started)