Pilot and Roll Out

Controlled Availability

MCP Workspace is available to a limited set of customers. Moveworks is validating the experience and gathering feedback, so capabilities and limits may change. To request access, register your interest.

Try a new server with a small pilot audience before you give it to everyone. A pilot shows whether the assistant picks the server’s tools for real requests, and whether sign-in and results work, before the server competes with the rest of your tool environment.

Choose a server for an app or use case you do not already cover, and review the tools it exposes.
Set a small pilot audience in Launch Configuration.
Test the requests that users need to complete.
Confirm that the assistant uses the MCP tool, then widen access when failures are diagnosable.

Start after you connect the server and Preview Tools returns its tools.

Choose What to Pilot

How the Assistant Picks a Tool

For each request, the assistant chooses from the MCP servers, Tool Studio plugins, and Enterprise Search available to that user. When more than one tool could handle the request, the assistant can choose the wrong tool or stop before it reaches the MCP server.

For example, Enterprise Search can answer a broad Notion request before a Notion MCP tool is considered, or an existing Linear plugin can win over a new Linear server. Design around the overlap before you expand access.

Start with New Apps and Use Cases

Connect MCP servers for apps and use cases that you do not already cover. A new app or a new use case gives the assistant a clearer choice.

Lower risk: connect first	Higher risk: defer or plan carefully
A server for an app you do not already cover with a plugin	A server that duplicates an existing plugin’s job
A lookup or read use case that nothing else covers	A use case that Enterprise Search already answers
A homegrown server for an internal system with no existing coverage	A server that overlaps heavily with a mission-critical plugin

If a server overlaps with an existing tool, expect selection issues. Reduce that overlap before you make the server available broadly.

Keep the Tool Environment Lean

Preview a server’s tools and review the inventory before you enable it. A single server can expose dozens or hundreds of tools.
Add servers deliberately. Confirm one works before you connect the next.
Disable a server that you are not actively using so it does not compete for selection.

The assistant narrows to a relevant set of tools for each request, so raw tool count matters less than overlap and very large individual servers. There is no published hard limit, but treat a server with well over a hundred tools as higher risk and pilot it carefully.

Set the Pilot Audience

After you publish the server, two settings control who can use it. The Enabled toggle turns an MCP server on or off. Launch Configuration controls which users can reach an enabled server. Start with a defined pilot audience instead of launching a new server broadly.

Launch Configuration tab and Enabled toggle annotated to show that Launch Configuration controls the audience and Enabled turns the server on or off. — Enabled turns a server on or off. Launch Configuration controls its audience.

MCP Workspace controls access at the server level. You cannot allow or block individual tools inside a server. Review the full tool inventory before you enable the server, especially when it exposes write actions.

Universal Assistant only during Controlled Availability

MCP tools run in the Universal Assistant. Productivity Assistant support is not available during Controlled Availability.

User permissions still apply

Connecting a server does not change upstream permissions. With per-user authorization, the server enforces the employee’s access. With application credentials, it enforces the application’s access. Launch Configuration still controls which employees can reach the server.

What Users Do the First Time

For per-user authorization, the first time a user asks the assistant to use a connected app, the assistant can prompt them to sign in within the conversation. After they complete sign-in, later requests can use the server without prompting again. Ask each pilot user to complete this sign-in when prompted.

Example conversation in which the assistant asks a user to connect an app before completing a request. — An example of an in-chat prompt to connect an app the first time it is needed.

If a server works for some users but not others, check their audience access, upstream permissions, and sign-in. If a stored token fails, use the authentication recovery steps.

Test with Real Requests

Ask pilot users to name the app and the item they need. Specific requests make it easier for the assistant to select the intended tool.

Instead of	Ask
”What needs my attention?"	"In Linear, show my open urgent issues."
"Find the incident details."	"In ServiceNow, show the status and assignee for incident INC0104822."
"Sort out my follow-up."	"In Slack, find my unread mentions from this week and summarize the ones that need a reply.”

Use these request types in the pilot:

Request type	Example
Lookup	”What are my open pull requests in GitHub, and which have requested changes?”
Standard action	”Create a Linear issue for this regression and assign it to me.”
Bulk action	”Add a status-update comment to all my open urgent Linear issues.”
Multi-app work	”Read the action items in this Notion incident retro, then create a Linear issue for each named owner.”

For bulk actions and multi-app work, name the apps and state each intended step. The assistant does not automatically compose a complex cross-app workflow from a vague goal, and one MCP tool call does not automatically trigger a tool on another server.

Validate the Connection Before Rollout

Use the requests your employees need, including the slowest retrieval and the cases most likely to fail.

Test	Confirm
Two employees with different upstream permissions	Each sees only the data allowed by the configured authentication method. Application credentials use application access, not separate employee permissions.
A token refresh after the initial sign-in	The next request succeeds without a new sign-in while a valid refresh token is available. A fresh login alone does not prove refresh works.
A revoked or expired authorization	The employee can recover with the authentication recovery steps.
Your slowest expected request	The request finishes within the 120-second timeout, and its latency appears in the tool call log. Use the timeout guidance if it fails.
An answer with sources	The tool returns answer text and source URLs in text blocks. The assistant’s answer links to the expected source.
A tool error or expired MCP session	The failure appears in the log. Do not assume that the call automatically restarted or that a write did not complete.
A request that Enterprise Search can also answer	The intended MCP tool is selected with the normal search configuration enabled.
An employee outside the pilot audience	The employee cannot use the server.

Check Which Tool Ran

Use More info > Reveal AI Reasoning on a response to check whether the assistant called an MCP tool. MCP tool calls use the format mcp__<server>__<tool>.

If the assistant selects a plugin or Enterprise Search instead, you have a tool-selection issue. See Use Temporary Testing Levers Carefully. If it selects the expected MCP tool but the result is wrong or the call fails, find the MCP tool call log and work through Troubleshooting.

Use Temporary Testing Levers Carefully

You may need to change the surrounding tool environment to understand a pilot result. These are testing levers, not permanent configuration.

If you see	Test approach
An existing plugin wins over the MCP tool for the same simple request	Disable the competing plugin only if it genuinely duplicates the MCP tool’s job. Keep plugins for organization-specific or mission-critical workflows.
The assistant cannot distinguish between similar tools	Improve the MCP tool description at the source server when you control it. Tool names and descriptions are view-only in Tool Studio.
Enterprise Search wins over a search-style MCP tool	Temporarily disable Enterprise Search in a test environment to confirm the MCP tool works, then re-enable it before broad rollout.

Do not use Enterprise Search disablement as a production strategy

Enterprise Search provides functionality that users may rely on. If an MCP server only works with it off, reduce the overlap between the MCP tools and Enterprise Search instead.

Widen Access

Keep the tested requests, unexpected results, and server or connector changes with the pilot record. Use that evidence to decide whether to widen the Launch Configuration audience, improve the server, or build a plugin instead. Widen the audience only when the assistant uses the MCP tool for the pilot requests and failures are diagnosable.