MCP Servers

What's on these screens

MCP Catalog in Instance Settings lets a Vibedata Owner configure organization MCP deployments. Each catalog entry shows its nested deployments and whether each deployment is Ready or Not ready. Entries that use a shared OAuth app include that setup when it is needed.

MCP Servers in User Settings lists the deployments available to the signed-in user. Each user connects and authorizes every deployment separately, even when sibling deployments share one organization OAuth app.

A deployment is available across the whole organization. It is not tied to a Domain: once you connect a server, it is available in every Intent you open, whichever Domain that Intent belongs to. Your connection is still your own — connecting a server does not connect it for anyone else.

Which setup a catalog entry asks for

Entries differ in where their credentials come from, and the Add deployment form shows only the fields the entry needs.

The entry uses	The Vibedata Owner supplies	Each user supplies
A shared OAuth app	Client ID and Client secret, tested before the first deployment	Nothing — they click Connect OAuth and approve at the provider
Container OAuth	Every required Environment field for the provider application	Nothing — they click Connect OAuth and approve at the provider
Environment values	Every required Environment field, such as a tenant, client, or secret	Their own credential, if the entry asks for one
Neither	A name only	Nothing

Entries that run as a container never use a shared OAuth app, because there is no endpoint for Studio to test an app against. They use environment values instead.

How to add a deployment that uses environment values

1. Open Instance Settings and select MCP Catalog.
2. Find the catalog entry and click Add deployment.
3. Fill in Name (optional), then complete every required Environment field.
4. Click Add deployment.

These values are the organization's own registration with the provider, shared by everyone who uses the deployment. Studio sends them to the runtime and never shows them again; secrets use password inputs. To change one later, use Edit on the deployment row and re-enter it.

There is no Test step for this shape. The deployment shows Not ready until its runtime reports itself healthy, which can take a moment after creation while the container image is pulled and started. A deployment that stays Not ready usually means a wrong environment value or an unreachable image — check the values with Edit.

Fields that offer a fixed set of values

Some catalog entries declare exactly which values a field accepts — a read-only toggle, a data region, a product surface. Those fields appear as a dropdown rather than a text box, with nothing pre-selected when the entry names no default. Pick one of the listed values and save.

Studio accepts only the listed values, matched exactly. True, yes, 1, or a value with a stray space is rejected with a message naming the field and its accepted values, and nothing is created or changed until you correct it. This matters because these values decide what the connector does: a read-only toggle that is not exactly true leaves the connector able to write, and a region value that is not one of the listed hosts points the deployment at a different endpoint.

Fields with no declared value set are still ordinary text or password fields. The same dropdown appears for a per-user field whose entry declares a value set, in MCP Servers under User Settings.

If a deployment was saved before its entry declared a value set, opening Edit shows Saved values are outside the accepted set and names each affected field with the values it accepts. Studio does not display the stored value and does not change it for you — pick a listed value and save to correct it. An edit that submits any value submits them all, so complete the other required fields in the same save.

How users connect a server that uses container OAuth

1. Open User Settings and select MCP Servers.
2. Find the deployment and click Connect or Connect OAuth.
3. Complete the provider sign-in and consent screen.
4. Return to Studio and confirm the deployment shows Connected.

Obot keeps each user's authorization separate and refreshes it when the provider allows. Studio never asks you to paste a bearer token and does not receive the provider token. If the grant can no longer be refreshed, use Connect OAuth to authorize again.

Each authorization attempt is single-use and expires. Finish the provider screen in one sitting: reopening an old provider link, returning after the attempt has expired, or letting a second window finish the same attempt is refused as invalid or expired instead of connecting. Start again from Connect OAuth. A refused attempt never disturbs a connection you already have.

How users connect a server that asks for a token

1. Open User Settings and select MCP Servers.
2. Find the deployment and click Connect.
3. Complete the setup form. A token field is a password input and is stored for your account only.
4. Click Save.

Your value is yours alone: two users of the same deployment reach the provider as themselves. Studio never shows a saved value back to you — to change it, enter a new one. Use Disconnect to remove your connection along with its saved setup.

If the provider issues short-lived tokens, your connection stops working when the token expires. Studio does not refresh it for you. Open MCP Servers, connect again with a fresh token, then Pause the Intent and open it again to load it into a running Intent.

How to register the Slack callback URL

1. Open Instance Settings and select MCP Catalog.
2. Find Slack Workspace and click Add deployment.
3. In Add Slack Workspace deployment, copy Callback URL with Copy callback URL.
4. Add that exact URL to the allowed redirect URLs in the Slack app's OAuth settings.
5. Return to Studio and keep the form open to test the app.

Use the displayed URL. Do not construct or shorten it.

How to configure the OAuth app and add the first deployment

1. In Add Slack Workspace deployment, fill in Name (optional), Client ID, and Client secret.
2. Click Test OAuth and finish authorization in the provider window.
3. Wait for Test successful. Add deployment is enabled for these exact values.
4. Click Add deployment.

