MCP Servers

What's on these screens

MCP catalog in Org settings lets a Vibedata Owner configure organization MCP instances. Its Catalog tab lists available entries; MCP instances lists the instances added to the organization. Selecting a catalog row switches to its filtered instances. OAuth setup is an entry overflow action, and instance rows open their edit form directly.

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

Each catalog entry and user server row shows the provider image when one is available. If the image is missing or cannot be loaded, Vibedata shows a generic server icon without hiding the row, status, or actions.

An instance 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. Add instance shows only configurable catalog fields. A required field has an asterisk. The Owner selects Preconfigured to enter a shared value, or delegates the field so each user provides their own. An optional field can also be ignored. Catalog-supplied fields do not appear.

The entry uses	The Vibedata Owner supplies	Each user supplies
A shared OAuth app	Client ID and Client secret, tested before the first instance	Nothing — they click Connect OAuth and approve at the provider
Environment values	Values marked Preconfigured for this instance	Values marked User-provided for this instance
Neither	A name only	Nothing

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

Browse the catalog and instances

The Catalog tab lists available MCP entries. Click an entry to switch to MCP instances with that entry selected as a filter. Clear the filter to see all instances. Both tabs search any part of the displayed name, ignoring case.

The catalog synchronizes at startup. Opening this page reads the current catalog without refreshing it. Use Refresh catalog to synchronize it manually, then Update instances to update existing instances from the current catalog definitions.

The catalog shows OAuth setup required only when a required shared OAuth app is missing. Having no instances is not a setup error. Configure the shared app from the entry’s More actions (…) menu.

Use Add instance in the instances tab. With a catalog filter selected, it adds that entry; without a filter, choose an entry from the menu. Click an instance row or choose Configure instance from its overflow menu to open the edit form directly. Remove instance is in the same menu and asks for confirmation.

Leaving an edited instance form asks whether to discard unsaved changes. Choose Keep editing to preserve the draft or Discard changes to leave. Cancelling an edited OAuth setup form uses the same confirmation.

How to add an instance that uses environment values

1. Open Org settings and select MCP catalog.
2. Click the catalog entry to open MCP instances filtered to that entry, then click Add instance.
3. Enter a name if needed. Required fields start Preconfigured; optional fields start Ignore. Choose who provides each field, and enter values for Preconfigured fields.
4. Click Add.

Preconfigured values are shared by everyone who uses the instance. Saved values are never shown again in the form. Sensitive fields start masked; use the eye control to show or hide the value you are entering. When editing, leave an unchanged Preconfigured value blank to keep it. Each user supplies only fields delegated by this instance.

There is no Test step for this shape. The instance shows Needs attention until its runtime reports itself healthy, which can take a moment after creation while the container image is pulled and started. An instance that stays Needs attention usually means a wrong environment value or an unreachable image — open the instance row to check its configuration.

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. Nonsensitive fields appear as a dropdown, with nothing pre-selected when the entry names no default. Fields the catalog marks sensitive use a password input even if accepted values are declared; the reveal button inside the field reads back what you typed, and a saved value is never returned. Enter an accepted value and save.

Vibedata 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 instance 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 an instance was saved before its entry declared a value set, opening the instance row shows Saved values are outside the accepted set and names each affected field with the values it accepts. Vibedata 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 OAuth

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

Each user's authorization is separate and refreshes when the provider allows. You do not need to paste a bearer token for OAuth. If the grant can no longer be refreshed, use Connect OAuth to authorize again.

When you finish at the provider, the window shows the authorization result:

• On success it says <server name> is connected, closes by itself, and the MCP servers list refreshes.
• If authorization fails, the window stays open and explains the failure, with the provider's error code when one is available. Close it, then use the row's action again.
• If Vibedata cannot confirm the connection in time, the window shows Can't confirm the authorization. Close it and check the row in the MCP servers list.
• If the window does not close, select Return to Studio.
• Opening the completion page directly, without starting from Connect or Connect OAuth, shows Nothing to confirm.
• A few providers clear the link between the window and Vibedata, so the window can show Nothing to confirm even after a real sign-in. Close it: the MCP servers list still shows the result.

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 the row's Connect or Connect OAuth action. 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 instance 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 instance reach the provider as themselves. Vibedata never shows a saved value back to you — to change it, enter a new one. If your organization fully sets up a server, there is nothing for you to connect: it appears Connected and is ready to use in Intents. Opening MCP servers prepares your MCP connection automatically, and Connect appears only where you have something to supply or a provider to authorize. Use Disconnect to clear the authorization Vibedata saved for you on that instance; a confirmation dialog names the instance, and selecting Disconnect there removes that authorization so you can authorize again. It leaves the instance available to everyone and keeps your other instances connected. Disconnect appears only when you have an authorization saved to clear; an instance that never needed one has no Disconnect action.

If the provider issues short-lived tokens, your connection stops working when the token expires. Vibedata 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 connect a server the agent asks for

When the agent needs a tool on an instance you have not connected, it asks Vibedata to connect it, or tries the tool directly. A Connection needed card appears in the dock above the composer. If you hold the Intent's edit lease, the card shows Connect and Dismiss for each requested server:

1. Click Connect. MCP servers opens with the named server row focused and scrolled into view.
2. Connect the instance as described above.
3. Vibedata re-checks the Intent's MCP servers as soon as the connection succeeds, and shows a notice such as GitHub is now connected. It checks again when you close Settings with Back.
4. Ask the agent to retry.

