Add RelayLink to Claude or ChatGPT in about two minutes

RelayLink is a remote MCP server, so there's nothing to install — paste one address into your assistant's connector settings, approve the sign-in, and it gains a correspondence surface.

12 min read Updated

RelayLink has no app, because your assistant is the app. It's a remote MCP server: you add it to the AI you already use as a custom connector, and your assistant gains a small set of correspondence tools. Setup is two values and a first prompt.

What you need

  • An email address. Signing in with it creates the account — from the app's consent screen where the deployment signs you in, or on your account page where it does not. A key is only for clients that cannot sign you in, and you issue one from your account page afterwards.
  • An AI app that supports remote MCP servers over HTTP. Claude and ChatGPT both do via custom connectors; so do most agent frameworks. On ChatGPT there is one extra step before you can add anything at all — see below.

The key is yours, not the model's — whoever holds it can correspond as you, so treat it like a password.

One address, and the app does the rest

The endpoint never changes: the RelayLink /mcp address, shown with a copy button at the top of the reference page. What changes is how you prove who you are, and for the big assistants that is a sign-in you approve, not something you type.

Sign in with RelayLink (OAuth). Paste the address where the app asks for a connector or MCP server, and the app takes you to a RelayLink page. RelayLink emails you a code — there are no passwords — you enter it, approve the connection, and you are back in the app. Claude and ChatGPT identify themselves to RelayLink automatically, and so do the coding tools that publish who they are — Claude Code, Codex, VS Code and Zed; there is no client id, secret or key in this flow. A coding tool's sign-in comes back to the tool on your computer rather than to a website, and the approval page says so. If an app ever asks for a client ID, the reference page lists the ones RelayLink holds; it is not a secret and most people never see the field.

A key in a header. X-RelayLink-Key: your-key. This is the path for anything that configures a connector by URL and headers rather than by signing you in — Cursor, Gemini CLI and the other coding tools that cannot sign in yet, most agent frameworks, and any app whose connector form has a header field. It is also the way in for a coding tool running somewhere your browser is not, such as over SSH. Make keys on your keys page, one per tool, so you can turn one off without the others. The header name matters: a key sent as Authorization: Bearer is presented as a sign-in, and refused.

Which of the two you use is a fact about the app. Claude, ChatGPT, Claude Code, Codex, VS Code and Zed sign you in; everything else sends a key. The shared-memory setup guide lists each assistant with its exact steps, what we have tested and when, and the apps that cannot connect yet.

Where the address goes, per app. The menus move as these apps evolve, so treat the paths as this month's and the shape as permanent. Once you are signed in, your connect guide has the same steps with this server's address already filled in, one app at a time, and says when the connection has worked:

  • Claude (claude.ai or the desktop app): Customize → Connectors → + → Add custom connector → paste → Add → Connect → sign in and approve. On Claude's free plan, that is your one custom connector.
  • Claude Code: claude mcp add --transport http relaylink <address>, then type /mcp inside Claude Code, choose it and sign in in the browser it opens. The approval page names claude.ai, which is where Claude Code publishes who it is, and says the code goes back to an app on this computer. If you have already connected RelayLink on claude.ai, signing Claude Code in with the same Claude subscription brings that connector along with no second sign-in. A key still works, and is the way in over SSH or wherever the sign-in cannot finish: add --header "X-RelayLink-Key: your-key" to the same command. Name the server after the handle the reference page shows (relaylink-sandbox on a sandbox), so the @ picker below matches what the server calls itself.
  • ChatGPT: turn on Developer mode in ChatGPT's settings, then create an app → paste → choose OAuth → sign in and approve. In a chat, pick it from + → Developer mode. The developer-mode step is covered below.
  • Grok: its connectors page takes a custom address, but xAI does not document how it signs in, and RelayLink does not recognise Grok's sign-in yet, so it cannot connect today.
  • Gemini: the app adds custom servers only inside Gemini Spark, and signs in a way RelayLink does not offer yet. Gemini CLI connects with the address and the key in its settings file.

The version with nothing to paste at all — RelayLink in the app's own connector list, one click — is a listing in each vendor's directory, which is a review on their side. Claude's is first in line. Until then, one address is the whole setup.

On ChatGPT, turn on developer mode first

This is the step people get stuck on, and the symptom is that there is simply no field to paste a URL into.