Add deployment stays disabled until the exact current Client ID and Client secret pass Test OAuth. Editing either field, leaving the form, a failed or expired test, or a closed provider window requires Test again. Studio saves the shared app and creates the deployment from that one submit. If app Save succeeds but deployment creation fails, the app remains configured and the next Add deployment asks only for deployment settings.

How to add another Slack deployment

1. Find Slack Workspace in MCP Catalog.
2. Click Add deployment.
3. Enter a distinct Name (optional), such as a workspace name.
4. Click Add deployment.

Sibling Slack deployments share one OAuth app. Deployment names and organization settings remain separate.

How to replace the OAuth app

1. Find the configured catalog entry, open its More actions (…) menu, and click Replace OAuth app.
2. In Replace Slack Workspace OAuth app, fill in the replacement Client ID and Client secret.
3. Click Test and finish provider authorization.
4. Wait for the successful test message, then click Save.
5. Ask users to reconnect each affected deployment from User Settings.

Testing a replacement does not disturb the active app. Invalid test results or an invalid Save proof leave the active app and existing connections unchanged. After a successful replacement, Studio reports OAuth credentials replaced. All Users must reconnect. All deployment rows remain.

If Studio cannot confirm a replacement outcome, it reports Replacement did not finish. The existing OAuth app remains active. Test the values again before retrying.

How to clear the OAuth app

1. Find the configured catalog entry, open its More actions (…) menu, and click Clear OAuth app.
2. Review Clear Slack Workspace OAuth app.
3. Click Clear OAuth app to confirm.

All sibling deployment rows remain, but they show Not ready. The entry does not show a persistent OAuth warning. Open its More actions (…) menu, select Configure OAuth app, and test and save the shared app to restore the existing deployments without creating another one.

How users reconnect

1. Open User Settings and select MCP Servers.
2. Find each affected deployment.
3. Click Connect OAuth and finish authorization in the provider window.
4. Return to Studio and confirm the deployment shows Connected.

Repeat these steps for every affected deployment. One user's connection does not reconnect another user or another deployment.

If OAuth finishes but the provider rejects MCP initialization, the deployment shows Unavailable with the provider's safe reason. The row shows Retry and Disconnect, not Connect OAuth. Enable MCP access for the app at the provider, then click Retry. A successful retry returns the deployment to Connected.

An Intent can still open without that deployment. Studio shows Opened with some MCP servers unavailable and pairs the deployment name with the safe reason. After the deployment returns to Connected, Pause the Intent and open it again to load it.

What you'll see

• No deployments configured. — no organization deployment exists yet.
• Saved values are outside the accepted set — a saved value no longer matches what its entry accepts. Pick a listed value in that field and save.
• Ready — the organization deployment has its required organization configuration.
• Not ready — the deployment remains defined but cannot be used: its shared OAuth app was cleared, its runtime has not reported itself healthy, or an organization value is wrong.
• Starting OAuth test… — Studio is opening the provider test.
• Waiting for the provider to finish authorization… — finish authorization in the provider window.
• Provider authorization was denied. Test again. — retry the test and approve the provider request.
• The provider rejected the credential test. Check the app credentials and test again. — verify Client ID, Client secret, and the registered Callback URL.
• The OAuth test was interrupted before it finished. Test again. — the provider returned to Studio but the test did not complete. Run Test again; the interrupted attempt cannot be resumed.
• The successful test is no longer valid. Test these values again. — the proof expired, changed, or was already used.
• This OAuth app is being changed. Try again. — another app or deployment mutation holds the catalog-entry lock.
• MCP catalog unavailable — Obot is not responding. Use Retry after the catalog service is healthy.
• MCP is not configured — repair the installation before using MCP Catalog. Intents still open normally on such an installation, with Studio's built-in tools and no MCP notice.
• Unavailable with a provider reason — OAuth is stored, but the provider rejected MCP initialization. Enable MCP access at the provider, then use Retry; Disconnect remains available.
• Opened with some MCP servers unavailable — the Intent remains usable without the named deployment. Restore the provider access, then Pause the Intent and open it again to load it.

Quick reference

Control	What it does
Add deployment	Opens one deployment form and includes shared OAuth app setup only when required.
Environment fields	Carry the organization's own registration with the provider. Shared by every user.
Fields with a dropdown	Accept only the values the catalog entry declares, matched exactly.
Callback URL	Shows the exact redirect URL to register with the provider.
Copy callback URL	Copies the displayed callback URL.
Client ID	Identifies the provider OAuth app.
Client secret	Supplies the provider OAuth app secret for Test and Save. Studio never displays a saved secret.
Test OAuth / Test again	Runs a real authorization and token exchange for the exact current values.
Replace OAuth app	Tests and atomically replaces the shared OAuth app.
Clear OAuth app	Removes the shared app and local user grants while retaining deployment rows.
Configure OAuth app	Restores a missing shared app when deployment rows remain.
Connect OAuth	Lets the signed-in user authorize one deployment.
Connect	Starts the signed-in user's setup for one deployment, including a per-user token field.
Disconnect	Removes the signed-in user's connection, saved setup, and authorization for one deployment.