Remote MCP Apps

Remote MCP apps connect Studio to a remote Model Context Protocol (MCP) server and turn the tools that server exposes into governed Studio tools. Once an app is connected and its tools are discovered, Actions can call those tools from Agent steps, Tool Call steps, and Code steps — under the same admin-gated perimeter as every other tool in the tenant.

For a general overview of all app types, see Tenant Admin > Apps.

What a Remote MCP App Provides

A Remote MCP app contributes exactly one kind of resource to Actions:

• Tools — the operations the connected MCP server exposes. They are callable from inside an Agent step (the LLM may choose to call them), from a Tool Call step (you invoke them deterministically), and from a Code step (via executeTool).

Unlike most other app types, a Remote MCP app provides:

• No triggers. A Remote MCP app cannot start an Action. Pair it with another trigger source — Manual, Scheduled, Dooap, an Exchange or Azure Storage trigger, or an OpenAPI webhook.
• No inputs. There are no deterministic data-fetch inputs. Everything the server offers is surfaced as a tool.

The available tools are whatever the server exposes — Studio does not define them. They appear on the app's Tools tab, each tagged with an MCP badge.

Supported Transport and Protocol

• Transport: Studio connects over Streamable HTTP, with automatic fallback to Server-Sent Events (SSE) for servers that only support the older HTTP+SSE transport. Studio negotiates the transport for you; there is nothing to configure beyond the server URL.
• Surface: Studio uses the MCP tools capability only — it lists tools (tools/list) and calls them (tools/call).
• Not supported: MCP resources, prompts, and sampling are not used. Stdio (local process) servers are not supported, because Remote MCP connects to a network endpoint.

Creating a Remote MCP App

1. Go to Tenant Admin > Apps.
2. Select New, choose Remote MCP, and continue.
3. Enter a clear, descriptive Name, for example IBISWorld MCP or Microsoft Learn MCP.
4. Optionally add a Description.
5. Enter the MCP server URL — the HTTP(S) endpoint of the remote MCP server, for example https://learn.microsoft.com/api/mcp. The URL must be an absolute http:// or https:// URL. Select What is this? next to the field for inline help.
6. Save the app.

When you save, Studio attempts an initial tool discovery against the server. If the server needs credentials before it will list its tools, discovery may return nothing until you configure authentication — see below.

After saving, open the app to configure credentials and refresh the tool list.

Authentication

Open the app and select Configure Credentials, then choose the scheme that matches the target server:

• None — public servers that require no credentials. This is the default for a new Remote MCP app.
• API Key — a single shared key. By default Studio sends it as an Authorization: Bearer <key> header. To send it under a different header instead, fill in Header Name (for example X-API-Key); when a custom header name is set, the key is sent verbatim with no Bearer prefix.
• OAuth 2.1 (Interactive) — an interactive Authorization Code flow with PKCE. Selecting this and saving starts a browser sign-in against the server's authorization server. Studio supports Dynamic Client Registration, so for most servers you do not need to pre-register a client; if the server issued you a confidential client secret, you can supply it. After you sign in, Studio stores the resulting token set and uses it as Authorization: Bearer <token> on every call.

Credentials are stored encrypted in the tenant's secret vault, on the app — never on individual Actions, steps, or prompts. To rotate or change them, reopen Configure Credentials, update the values, and save.

For interactive OAuth, the access token can expire. When it does, the next tool call or tool refresh fails with a re-authentication error; reconnect the app through Configure Credentials to sign in again and refresh the stored token.

Tool Discovery and Sync

Studio discovers tools by connecting to the server and asking it to list them. Discovery runs automatically when you create the app and when you change the server URL, and on demand when you select Refresh tools on the app's General tab.

Use Refresh tools after you configure or change authentication, since many servers will not list their tools until the request is authenticated. After a successful refresh, the discovered tools appear on the Tools tab, and the tab count updates.

When you refresh, Studio reconciles the server's current tools with what it already has:

• Added — a tool the server now offers that Studio did not have is created.
• Updated — a tool whose description or input schema changed on the server is updated, and a new tool version is recorded.
• Removed — a tool the server no longer offers is deleted only if it is not assigned to any step. If a removed tool is still used by a step, Studio keeps it so the Action does not silently break, and records a warning. Remove the tool from the step, then refresh again to clear it.

Tools are matched by name. If a server renames a tool, Studio sees that as one tool removed and a different tool added — the new name appears, and the old name is kept if it is still assigned to a step.

There is no background polling. Tool lists change only on create, on a server-URL change, or when you select Refresh tools.

Governance

MCP tools live under the same admin-gated perimeter as every other tool in Studio. Discovering a tool does not automatically expose it to an Action. A tool only runs when an Action author assigns it to a step:

• In an Agent step, the author adds the tool to the step's tool whitelist; only assigned tools are offered to the LLM.
• In a Tool Call step, the author selects the specific tool to invoke.
• In a Code step, the author assigns the tool and calls it by name through executeTool.