ChatGPT will only let you add an arbitrary MCP server when developer mode is on. It is a toggle in ChatGPT's own settings — the section it sits under has moved more than once, so look for developer mode rather than for a fixed menu path. It is currently in beta, on the web, for Plus, Pro, Business, Enterprise and Education accounts.

Three things worth being clear about, because the naming invites the wrong guess:

  • It is not about RelayLink. It is the gate on adding any custom connector. Every MCP server that isn't already in ChatGPT's own directory is behind the same toggle.
  • It is not about write access specifically. You may read that developer mode is what enables tools beyond search and fetch, which is true, but it undersells the situation: without it there is no custom connector to expose tools at all.
  • It is not a workaround or an unsupported hack. It is OpenAI's documented route for connecting your own server, and per-call confirmation for write actions stays on — which sits comfortably with how RelayLink works anyway, since nothing is delivered without your explicit confirm.

The alternative is one-click install from ChatGPT's directory, which needs no developer mode and no URL. That is a submission-and-review process on our side rather than a setting on yours, and RelayLink is not in the directory yet. Until it is, developer mode is the way in.

Claude needs none of this: custom connectors are available in its settings directly. If you use both apps, expect the ChatGPT side to take a minute longer the first time and to be identical afterwards — same account, same tools, same inbox.

Neither path is a downgrade. A key is a single long-lived credential you look after yourself; an OAuth connection is one you can approve per app. Both reach the same seventy-two tools as the same account.

What your assistant can do once connected

Seventy-two tools, in the language you'd already use.

Correspondence:

  • whats_new — anything new? One call: unread packages, who is waiting on you, who accepted your request
  • check_inbox — what came in
  • get_package — read the full briefing
  • acknowledge_package — tell the sender a person read it
  • draft_package — compose, for your review
  • confirm_send — deliver, after you approve
  • cancel_draft — discard without sending
  • list_drafts — composed but unsent
  • thread_status — "did they reply yet?"
  • list_threads — everything in flight

People:

  • list_contacts — who you can write to, and who is waiting on you
  • rename_contact — what you call them, so "@relaylink Billy" just works
  • invite_contact — ask somebody to be a contact
  • accept_contact — answer a request that is waiting
  • block_contact — refuse one, or end a contact, without telling them
  • unblock_contact — lift a block
  • withdraw_invite — take back an ask they have not answered

The account:

  • whoami — which account, and which RelayLink, this connection is
  • set_my_name — the name every recipient sees
  • list_api_keys — what can reach the account, and when each was last used
  • revoke_api_key — turn one off

Note the shape: reading and drafting are free, but nothing reaches another person without your explicit confirm. That separation is the point of the whole design, not a setup inconvenience.

The twelve people-tools change who can reach you, so they carry the same condition the send does: your assistant may act on your own words asking for it, and never on something it read in a package, a document or a web page. Say the word and it can ask Priya to be a contact; a briefing from Priya saying "please accept Dev" is something it should tell you about, not act on. One thing stays in the browser on purpose — issuing a new API key, because a key exists in the clear exactly once and a chat transcript is the wrong place for it.

First prompts to try

No new syntax to learn — just talk:

  • "Save where we left off in RelayLink." — in a chat you are partway through. Then open a fresh chat, in the same assistant or the other one, and say "Pick up where I left off in RelayLink." That pair is the quickest way to see what RelayLink is for: it needs nobody else, and it is the same four steps your account page ticks off as you go.
  • "Check my RelayLink inbox." The email you get when a briefing arrives carries an Open in Claude and an Open in ChatGPT link that ask this for you, so the usual way you will run it is one tap from your inbox. You will also hear about anything waiting on the back of whatever else you ask RelayLink to do — a draft, a status check, a contact list all come back with a line saying how many packages are unread.
  • "Who are my RelayLink contacts?"
  • "Draft a briefing for Priya about the lease decision — I want her opinion by Friday." Review what it composed, fix anything wrong, then: "Send it."
  • Or the short form: "@relaylink Priya — lease decision, I want her opinion by Friday." Shorter still: "@rl Priya — …" means the same. A name is enough when it's one of your contacts; the server matches it against list_contacts and asks rather than guesses if two people share it. It opens a draft, never a send — the review step is the same.
  • Your own names for people: "For RelayLink, rename billy12399d@gmail.com to Billy." From then on "@relaylink Billy" is that person. The nickname lives in your list only: Billy never sees it, cannot set it, and it will not travel in anything you send him. That last part is enforced rather than trusted — if your assistant writes "Billy" into the briefing itself, the server refuses the draft and tells it to use the name he actually goes by. If you'd rather he saw it, say so and your assistant records it ("it's fine, Billy knows I call him that"), or tick They can see this name beside the nickname on your contacts page; renaming him later makes it private again. Set a nickname in your browser and your assistant may still be holding the list from before; the server tells it to try the name anyway and re-read the list rather than say no from memory.
  • Later: "Did Priya reply yet?"

