You are testing a RelayLink integration while the live connection remains available in the same assistant. Both servers expose familiar operations, both know some of the same names, and one careless draft could target a real person instead of test data.
For integration developers, release testers, and operators, the safe setup is two explicitly named MCP connections plus a habit of checking identity before addressing a package.
Each host has its own handle
Every RelayLink host has an Mcp:Handle configuration value. That handle becomes the server name presented to the client and the long @handle form taught to the assistant.
RelayLink's production host uses relaylink and its sandbox uses relaylink-sandbox. Those names are deployment configuration, not values guaranteed by MCP itself. Another RelayLink deployment may use different handles.
A handle helps the assistant select a server; it is not an authentication or data-isolation mechanism. The endpoint and credential still decide which host and account receive the call.
Configure both /mcp endpoints as separate connections in your assistant. Give the connections labels that include the environment. Do not point two labels at one endpoint and assume the label changes where calls go.
Each connection also needs its own authentication. An OAuth token belongs to the host and account that issued it. If you use keys, create a distinct named key on each host and keep it only with the matching endpoint. Do not reuse a service key and rely on the handle to separate environments.
Ask whoami before a test
whoami answers two questions together: which account the credential represents, and which RelayLink server handle answered. If the selected connection cannot authenticate, fix that first; a handle cannot make an invalid production credential valid on sandbox.
Use it after connecting, after replacing a credential, and before any test that could deliver. A useful preflight is:
- Select the connection you intend to test.
- Call
whoami. - Check both the account address and server handle.
- Run
list_contactsand check the intended test contact on that host. - Draft only after those values match your test plan.
This catches a mislabeled connector, an unexpected account on a valid connection, or a production connection left selected from the previous turn.
Who you are connected as explains the identity response and display-name behavior.
Long handles and short aliases
RelayLink can teach a shorter alias alongside the configured handle. When no explicit alias is set, the standard derivation shortens relaylink to rl.
That means a host configured as relaylink commonly teaches @rl, while one configured as relaylink-sandbox commonly teaches @rl-sandbox. If a handle does not contain relaylink, there may be no derived short form. The host's reference page is the authority for the names it actually uses.
Prefer the long form while testing configuration. It makes the target visible in the prompt:
@relaylink-sandbox Priya ...for a test draft@relaylink Priya ...for a live draft
The shorthand opens a draft. It does not confirm a send. You still review the preview and approve delivery separately, whichever handle you used.
Keep test recipients on the test host
Distinct handles reduce ambiguity, but they do not replace test data discipline. Use accounts and email addresses intended for the sandbox. Check the displayed recipient address in the preview rather than trusting a familiar first name.
Contacts, threads, and inboxes belong to the host where they were created. A test contact on one host does not establish a relationship on the other. If the same email exists in both places, the handle and whoami result are what distinguish the environment.
Do not reuse one key value across environments. Separate named keys make the endpoint pairing visible and let you revoke one connection without disturbing the other.
Client architecture matters
An MCP client that flattens several servers into one tool list should namespace operations by a stable server identifier. Bare operation names can collide. Preserve a map from the client-visible name back to the correct server and keep that mapping stable for the session.
Connecting an agent framework to MCP covers that dispatch layer. The human-facing handle and the client's internal namespace solve related but different problems: one guides the assistant's intent, while the other routes the call.
Where this setup fits
Two hosts in one assistant are useful for connector development, approval-flow testing, and rehearsing correspondence with non-live data. Distinct handles reduce selection mistakes; they do not provide cryptographic separation or replace isolated credentials and test data.
Use distinct endpoints, handles, aliases, credentials, and test addresses. Then let the draft-and-confirm boundary do its job: a mistaken target should be visible while the package is still a preview.