Only the edit lease holder sees Connect; read-only viewers can dismiss their own notice. Each offer expires five minutes after it first appears. The card shows the remaining time; when several servers need connections, each row has its own countdown and the header shows the next expiry. Dismissal and the original expiry survive reload and do not change the recorded call or send anything to the agent. A new refusal in a later Turn can raise a new offer. A successful connection recheck clears the offer; the failed attempt remains in Agent activity, and retrying is always an explicit action. A server that does not fit in the Conversation's MCP tool budget stays unavailable until a new Intent, even if you disconnect another server.

How to retry a failed connection action

1. Find the affected instance in User Settings → MCP servers.
2. Read the service message below that instance. Vibedata redacts secrets while retaining the service's actionable explanation.
3. Correct the problem at the service, then click Retry.

When Vibedata confirms the failed action can be repeated, Retry replaces the button that failed and repeats the same action. If you still have a saved authorization on that instance, Disconnect remains available. If the service supplies no usable detail, Vibedata shows a stable message for the failed action.

How to register the Slack callback URL

1. Open Org settings and select MCP catalog.
2. Find Slack Workspace in Catalog.
3. Choose Configure OAuth from the entry’s More actions (…) menu, then 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 Vibedata 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 instance

1. Choose Configure OAuth from Slack Workspace’s overflow menu and fill in Client ID and Client secret.
2. Click Test and finish authorization in the provider window.
3. Wait for the successful test message, then click Save.
4. Click the catalog row to open its filtered MCP instances list, select Add instance, enter Name if needed, and click Add.

Add instance stays disabled until the shared app has been tested successfully and saved. A successful test alone does not enable it. Save stays disabled until the exact current credentials pass the test. Editing either credential or a failed or expired test requires testing again. The saved OAuth app is shared by the entry's instances; adding an instance preserves that registration. A failed provider window explains the failure and offers a return to Studio. Close it and retry from the form when necessary.

How to add another Slack instance

1. Open Slack Workspace in MCP catalog.
2. In MCP instances, click Add instance.
3. Enter a distinct Name, such as a workspace name.
4. Click Add.

Sibling Slack instances share one OAuth app. Instance names and organization settings remain separate.

How to recover from a failed instance change

1. Read the message on the add, edit, or remove form. Your draft stays open after a failed save.
2. Correct the problem described by the message.
3. When the action is available, select Add, Save, or Remove instance again.

If Vibedata cannot confirm whether an add or edit was saved, it disables resubmission. Close the form and check MCP instances before trying again, so you do not repeat a change that already succeeded. Saved organization values remain hidden; you may need to re-enter them when you reopen the form.

If an OAuth setup or removal reports that the saved configuration changed, close the form and reopen it to review the current configuration before submitting again.

How to replace the OAuth app

1. Find the configured entry in Catalog.
2. Choose Replace OAuth app from its overflow menu and 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. Confirm Replace OAuth app.
6. Ask users to reconnect each affected instance 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, Vibedata reports OAuth credentials replaced. All Users must reconnect. All instance rows remain.

If Vibedata 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 instance rows remain, but they show Needs attention. The entry shows OAuth setup required. Choose Configure OAuth from its overflow menu to test and save the shared app, restoring the existing instances without creating another one.

How users reconnect

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

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

If OAuth finishes but the provider rejects MCP initialization, the instance 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 instance to Connected.

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

What you'll see

• No instances yet — no instance exists for the current catalog filter, or none exists in the organization if no filter is selected.
• 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 instance has its required configuration and its runtime reports that it is ready.
• Needs attention — the instance 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… — Vibedata 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 Vibedata 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 change to this catalog entry is in progress.
• MCP catalog unavailable — Obot is not responding. The message names what Vibedata could not read, keeps Obot's own explanation, and offers Retry.
• Unable to load MCP server instances — the page could not read your MCP servers from Obot. Vibedata shows Obot's explanation beneath its own line; use Retry once the service is healthy. It never replaces that explanation with a generic message.
• MCP is not configured — repair the installation before using MCP Catalog. Intents still open normally on such an installation, with Vibedata'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 instance. Restore the provider access, then Pause the Intent and open it again to load it.
• Retry — replaces a failed row action only after Vibedata confirms that repeating it is safe.
• A service message below the affected row, dialog, or page — secrets are redacted, while actionable provider details remain visible.
• A generic server icon — the provider image is missing or could not be loaded; the server row and its actions remain available.

Quick reference

Control	What it does
Catalog / MCP instances	Browse available entries or manage the instances added to the organization.
Refresh catalog	Synchronizes the catalog on request. Opening the page does not start a refresh.
Update instances	Updates existing instances from the current catalog definitions.
Add instance	Opens the form for a new instance.
Configure instance	Opens the selected instance's edit form, as does clicking its row.
Remove instance	Removes the selected instance after confirmation.
Preconfigured / User-provided / Ignore	Choose a shared value, a value each user supplies, or omission of an optional field.
Fields with a dropdown	Accept only the values the catalog entry declares, matched exactly.
Copy callback URL	Copies the exact redirect URL to register with the provider.
Client ID / Client secret	Supply the shared OAuth app credentials. Saved secrets remain hidden.
Test / Test again	Tests the exact current OAuth app credentials with the provider.
Configure OAuth	Opens setup for a missing shared OAuth app. Test it, then select Save.
Replace OAuth app	Tests and replaces the shared OAuth app after confirmation.
Clear OAuth app	Removes the shared app and local user grants while retaining instance rows.
Connect OAuth	Lets the signed-in user authorize one instance.
Connect	Starts the signed-in user's setup for one instance.
Disconnect	Clears your saved authorization for one instance after confirmation; other connections stay.
Retry	Repeats a failed personal connection action when it is safe.