Publish your app as an MCP server

Agent integrations make a published RShift Sites app available to AI assistants. Users connect your app in ChatGPT, Claude, or another compatible assistant, then ask the assistant to read information, run workflows, create or update records, or apply your app’s logic.

People use your app by clicking buttons, filling out forms, and moving through screens. An AI assistant cannot click: it needs a list of actions it can call instead. That list is what an MCP server provides.

Model Context Protocol, or MCP, is an open standard that lets AI assistants discover and call an app’s actions, called tools. When a user asks their assistant for something your app handles, the assistant picks the matching tool, and your app does the work.

RShift Sites creates and hosts the MCP server for you, with proposed tools based on your app’s functionality, such as looking up an order, generating a quote, or pulling information from a knowledge base. For your users, connecting your app works like adding a plugin. The assistant gets access only to the tools you publish, not to your RShift Sites project.

How it works

Start setup by asking RShift Sites in chat to add agent integrations or by selecting Enable agent integrations under More → Agent integrations. You can set up the integration before publishing the app.

RShift Sites then:

1. Generates an MCP server for the app.
2. Proposes a set of tools based on what the app does.
3. Asks who should be able to call the tools: signed-in users or anyone.
4. Sets up authentication to match your answer.

The proposed tools are a starting point: you can ask RShift Sites to add, remove, rename, or change them at any time.

Before anything goes live, you review the tools and access setup, then publish your app. RShift Sites gives you an MCP link to share with your users. They add the link to their AI assistant as a custom connector, sign in if your app requires it, and start asking the assistant to use your app.

Your integration runs on your live published app, not a copy. Enabling it adds tool code and connection endpoints to your project, and nothing changes for the people using your app. RShift Sites hosts the MCP server and keeps it compatible as the standard evolves. You control which actions are exposed, who can call them, and when changes are published.

When you change the app or its tools, publish again. Users need to refresh their connector when you add, remove, or rename tools. Step-by-step instructions are in Set up your agent integration.

How this differs from RShift Sites’ other MCP features

RShift Sites uses MCP in three different ways, each connecting a different system for a different purpose. Agent integrations let AI assistants use the published app you built. They do not let an assistant edit the RShift Sites project itself. That is the RShift Sites MCP server, a separate feature.

These uses also combine: a published app with an agent integration becomes available as a chat connector inside its own workspace, so you and your teammates can use the app when you chat with RShift Sites. See Use your app in your chats.

Should you add an agent integration?

Why use it

• Reach users where they already work. Your users can work with your app from inside their AI assistant, without opening the app itself.
• Give your app a new experience without rebuilding it. The integration is generated from your existing published app, so assistants become another way to use the same features.
• Control access and monetization. You review every proposed tool before publishing and decide whether the integration requires sign-in or is available without sign-in. Your app keeps enforcing roles, plans, and its other access rules, so you can make assistant access a benefit of your paid plan.
• RShift Sites hosts and maintains the server. RShift Sites runs the MCP server and keeps it compatible as the standard evolves. The tools, access rules, and app behavior you publish stay yours to manage.

Use cases and examples

Agent integrations work best when your app contains data, workflows, knowledge, or repeatable expertise.

Each tool is one action from your app. Take a client portal: RShift Sites might propose a read-only list_open_requests tool, a create_request tool, and a get_request_status tool.

When a client asks their assistant “do I have any requests waiting on me?”, the assistant recognizes that list_open_requests matches the question, calls it, and answers with live data from your app.

An app can span several of these. It only needs one clear, useful task that works well through an assistant.

When it may not be a good fit

Not every app that can have an agent integration needs one. RShift Sites proposes tools, but it does not decide whether an integration is valuable or appropriate for your app, so consider that yourself first. An agent integration may provide limited value when:

• Your app’s value is mainly visual or interactive, such as a game or a portfolio site. A game can still have useful tools, such as retrieving statistics or managing a tournament, but turn-by-turn gameplay is usually better suited to the app’s own interface.
• The app is a static site with no meaningful action or information for an assistant to use.
• The only possible tools would be slow, expensive, destructive, difficult to reverse, or unsafe to run twice.
• The tools would expose more data or capability than the use case requires.

