Configure and Test MCP Workspace

Reduce tool overlap, test real requests, and expand access with evidence.

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.

Why Tool Selection Matters

Tool selection is the main reliability risk during Controlled Availability. For each request, the assistant chooses from the MCP servers, Agent 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.

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 Agent 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 you need to keep it off for an MCP server to work in production, reduce the overlap or raise the issue with your Moveworks team.

When you need more routing help

If routing still misbehaves after you reduce overlap and improve tool descriptions, ask your Moveworks team for custom routing instructions.

Test with Real Requests

Before the pilot, ask each user to complete first-time authentication when prompted. Connect and Manage Servers explains that in-chat sign-in flow.

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.

Review What the Assistant Did

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. If it selects the expected MCP tool but the result is wrong or the call fails, use Limitations and Troubleshooting to find the failed stage.

Recommended Starting Configuration

Choose a server for an app or use case you do not already cover.
Preview its tools and review what it exposes before enabling it.
Scope the server to a small pilot audience in Launch Configuration.
Test the requests that users need to complete.
Confirm the MCP tool is used, then widen the audience only when failures are diagnosable.

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.