> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://help.moveworks.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://help.moveworks.com/_mcp/server. # Limitations and Troubleshooting 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). This page first describes the current boundaries of MCP Workspace, then walks through the four stages of a failed request. ## Current Limitations | Limitation | What it means | | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Universal Assistant only | MCP tools run in the Universal Assistant. Specialized Assistant support is not available during Controlled Availability. | | Governance is server-level | You can enable, disable, and control access to a server, not individual tools within it. | | No confirmation gate for writes | The assistant can run a write without asking for confirmation. Start with read and lookup use cases, and review any server that exposes destructive actions. | | No automatic action chaining across MCP servers | Name the apps and each intended step. The assistant does not automatically compose a complex cross-app workflow from a vague goal. | | Long-running tools can time out | Tool calls run synchronously and can time out at roughly 60 seconds. Keep tools and requests bounded. | | Tool descriptions control routing quality | Tool names and descriptions come from the server. You cannot edit them in Agent Studio, so improve them at the source when you can. | | Servers are added manually | MCP Workspace does not sync a catalog from an MCP registry or aggregator. | | Tools only | Resources, Prompts, and Sampling are not supported. Moveworks connects to remote MCP servers, not local servers. | During Controlled Availability, design the normal response path to finish within 15 to 20 seconds. The runtime can time out at roughly 60 seconds, so a faster baseline leaves room for slower P90 and P99 responses without reaching that boundary. ## Check What the Assistant Did Start by identifying whether the assistant selected the expected MCP tool and what happened next. * **Reveal AI Reasoning**: In the assistant, open **More info > Reveal AI Reasoning** on a response. This is the fastest first check for a user. * **Chat Playback**: Admins can review the available and selected tools for a conversation. A conversation can take roughly 10 minutes to appear. * **Agent Studio logs**: MCP call details are not available at the start of Controlled Availability. Support for the full request, response, and error for each call is planned during Controlled Availability. MCP tool calls use the format `mcp____`. If you expected that prefix but see a plugin or `Enterprise_Search` instead, focus on tool selection. Assistant response with the More info button highlighted. Reveal AI Reasoning panel showing an MCP tool call with an mcp__ prefix. Chat Playback page showing a conversation and the plugin selection panel. ## Work Through the Four Stages Work through these stages in order. The first one that fails is where to focus. ### Stage 1: Connection and Authentication | What you see | Likely cause | What to do | | ----------------------------------------------------------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------- | | Error adding or authenticating a server, or you cannot generate a token | The source app's OAuth configuration is wrong | Follow the source app's OAuth guidance, then run **Preview Tools** again. | | The server worked yesterday but fails now | An access token expired or a refresh token was revoked | Re-authenticate or reconnect the server. | | The server works for some users but not others | The affected users have not completed first-time in-chat authentication | Have each affected user sign in when the assistant prompts them. | ### Stage 2: Tool Discovery and Selection | What you see | Likely cause | What to do | | --------------------------------------------------------------- | -------------------------------------------------- | ------------------------------------------------------------------------------------- | | A plugin runs instead of the MCP tool | Another tool can plausibly handle the same request | Reduce the overlap. In the moment, have the user name the app, such as "in Linear." | | The assistant calls Enterprise Search, gets nothing, then stops | It stopped before trying the more specific server | Have the user name the app explicitly in the request. | | The expected tool never appears as an option | The tool description is too vague to match | Improve the description at the source app or server. It is view-only in Agent Studio. | ### Stage 3: Tool Execution | What you see | Likely cause | What to do | | -------------------------------------------------------- | ------------------------------------------------ | ----------------------------------------------------------------------------- | | A long-running call fails after roughly 60 seconds | The tool exceeded the synchronous timeout | Try a narrower request or a more focused tool. | | The answer is truncated or degraded after a large result | The tool returned too much data | Scope the request more narrowly. | | Failures are intermittent and cluster under load | The upstream server is rate-limiting the call | Wait and retry. Check the upstream service for rate limits or errors. | | The tool returns something unexpected | The assistant sent wrong or incomplete arguments | Rephrase the request with the entity, project, field, or date range you need. | ### Stage 4: Response Quality | What you see | Likely cause | What to do | | ------------------------------------------------------ | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------- | | A plausible but wrong result | A broad tool returned data that was not scoped to the right item | Name the entity, project, field, or date range in the request. | | The result is technically right but poorly shaped | The response format is not tuned for the request | Rephrase with the format or level of detail you need. | | The same request returns different results across runs | The behavior is non-deterministic | Capture examples and escalate. There is no self-service configuration for this today. | ## Retry Before You Escalate Before you escalate, try the recovery step that matches the failed stage: 1. Ask the assistant, "Why didn't that work?" It can often explain whether sign-in, tool selection, or a tool call failed. 2. Retry with the app named and the request scoped to the entity, project, field, or date range you need. 3. If the server works for others but not the affected user, have that user complete the in-chat sign-in flow. ## Escalate with Useful Evidence If you identify the failed stage and do not have a self-service fix, include the following in your escalation: * Conversation URL or ID and the approximate timestamp with timezone. * The failed stage and the exact request. * The affected app and expected `mcp____` name, when known. * Expected and actual behavior. * A screenshot of Reveal AI Reasoning and, when available, Chat Playback. * The user-facing error text and safe server-side correlation details, such as a request ID, HTTP status, or stable error code. * Whether the issue reproduces, the affected pilot group, and any recent connector, server, or tool-description change. Do not include access tokens, refresh tokens, credentials, raw employee data, or unredacted upstream responses in an escalation.