Prerequisites

Before you add an agent integration, make sure your app meets these requirements.

• A published app. Your integration serves the published version of your app, and the MCP link becomes available only after the app is published.

  On Free and Pro workspaces, the app must be published publicly. On Business and Enterprise workspaces, you can also publish the app to your workspace: the app and its tools then stay private to people with access to the app, and sign-in is always required. See Workspace-published apps.

• A supported stack. Newer apps, which use TanStack Start, host the integration in the app itself. On these apps, tools that are open to anyone and only return information built into the app do not need the built-in backend (Cloud), a connected Supabase project, a database, or user accounts. Older React + Vite apps need the built-in backend (Cloud). RShift Sites cannot add an agent integration to an older app that uses your own Supabase project.

• Authentication for sign-in. An integration that requires sign-in needs app authentication through the built-in backend (Cloud) or, on newer apps, a connected Supabase project. Public access always requires your explicit choice, and workspace-published apps always require sign-in. See Access, sign-in, and permissions.

• OAuth 2.1 for connected Supabase projects. If your newer app uses your own Supabase project and the integration requires sign-in, RShift Sites enables the OAuth 2.1 authorization server when you publish the app with a working Supabase connection. If OAuth is still disabled after publishing, reconnect the Supabase project in RShift Sites and publish again. RShift Sites also handles OAuth setup for apps on the built-in backend (Cloud).

Costs, credits, and usage limits

A tool call costs what the action behind it costs. Each call runs your app’s normal backend logic, so database operations, built-in backend usage, AI features, and third-party services count toward usage or incur charges the same way as direct app usage.

RShift Sites does not charge a separate fee for hosting the integration, publishing it, or tool calls.

There is no built-in rate limit or spending cap, so expose paid or resource-intensive actions only when your app already limits them. See Can I rate limit an agent integration? for details.

Enabling or changing an agent integration uses build credits. When you select Enable agent integrations, RShift Sites generates or updates the MCP server and its tools. The number of credits depends on the app and the work required.

Set up your agent integration

Start with a small number of focused tools. Prefer read-only tools before exposing actions that modify data, trigger paid services, or consume significant resources.

Before you publish, check what each tool can do, what inputs it accepts, what data it returns, whether the action enforces your app’s permission and plan checks, and whether it is safe if an assistant retries the call.

Add the integration

Open Agent integrations

Open your app in RShift Sites and go to More → Agent integrations.

Enable the integration

Select Enable agent integrations. RShift Sites adds an MCP server to your app and proposes a set of tools based on what your app does.

Selecting Enable agent integrations starts a build, which uses credits like any other build work in RShift Sites.

Choose who can connect

During the build, RShift Sites asks Who should be able to call this MCP server? Choose one of the following:

• Protected with OAuth (recommended): users sign in to your app before their assistant can call the tools. This is the default. If you skip the question, RShift Sites uses protected access.
• Public — no login: anyone can call the tools without signing in. You must choose this option explicitly. At the end of the build, RShift Sites summarizes which actions can be called and what data they can return without sign-in.

For apps published to your workspace, sign-in is the only option: a workspace app with an unauthenticated integration cannot be published.

See Access, sign-in, and permissions for details.

Review and adjust the tools

Review the generated tools in the AI tools section. Ask RShift Sites to add, remove, rename, or adjust tools if needed.

    Add a read-only tool that looks up an order by ID and returns its current status and items.

Publish your app

Publish your app, publicly or, on Business and Enterprise workspaces, to your workspace. Once it is live, the MCP link becomes available. RShift Sites runs automated security checks at publish. If the integration allows access without sign-in, RShift Sites warns you when you publish publicly, and blocks the publish when you publish to your workspace. See Workspace-published apps.

Copy the MCP link

In More → Agent integrations, copy the link from the Your MCP link card at the top of the panel, then share it with your users.

You can also start the setup from the project chat.

Add Agent integrations to this app so users can connect it to AI assistants like ChatGPT and Claude.

Review the tools

The AI tools section shows the tools available through your integration and what each one can do.

Each tool shows a status:

