An MCP endpoint so your assistant can run the program

RelayWonder now has an MCP endpoint at /api/mcp. A brand creates an API key with one or more scopes (read, campaigns, invite), hands it to Claude, ChatGPT or any client that speaks the Model Context Protocol, and the assistant can read program terms, search partners, publish campaigns, read the ledger and invite partners on the brand's behalf. Approving payouts, changing bank details, adding team members and rotating keys are not tools and never will be; those stay in the console with a signed-in human. Every call is logged with the key, the tool, the arguments and the result, and the brand sees the log on the agents page. This post explains what shipped, why the boundary sits where it does, how to set it up, and what it means for a program to be readable by machines.

What the MCP endpoint exposes

The Model Context Protocol is an open standard for connecting assistants to tools and data [1]. A server publishes a list of tools with names, descriptions and JSON schemas for their inputs; a client asks the model which tool to call and with what arguments; the server runs it and returns a result [2]. We implemented the server side over the same data layer the brand console uses, so there is no second copy of anything and no "API-only" behaviour that differs from what a person sees.

Scoped API keys

A key is created in the brand console under Agents. You give it a name, tick the scopes it should have, and copy the key once; after that the console shows only a prefix. The three scopes are additive and narrow by design.

• read: every get, search and list tool. A key with only this scope cannot change anything, which makes it safe to hand to an assistant that is drafting a weekly report.
• campaigns: publish and update content campaigns. Needs read as well, since a campaign tool without the ability to read program terms is useless.
• invite: send invitations to network partners. This is the scope that touches people rather than data, so it is separate; an assistant that is allowed to plan campaigns is not automatically allowed to email partners about them.

A key can be paused or revoked at any moment from the console, and revoking is immediate: the next call fails with an authentication error and nothing in flight completes. Keys do not expire on their own, because an expiry you forgot about is a Monday-morning outage, but the agents page shows the last-used time for each key so an unused one is easy to spot and remove. The pattern is deliberately close to how Stripe handles restricted API keys, which most of our brands already know [3].

What is not a tool, and why

The boundary is not about trust in any particular model. It is about which actions can be undone. Everything exposed through the MCP endpoint is either read-only or reversible by a person in the console within a minute: a campaign can be closed, an invitation can be withdrawn before the partner accepts. The four actions that are excluded share one property: once they happen, somebody has moved money or changed who controls the account.

• Approving a payout batch. Marking a batch paid writes paid rows to the ledger and tells partners the money is on its way. The only correct way to undo that is to have actually paid, so it stays human.
• Changing bank or payout details. Those are the partner's own details, entered by the partner in their portal. No brand user can change them in the console either, and no key can.
• Adding, removing or re-roling team members. Changing who can act on the account is the one thing an automated actor must never be able to do, because it is how a compromised key would make itself permanent.
• Creating, rotating or revoking API keys. Same reason. A key cannot mint another key.

We also do not expose fraud-flag clearing. The self-referral, click-burst and same-user-agent checks hold a payout line until a person reviews it, and we want that person to be a person. An assistant can read the flags and summarise them for you; it cannot clear them.

Setting it up with a client

The endpoint speaks MCP over HTTP, so any client that supports remote servers works. The steps for a typical desktop assistant are:

1. In the brand console, open Agents, click New key, name it (for example "Weekly report assistant"), tick read, and copy the key.
2. In your MCP client's configuration, add a server entry pointing at https://app.relaywonder.com/api/mcp with an Authorization header carrying the key as a bearer token. The client documentation for your assistant shows where this file lives [1].
3. Restart or reload the client. It will call the endpoint's tool-listing method and show the tools the key is allowed to use. A read-only key lists five tools; a key with all three scopes lists eight.
4. Ask something concrete: "Which partners in my design program have conversions in the last 90 days, and what is each one's payable balance?" The assistant calls search_partners, get_partner_summary and read_ledger and answers from the results.
5. Open the agents page in the console. Each call is there with its timestamp, tool, arguments and a result summary, under the key that made it.

A worked session

Here is what a Monday morning looks like for a brand running a 25% recurring program with the endpoint connected to an assistant holding a key with all three scopes. The prompts are the brand's; the actions are what the log shows.

1. Prompt: "Summarise last week." The assistant calls read_ledger for the last seven days: 14 positive rows totalling $612.50, 1 negative row of -$24.00 for a refund, 2 rows flagged for review. It reports the totals and names the two flagged partners without clearing anything.
2. Prompt: "Which open campaigns have fewer applicants than their cap?" The assistant calls get_program_terms to list campaigns and finds one with a cap of 3 and one applicant. It reports the brief and the bounty.
3. Prompt: "Find three creators who make YouTube reviews for design tools and have converted in the last 90 days, and invite them to that campaign." The assistant calls search_partners with type creator, format youtube, results in the last 90 days; gets a ranked list; calls get_partner_summary on the top three; calls invite_partner three times. Three invitations are sent, three log lines are written, and the partners see an invitation in their portal.
4. Prompt: "Open the September payout batch and tell me what we owe." The assistant calls list_open_payout_batches: 9 partners above the $50 minimum, $1,384.00 in USD and 210.00 in EUR, 1 line held by a flag. It reports the numbers and says that marking the batch paid has to be done in the console.

Twelve tool calls, perhaps six minutes, and nothing happened that the brand could not see and reverse. The payout was not approved, the flag was not cleared, and the invitations can be withdrawn before anyone accepts. That is the whole design in one session.

The activity log

Every call through the MCP endpoint produces one log row: timestamp, key, tool name, arguments as the model sent them, outcome (ok, denied, error) and a short result summary. Denied calls are logged too, which is how you find out that an assistant tried to use a tool its key does not allow. The log is append-only like the ledger and is kept for the life of the account. Rows can be filtered by key and exported as CSV for anyone who needs to audit what automation did on the account in a given month.

Why being readable by machines matters

The useful part of this release is not that a brand can automate its own Monday morning, though it can. It is the other direction. Terms that an agent can read are terms that a creator's agent can compare. When a partner asks their assistant "which design-tool affiliate programs pay recurring commission with at least a 60-day cookie and a hold under 45 days", the programs whose terms are structured and reachable are the ones that make the list. A program described only in a PDF on a landing page is invisible to that question. Being comparable is how a small program gets found, and the public program page plus the get_program_terms tool make RelayWonder programs comparable by default [4].

This is also why we chose an open protocol over a proprietary API. A proprietary API has to be integrated by each client; an MCP server is reachable by any client that already speaks the protocol, including ones that do not exist yet. The cost to us was writing eight tool definitions over data we already had.

Limits and what is next

• The endpoint is brand-side only today. Partners cannot yet give an assistant a key to their own portal. That is on the list, with the same read-only-first rule.
• Rate limits are per key and generous for assistant use, but a loop that calls read_ledger every second will be throttled, and the log will show it.
• search_partners returns profiles and aggregate results, not email addresses. Contact happens through invite_partner so that the partner controls it.
• There is no tool for Hunter open-web search, because that feature is not live. When it is, it will be a read-scope tool.