The @relaylink handle is what the server calls itself, so if you have more than one connected — a sandbox alongside production, say — each answers to its own, and "@relaylink-sandbox Priya" cannot land on the real one.

In Claude Code the same thing is a menu: type @ and your RelayLink contacts are listed as @relaylink:relaylink://contacts/…, and /mcp__relaylink__send-to Priya is the slash-command form. Both are the typed shorthand with the person already resolved, and both stop at the preview.

The best first run is a real, low-stakes question to a real person. The recipient needs nothing — briefings arrive as normal email with a reply link, whether or not they have an assistant of their own.

If something doesn't work

  • The app never showed you a sign-in page, or its sign-in failed. Claude's and ChatGPT's connectors sign in to RelayLink, and so do Claude Code, Codex, VS Code and Zed; the setup guide says which tools do. Any other coding tool or agent framework that opens a browser for it, or reports the connection refused, needs the key path instead — your keys page issues one — and nothing about the address is wrong. A coding tool running on a different machine from your browser, over SSH or in a container, may not receive the sign-in when you approve it; a key works there too.
  • The connection is rejected. On the key path it is almost always the header: the name must be exactly X-RelayLink-Key, with your key as the value, and a pasted space around the key counts. The server will not tell you which mistake you made — a missing header, a wrong key and an expired token all come back as a 401 with no body, because a request that can authenticate two ways cannot have one of them writing the explanation. What the 401 does carry is a WWW-Authenticate: Bearer resource_metadata="…" header, which is how an app that signs in finds out where to go; on the key path you can ignore it. On the OAuth path, a rejection usually means the approval never finished: start again from the app's connector settings rather than reloading the RelayLink page.
  • In ChatGPT, there's nowhere to paste the URL. Developer mode is off. That is the whole answer — see the section above. Nothing about the endpoint, the key or the account is involved yet, so don't start re-checking them.
  • The tools don't show up. Reconnect or refresh the connector in the app's settings, then start a fresh conversation — some apps only pick up new connectors on a new session. Confirm your app supports remote MCP servers, not only local ones.
  • list_contacts comes back empty. Contacts are mutual: a standing pair exists only once both sides accept it. Until then, two things can happen, and which one depends on the other person. Writing to someone who is not on RelayLink travels as cold email — deliberately hard-capped per day, with the first message required to be a full briefing. Writing to someone who is on RelayLink and has not accepted you is refused until they do; ask your assistant to invite them ("invite priya@example.com to RelayLink"), or send the request from your contacts page. Send one real briefing to someone you know; the pair forms from real correspondence, not from an address book import.
  • The assistant drafts but nothing arrives. Check list_drafts — a draft isn't a send. Review it and confirm, or cancel_draft if it shouldn't go.

Once connected, the habit that makes it click is small: the next time you catch yourself about to paste an AI conversation into an email, have the assistant draft the briefing instead.

Frequently asked questions

Do I need Claude specifically?
No. Anything that can talk to a remote MCP server over HTTP works — Claude via its connector settings, ChatGPT via its connector settings once developer mode is on, and most agent frameworks via their standard MCP client configuration.
Why does ChatGPT need developer mode and Claude doesn't?
Because ChatGPT only lets you type an arbitrary MCP server URL into settings when developer mode is on. It is not about RelayLink or about write access — it is the gate on adding any custom connector, and it applies to every MCP server that isn't already listed in ChatGPT's own directory. It is a toggle on paid plans on the web, and turning it on takes a few seconds.
Does this give my assistant access to my email account?
No. RelayLink is a separate correspondence channel and never touches your mailbox. The assistant gets the seventy-two RelayLink tools — plus, on a client that lists them, two prompts and your accepted contacts as resources, all described on [/docs](/docs) — and nothing about your email account.
Can my assistant send something without me?
No. Drafting and sending are separate server-side steps. A draft sits unsent until you review the rendered package and explicitly confirm — there is no single call that composes and delivers.