• Active: the tool is live in your published integration, and assistants can call it.
• Not published: you added or changed the tool after your last publish, so assistants do not see the updates yet. Publish your app to make them live. Tools from your last publish keep working in the meantime.
• Inactive: the integration is not currently available, for example because the app is no longer published publicly. Assistants cannot call its tools.

Each tool also has a capability label:

• Read-only: the tool only reads information.
• May modify data: the tool can create, change, or delete data. Review these most carefully.

Tools go live when you publish your app. There is no separate tool-approval step, so review every active tool before sharing the MCP link.

For each tool, check:

• The action it performs. Confirm the tool does only what its name and description say.
• The inputs it accepts. Prefer narrow inputs that match the task, such as a specific record identifier, rather than broad queries or arbitrary field values.
• The data it returns. Return only the fields the task needs. A read-only tool can still expose sensitive or unnecessary information.
• Its access checks. Confirm the action enforces the ownership, role, permission, and paid-plan requirements your app expects.
• Its retry behavior. For tools that change data, confirm that repeating the call does not create duplicate or unintended changes.

Tool names and descriptions matter, because the assistant chooses which tool to call based on what the user asks and how the tool is described. Compare:

• Vague: get_data, described as “Gets data.”
• Clear: list_open_orders, described as “Returns the signed-in customer’s open orders with order number, status, and total.”

You can ask RShift Sites to adjust tools in plain language.

Remove any tool that can delete records.

Rename the customer lookup tool so it is clear that it searches by email address.

Access, sign-in, and permissions

Agent integrations require sign-in by default. When RShift Sites generates your MCP server, it proposes an authenticated setup, and making tools public always requires your explicit choice.

Sign-in, permissions, and tool exposure are three different layers, and it helps to keep them apart:

• Sign-in identifies the caller. People connecting through an AI assistant authenticate through your app: they see your app’s sign-in screen, then a consent screen that asks them to approve the assistant’s access. Both are expected parts of connecting.
• Your app’s rules decide what the caller can do. A tool acts as the signed-in user. Rules your app enforces in its backend, such as each customer only seeing their own records, apply to tool calls too, and generated tools are not allowed to work around them. Extra requirements, such as owning the record, having a role, or being on a paid plan, apply only when the action itself checks them.
• The tool definition decides what is exposed. Review each tool’s inputs, the action it performs, and the data it returns.

A tool call does not go through your app’s screens. Buttons you hid, pages you removed from menus, and other interface-level controls do not protect a backend action on their own.

Choose an access configuration

You choose between two access configurations:

• Sign-in required, which is the default. Every tool requires the user to authenticate. Individual actions can then enforce role, ownership, or paid-plan requirements in your app’s backend, so an app that limits a feature to paying users keeps that limit for assistant calls. RShift Sites activates the OAuth capability on your app’s backend when you publish, without changing how your users sign in to the app itself.
• No sign-in. Every tool can be called without authenticating a user. This is a deliberate choice: RShift Sites asks you to confirm it, and it summarizes what the tools expose without sign-in.

Workspace-published apps

On Business and Enterprise workspaces, an app published to the workspace can have an agent integration too. The app stays private to your workspace, and its tools always require sign-in: publishing a workspace app with an unauthenticated integration is blocked with a message asking you to enable OAuth on the MCP server first.

When the integration still allows access without sign-in, the publish dialog shows MCP authentication is required rather than letting you continue, with an Ask RShift Sites button that asks the agent to add sign-in for you. The same block appears in More → Agent integrations as Publishing is blocked, with an Add sign-in button.

This also covers apps that are already published to your workspace. They keep serving and their integration keeps working, but you can’t publish any change to the app until the integration requires sign-in. You have three ways to resolve it:

• Add sign-in to the integration, which is what Ask RShift Sites and Add sign-in do for you.
• Publish the app publicly instead. A public app can have an integration that allows access without sign-in, and you get a security finding rather than a block.
• Turn the integration off, then publish.

Connecting to a workspace app’s integration involves two sign-ins. When someone adds the MCP link to their assistant, they first sign in with their RShift Sites account to pass the workspace access check, then sign in to the app itself, like they would in the browser.

The MCP connection endpoint is reachable by AI clients outside your workspace, because assistants need to reach it to start the sign-in flow. Sign-in protects the tools: without passing both sign-ins, no tools can be called.