Because Remote MCP apps are created and credentialed by Tenant Admins, and tools are only reachable once assigned to a step, third-party MCP tools are governed exactly like first-party ones.

Parameters and Schemas

Each MCP tool carries an input schema published by the server (standard JSON Schema). Studio stores that schema with the tool and uses it in two places:

• Tool Call step — the schema drives the parameter form, with the same field labels, helper text, type chips, and JSON editors used for other tool types. You can chain values into the parameters using {{inputs.…}} and {{StepName.…}} references.
• Agent step — the schema and the tool's description are passed to the LLM as the tool's function signature, so the model knows what arguments to supply.

Because the schema comes straight from the server, the quality of the parameter descriptions an Agent sees depends on how well the server documents its tools.

Output Filters

MCP tool results support the same JSONPath output filter as other tools. When an Agent step calls an MCP tool, you can apply an output filter to the result to narrow large payloads down to just the part the Action needs, keeping later prompts and step outputs focused.

Limitations

• Tools only. MCP resources, prompts, and sampling are not supported.
• Result content. Studio reads text content and structured (JSON) content from a tool result. Other content types, such as images or embedded binary resources, are not specially handled.
• No streaming of results. A tool call returns a single result; partial/streamed tool output is not surfaced incrementally.
• No fixed timeout or payload cap is configured by Studio for MCP calls; a call is bound by the overall step/run cancellation. A slow or very large server response is therefore governed by the run, not by an MCP-specific limit.
• A fresh connection per call. Studio connects to the server for each discovery and each tool call rather than holding a long-lived session.

Security Considerations

• Trust the server. Connecting a Remote MCP app lets its tools run inside your Actions with whatever credentials you configure. Only connect servers you trust, and review the tools the server exposes after each refresh.
• What is logged. For each tool call, Studio logs the tool name, the server URL, and the number of arguments passed — not the argument values — plus success or failure. Tool results are recorded in the step output and the run's tool-call record, where they are visible in execution logs and used by evaluations. Avoid sending secrets as tool arguments you would not want to appear in results.
• Credential masking. API keys and bearer tokens are held in the secret vault and are masked in run logs.
• Unauthenticated fallback. If a tool runs without configured credentials, Studio calls the server unauthenticated and records that it did so. Configure credentials for any server that should not be called anonymously.

Troubleshooting

• Refresh tools returns nothing / connection error. Verify the MCP server URL is the server's MCP endpoint (not its marketing or docs page) and is reachable over HTTPS. Confirm credentials are configured if the server requires them, then refresh again.
• 401 / authentication errors. Re-open Configure Credentials. For API Key, check the key and, if the server expects a non-standard header, the Header Name. For OAuth 2.1, reconnect to refresh an expired token.
• A tool disappeared or its parameters changed. The server changed its tool set. Select Refresh tools to sync. If a tool you still use was removed on the server, Studio keeps it but warns — update the step that uses it.
• Agent ignores a tool or fills parameters wrong. The Agent relies on the server's tool description and parameter schema. If they are sparse, the model has little to go on; prefer servers with well-documented tools, and use clear step instructions.

Worked Example: Connect IBISWorld MCP

This example connects the IBISWorld industry-research MCP server and uses one of its tools from an Agent step. It assumes you have an IBISWorld membership that grants MCP access.

1. Create the app. Go to Tenant Admin > Apps, select New, choose Remote MCP, and continue. Name it IBISWorld MCP, set the MCP server URL to https://mcp.ibisworld.com, and save.
2. Configure authentication. Open the app and select Configure Credentials. IBISWorld signs you in interactively, so choose OAuth 2.1 (Interactive) and save, then complete the sign-in with your IBISWorld account. Studio stores the token.
3. Discover the tools. Back on the app's General tab, select Refresh tools. The server's tools appear on the Tools tab. Open a tool to review its description and parameters.
4. Assign a tool to an Agent step. In an Action, open an Agent step, go to its Tools section, and add one of the IBISWorld tools (it shows an MCP badge). Write step instructions that tell the Agent when to use it.
5. Run the Action. Trigger the Action. When the Agent decides the tool is relevant, it calls the IBISWorld MCP server with the arguments it chose, and the result flows into the Agent's reasoning. Open the run to see the tool call recorded in the step output.

If the run later fails with an authentication error, the OAuth token has expired — reconnect through Configure Credentials and run again.

Things to Know

• Remote MCP apps provide tools only — no triggers and no inputs. Pair them with a separate trigger.
• Tool lists are not polled. They update on create, on a server-URL change, and when you select Refresh tools.
• A removed-but-still-assigned tool is kept (with a warning) so Actions do not break; clean it up by removing it from the step and refreshing.
• Credentials live in the secret vault on the app and are masked in logs; rotate them through Configure Credentials.
• Per-call logs record the tool name, server URL, and argument count — not argument values; results land in step output and the run's tool-call record.

---