> This page is for Tools. > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.moveworks.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.moveworks.com/_mcp/server. # 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](https://community.moveworks.com/p/mcp-workspace-controlled-availability). 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. 1. [Choose a server](#choose-what-to-pilot) for an app or use case you do not already cover, and review the tools it exposes. 2. [Set a small pilot audience](#set-the-pilot-audience) in Launch Configuration. 3. [Test the requests](#test-with-real-requests) that users need to complete. 4. [Confirm that the assistant uses the MCP tool](#check-which-tool-ran), then [widen access](#widen-access) when failures are diagnosable. Start after you [connect the server](/tool-studio/mcp-workspace/connect-a-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. ```mermaid flowchart TB Request["User request"] --> Choice{"Does one tool clearly fit?"} Choice -->|Yes| MCP["MCP tool"] Choice -->|No| Overlap["Tool overlap"] Overlap --> Plugin["Tool Studio plugin"] Overlap --> Search["Enterprise Search"] Overlap --> MCP NewUseCase["New app or use case"] -->|reduces| Overlap ``` 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](/tool-studio/mcp-workspace/connect-a-server#publish-the-server), two settings control who can use it. The **Enabled** toggle turns an MCP server on or off. [Launch Configuration](/platform-management/access-control/end-user-access-control/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.](/_fern-img/907c8c48357e5318c7146cb4629b7122752090f4869005b2614d483afba402a0.webp) 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.](/_fern-img/badfb834b93c0380125664d9445f0f377800b5b42e6720efe9270666ad16481f.webp) 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](/tool-studio/mcp-workspace/troubleshooting#recover-from-an-authorization-failure). ## 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](/tool-studio/mcp-workspace/troubleshooting#recover-from-an-authorization-failure). | | 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](/tool-studio/mcp-workspace/requirements-and-limits#timeouts-progress-and-retries) 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____`. If the assistant selects a plugin or Enterprise Search instead, you have a tool-selection issue. See [Use Temporary Testing Levers Carefully](#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](/tool-studio/mcp-workspace/troubleshooting#find-the-mcp-tool-call-log) and work through [Troubleshooting](/tool-studio/mcp-workspace/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](/tool-studio/why-plugins) instead. Widen the audience only when the assistant uses the MCP tool for the pilot requests and failures are diagnosable.