Check the current access setting

The Agent integrations panel shows your current setup as a status card:

• Access is protected, with a Sign-in enabled badge, when tools require sign-in.
• Anyone can connect to your app, with a Public access badge, when tools do not require sign-in. This card includes an Add sign-in button. Selecting it starts a build that adds authentication to the integration.

If you set up your integration a while ago, open the panel and confirm the status card shows the access you expect. Switching between public and protected later is a build, not a settings toggle: select Add sign-in on the public card as the shortcut, or ask RShift Sites in the project chat, and it updates your app’s authentication setup.

For example, you can ask RShift Sites:

Require users to sign in before they can use this agent integration, and make sure the export report action checks whether the user is on a paid plan.

Automated security checks

RShift Sites runs two automated security checks on your integration:

• A basic check, at every publish. It checks whether your integration allows access without sign-in and warns you in the publish flow. When the app is published to your workspace rather than publicly, publishing is blocked instead of warned. This applies to every workspace and is a publishing requirement, separate from the findings below.
• A deep scan, when you publish a public integration. If your tools do not require sign-in, publishing a new or changed integration also starts a deeper scan of the tools themselves. It checks what each tool actually exposes and flags common risk patterns: private-data exposure, unintended record changes, bulk data access, and paywall bypass.

Findings from both checks appear under More → Security in your project, with deep-scan findings listed under App MCP data exposure.

Serious deep-scan findings are marked critical. If your workspace blocks publishing on critical security findings, you cannot publish again until they are resolved. Open a finding to review the issue, then ask RShift Sites to fix it, or mark it as ignored if it does not apply.

Automated checks do not replace your own review, and they may not detect risks that depend on your app’s custom business logic. Before sharing the integration, work through the checks in Review the tools and Test before you share.

For how RShift Sites’ security scanning works more broadly, see the Security overview and Project security view.

Test before you share

Connect your own app in an assistant your users are likely to use, such as ChatGPT or Claude, and test the main workflows before sharing the MCP link.

If the integration requires sign-in, test the full connection flow, including your app’s sign-in and consent screens. Connection and authentication issues often appear there first.

Test at least the following:

• Run each tool as an ordinary signed-in user.
• Try protected tools as a user without the required role, ownership, or paid plan, and confirm access is denied.
• Request a record that does not exist or belongs to another user.
• Confirm that each tool returns only the fields needed for its task.
• Run a write action twice and confirm it does not create duplicate or unintended changes.
• Test any paid or resource-intensive action against your app’s usage or plan limits.
• For an integration without sign-in, connect from a session where you are not signed in to the app and verify exactly which actions and data are available.

Connect your users

Once the integration is live, users connect your app to their AI assistant with the MCP link.

Supported assistants

Your app works with any AI assistant or agent that can connect to a remote MCP server and complete its sign-in flow. RShift Sites provides in-product connection steps for:

• ChatGPT
• Claude

Other MCP clients, such as Claude Code, Cursor, and VS Code, connect with the same MCP link through their own custom-connector setup.

Setup flows differ by assistant and can change over time. Open More → Agent integrations, then expand How to connect for the current ChatGPT and Claude steps. For other assistants, refer users to the assistant’s official documentation.

Share the MCP link

After you publish, RShift Sites shows your app’s MCP link in the Your MCP link card under More → Agent integrations. Users add this link as a custom connector in their assistant.

You can share the link directly, or create a connection page inside your app that explains what the integration does, includes the MCP link, and helps users connect it in the assistant they use.

To create a connection page, expand How to connect and select Ask RShift Sites to build.

Because assistant setup flows can change, avoid copying detailed connection steps into a page that will not be maintained. Link to each assistant’s official documentation, or review the page whenever a setup flow changes.

Use your app in your chats

A published app with an agent integration also becomes available inside RShift Sites, as a connector in its own workspace. Once you connect it, RShift Sites can call the app’s tools from a chat or the project chat: pull live data from the app while you build, run one of its workflows, or use it as context for another project.

Connections are personal. Each workspace member who wants to use the app in their chats connects it once, for themselves.

Connect the app

