Limitations and Troubleshooting

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.

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.
Approval policy applies to the server	Set the tool approval policy before enabling write-capable tools.
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	Long-running calls are supported, but the timeout depends on the execution path and upstream server. Test the slowest requests in your pilot.
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.

Timeouts, Progress, and Retries

Long-running calls are supported. A retrieval that takes 120 seconds fits within current platform timeout budgets, but test it with your server before rollout. There is no single maximum timeout for every execution path, and the upstream server can impose a shorter limit. Do not design around unlimited execution time.

Users do not see the server’s MCP progress updates. A call can continue in the background, but this does not provide a stream of partial results to the employee.

Automatic retries cover certain connection failures before a tool call starts. Failed tool calls are not automatically replayed. A resumed SSE connection also does not mean that the tool ran again.

For a slow or failed request:

Open the MCP tool call log and compare its latency and error with the server logs.
If the server timed out, reduce the request scope or improve the server’s response time.
Before manually retrying a write, check whether the upstream action completed.

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.
MCP tool call logs: Open the Logs app to inspect the arguments, model-visible response, execution status, latency, and error for each call. View MCP Tool Call Logs explains the available filters and fields.

MCP tool calls use the format mcp__<server>__<tool>. 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. — Open More info on a response, then select Reveal AI Reasoning.

Reveal AI Reasoning panel showing an MCP tool call with an mcp__ prefix. — Reveal AI Reasoning shows the tool call made for a response, including the mcp__ server and tool name.

Chat Playback page showing a conversation and the plugin selection panel. — Chat Playback lets admins review the conversation alongside available and selected tools.

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.
DCR reports that the server does not support OAuth discovery	The discovery URL or metadata is missing or incorrect	Check the discovery URL, Protected Resource Metadata, authorization-server metadata, `registration_endpoint`, and `S256` PKCE support. The registration endpoint alone is not a discovery URL.
The server worked yesterday but fails now	The provider rejected a token, or token refresh failed	Follow the authentication recovery steps.
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.

Recover from an Authorization Failure

An Authorized status does not prove that the upstream server still accepts the stored token. Moveworks refreshes tokens when needed, but an expired or revoked refresh token requires a new sign-in.

Ask the assistant for a specific task and name the app. If a connect prompt appears, complete sign-in, then repeat the request.
If the connection still fails or no prompt appears, open your Moveworks Connections page. Disconnect the affected integration, then authorize it again.
For an administrator’s failed Preview Tools connection, use Revoke Token, authenticate again, and run Preview Tools.
If authentication still fails, compare the sanitized 401 or 403 error with the provider’s token and permission settings.

Revoking a token or disconnecting an integration removes that authorization. It does not remove the MCP server configuration. Do not delete and recreate a server to recover a user token.

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.
Tools appear in Preview Tools but not in an employee’s conversation	Administrator preview access differs from the employee’s access	Check Enabled, Launch Configuration, the employee’s sign-in, and upstream permissions. Preview Tools validates only the administrator connection.
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.
The assistant never calls any tool from a Custom Server	The server endpoint is entered incorrectly	Open the server in MCP Workspace and check the endpoint. The base URL must not end with a `/`, such as `https://mcp.example.com`, and the Path field must contain the server’s Streamable HTTP path, such as `/mcp`. Correct the values, then run Preview Tools again.

Stage 3: Tool Execution

What you see	Likely cause	What to do
A long-running call fails with a timeout	The platform or upstream server ended the request	Compare the call latency and error with server logs. Follow timeout recovery.
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:

Ask the assistant, “Why didn’t that work?” It can often explain whether sign-in, tool selection, or a tool call failed.
Retry with the app named and the request scoped to the entity, project, field, or date range you need.
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__<server>__<tool> 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 secrets

Do not include access tokens, refresh tokens, credentials, raw employee data, or unredacted upstream responses in an escalation.