There are two ways to connect:

• From the app itself. Open More → Agent integrations and select Add to RShift Sites on the Use this app in RShift Sites chats card. The button becomes available once the app is published.
• From the connectors catalog. Open your workspace’s Connectors page and find the app under the RShift Sites apps section, which lists MCP connectors published from RShift Sites apps in your workspace. Select the app and connect, signing in to the app if it requires it.

Workspace members see an app in the RShift Sites apps section when they can access the published app. An app published publicly or to the whole workspace is visible to everyone in the workspace. An app published to a custom audience is visible only to that audience.

Use the app from chat

After connecting, mention the app in a chat or in the project chat like other connectors.

Use the Inventory Tracker connector to list items below their reorder threshold, and build a reorder summary page from the results.

Tools the app marks as read-only run without asking. Any other tool asks for your approval each time it runs. In the connector’s settings, you can change this per tool: always allow, ask each time, or never allow.

Manage app connectors

• Disconnect. Remove the connection from your workspace’s Connectors page. This only affects your own connection.
• Unpublish or delete the app. The app disappears from the RShift Sites apps section, and its tools stop working in chats.
• Workspace-wide control. Workspace admins can turn off Remote MCP connectors in Privacy & security (Settings → Security → Privacy & security → MCP connectors), which disables app connectors along with other MCP connectors and removes existing MCP connections. On Enterprise workspaces, this setting can be managed by the organization.

Maintain the integration

After launch, revisit the integration whenever you change tools, access logic, backend behavior, or your app’s domain. Changes reach users through publishing, and you stay responsible for what the integration exposes.

Keep it up to date

Your integration serves the published version of your app. After you change your app, tools, access logic, or domain:

Publish the app again

Publishing updates the live MCP server with your latest tools and settings.

Redeploy backend changes for older apps

For older React + Vite apps, ask RShift Sites to redeploy the app’s backend function after your changes so the live integration picks them up.

Ask users to refresh after tool changes

Users need to refresh the connector in their assistant when you add, remove, or rename tools. Changes to existing app behavior take effect after publishing and normally do not require a connector refresh.

Share the new link if it changed

If the MCP link changed, ask users to reconnect with the new link.

Open More → Agent integrations, then expand Refresh after app changes to see the refresh steps for ChatGPT and Claude. For other assistants, refer users to the assistant’s official documentation.

RShift Sites maintains the hosted MCP setup as the standard evolves, and protocol changes ship as versioned updates. When an update needs a change in your app, RShift Sites provides an upgrade path.

When your MCP link changes

The MCP link cannot be changed on demand.

• For TanStack Start apps, the link is based on your app’s web address, so it changes when you change the app’s primary custom domain, and users then need to paste the new link into their assistant.
• For older React + Vite apps, the link points to the app’s backend function, so it does not change with your domain.

Monitor, disable, and remove

Tool errors surface in your app’s logs like other backend errors. If you need tool calls tied to identities, keep sign-in on, so every call comes from a signed-in user of your app.

To stop or restrict the integration:

• Remove a tool. Ask RShift Sites to remove it, then publish. The tool disappears from the integration.
• Remove the whole integration. Ask RShift Sites to remove agent integrations from the app, then publish. RShift Sites removes the generated code and takes the MCP server offline. Your app keeps working as before.
• Unpublish the app. This takes the MCP server offline immediately along with the app itself. Existing assistant connections cannot call it while the app is unpublished.
• Delete the project. This permanently removes the app and its MCP server.

Best practices

• Start with the main user jobs. Create tools for the actions users already come to your app to complete. New app features do not become tools automatically, so ask RShift Sites to expose each action you want assistants to use.
• Write clear tool names and descriptions. Explain what the tool does, what inputs it needs, and what result it returns. Clear names and descriptions help the assistant choose the right tool.
• Return only the data the task requires. A tool exposes its returned data as well as its action. Ask RShift Sites to limit results to the fields the tool’s purpose requires.
• Separate read and write actions. Make it clear which tools only retrieve information and which tools can create, update, or delete data.
• Make write actions safe to retry. An assistant may retry a call after a timeout or connection error, and a tool that creates or changes something could then do it twice, such as creating the same order two times. Ask RShift Sites to design write tools so a repeated call does not duplicate the change, for example by checking whether the change was already applied or by using a request identifier.
• Keep sign-in on by default. Allow access without sign-in only when every exposed action and returned field is safe for anonymous use.
• Enforce restricted access in your app. If a tool returns private information, changes records, or runs a paid feature, verify the user’s permissions, ownership, role, and plan before completing the action.
• Publish after changing tools. New, removed, or updated tools do not reach users until you publish the app.
• Add a connection page. Give users the MCP link, explain what the integration can do, and point them to current setup instructions. See Share the MCP link.

Limitations

• Long-running tools can time out. Tools run one action at a time, and the assistant waits for the result with a time limit. Work that takes more than tens of seconds, such as processing a large file or generating media, can show as stuck or interrupted in the assistant. Keep tools fast, and run heavier work inside the app.
• Integrations cannot send alerts on their own. Your app cannot notify an assistant. Assistants only act when a user asks, so “watch this and alert me” workflows do not work.
• Users must refresh after tool changes. Assistants keep a copy of your tool list. After you add, remove, or rename tools and publish, users see the previous list until they refresh the connector, which slows down iteration on a live integration.
• There is no public discovery directory. People outside your workspace cannot browse a directory of agent integrations, so you share the MCP link with your users yourself. Inside your own workspace, published apps appear under RShift Sites apps on the Connectors page.

FAQ

What is an MCP server?

An MCP server exposes your app’s actions as tools that an AI assistant can call. MCP stands for Model Context Protocol, an open standard for connecting assistants to external tools.

Is this a new product or a copy of my app?

Neither. The agent integration is a new way into the same app. Your app does not move into the assistant. The assistant gets a way to call your live app, your app does the work, and the integration follows the published version whenever you update it. Your visible pages and normal user flow stay the same. RShift Sites adds the tool code and connection endpoints the integration needs.

What happens if my app already has a custom MCP server?

RShift Sites does not detect a hand-built MCP server in advance. If your existing server uses the same routes, the build fails rather than overwriting your code. Ask RShift Sites to rebuild your existing server as an agent integration, or to set the integration up on a different path.

Will this expose my paid or private content?

Not when the integration and its tool actions are configured correctly. Agent integrations require sign-in by default. Backend rules that use the signed-in user’s identity apply to tool calls, while each protected action must still enforce any additional ownership, role, permission, and paid-plan requirements. Review both what each tool can access and what it returns before publishing.

Can I make only some tools public?

No. Sign-in applies to the whole integration: all tools require sign-in, or none do. Inside a protected integration, individual tools can apply their own checks in your app’s logic, such as requiring a specific role or plan.

Can I rate limit an agent integration?

Not today. There is no built-in rate-limit control or tool-call quota. Requiring sign-in prevents anonymous calls and ties every call to a user, but it does not limit how often a signed-in user can call a tool. Avoid exposing expensive actions unless your app already enforces a usage or plan limit for them.

Can I see who is using the integration?

RShift Sites does not show tool-call activity, but tool errors appear in your app’s logs like other backend errors. If your integration requires sign-in, every call runs as a signed-in user of your app, so any changes it makes show up in your app’s data like normal user activity.

How do I disable the integration?

Ask RShift Sites to remove a tool or the whole integration, then publish. Unpublishing the app also takes the MCP server offline immediately. See Monitor, disable, and remove.

Do tool calls cost me anything?

There is no separate RShift Sites charge for tool calls. A tool call runs in your app’s backend like normal app usage, so if a tool uses the built-in backend or AI features, that usage counts against your app’s balance the same way it does when someone uses your app directly. Require sign-in to prevent anonymous calls, and make sure your app enforces a plan or usage limit for expensive actions.

Which assistants can connect to my app?

Any AI assistant or agent that can connect to a remote MCP server and complete its sign-in flow. RShift Sites provides in-product connection steps for ChatGPT and Claude, and other MCP clients, such as Claude Code, Cursor, and VS Code, connect with the same MCP link.

Can I use this with a workspace or internal app?

Yes, on Business and Enterprise workspaces. Publish the app to your workspace, and its agent integration stays private along with the app: tools always require sign-in, and users pass the RShift Sites workspace access check before signing in to the app. See Workspace-published apps. On Free and Pro workspaces, agent integrations require a publicly published app.

Can my teammates use my app from Chats or the project chat?

Yes. Workspace members who can access the published app find it under RShift Sites apps on the workspace’s Connectors page and connect it for themselves. See Use your app in RShift Sites chats.

Can my app use another app’s integration at runtime?

No. Connections work when you chat with RShift Sites, in a chat or in the project chat. They are not part of a published app, so your app cannot call another app’s tools while people use it.

Troubleshooting

The Enable agent integrations option is not available

You can enable the integration before publishing, but the integration only becomes available to users after the app is published: publicly on Free and Pro workspaces, publicly or to your workspace on Business and Enterprise workspaces. If the option stays disabled, publish your app first, then try again.

My app is published to the workspace, but AI clients cannot reach its MCP

A workspace-published app can serve its MCP from a link that AI assistants outside the workspace cannot reach. The Agent integrations panel shows an AI assistants can’t reach your MCP yet card when this happens: select Fix MCP link, and RShift Sites moves the MCP server to a public link while the app itself stays published to your workspace. Sign-in still protects the tools.

The Add to RShift Sites button is grayed out

The hint under the button says why. Publish the app if it is not published yet, or republish it if the hint asks for a republish. If the connector is still being prepared, it becomes available shortly after publishing. An app published to a custom audience can only be added by that audience, and only members of the app’s workspace can add it. You also need to be a workspace editor to connect MCP servers. If the connector failed to be created, select Fix connector to have RShift Sites investigate, or republish the app.

Users cannot see my latest tools

Publish your app after your changes, then have users refresh the connector in their assistant (such as ChatGPT or Claude). For older React + Vite apps, ask RShift Sites to redeploy the app’s backend function after your changes.

Connecting fails or returns an error

• Confirm your app is published and that you pasted the current MCP link.
  • If your app requires sign-in, make sure users complete the sign-in step when the assistant prompts them.
  • If your tools do not require sign-in, check the connector’s authentication setting: ChatGPT defaults new connectors to OAuth, so select the no-authentication option when adding a server that does not require sign-in.

Connecting fails at the sign-in step with an error about ID tokens, JWT signing, or HS256

Older projects may use a token-signing setup that some assistants do not accept. Ask RShift Sites to migrate your project’s signing keys. It asks for confirmation, runs the migration, and connecting works afterward.

The sign-in page shows a 404 during connect

The sign-in screen is part of your app, so it only exists once the app is published. Publish your app, then have the user connect again.

RShift Sites says it cannot secure the MCP server

On newer apps using your own Supabase project, RShift Sites activates OAuth when you publish. If OAuth is still disabled afterward, reconnect the Supabase project in RShift Sites and publish again.

Older React + Vite apps require the built-in backend (Cloud). RShift Sites cannot add an agent integration to an older app that uses your own Supabase project. See Prerequisites.

The assistant is not calling my app

In most assistants, including ChatGPT and Claude, the connector has to be enabled from the chat composer for that conversation. Ask users to enable it, then make the request explicit, for example “Use [app name] to check my open requests.”

A tool call shows as stuck or interrupted

The tool is probably doing work that takes longer than the assistant’s timeout, such as processing a large file or generating media. Assistants can also retry timed-out calls, which can create duplicate records. Ask RShift Sites to make the tool respond immediately and add a separate tool to check the result, or move the heavy work into the app itself.

The build fails after I added the integration to an app with an existing MCP server

RShift Sites refuses to overwrite MCP code you wrote by hand. Ask RShift Sites to move your existing server to a different path, or to rebuild it as the agent integration.

The MCP link stopped working

For TanStack Start apps, changing the app’s primary custom domain changes the MCP link too. Copy the new link from the Your MCP link card in More → Agent integrations and share it with your users.

Older React + Vite app links point to the app’s backend function and do not change with your domain.

Related topics

• Connect a custom MCP server as a chat connector
• Chat connectors: Connect your tools to RShift Sites using MCP servers
• RShift Sites MCP server
• MCP registries
• Privacy & security settings