Add an MCP from a remote URL

If this connection lists call_platform_tool instead of the tools this workflow names, find each named tool with search_platform_tools, describe it with describe_platform_tool, then run it with call_platform_tool and the same arguments. Whether a tool exists for you is decided by describe_platform_tool with its exact name, not by tools/list or one page of search results: a name returned in not_found is unavailable to you, so say so rather than guess. The call itself still checks your access. When execute is also listed, a multi-step read may run in execute with tools.search, tools.describe and tools.call on platform--<tool name> paths. End each execute run at a confirmation point and ask the user before any write.

Use this workflow only through the authenticated Speakeasy AI Control Plane (AICP) Platform MCP when the user supplies a remote MCP server URL that is not in the reviewed MCP Catalogue. It follows the same guarded outcome a user completes in the AICP dashboard: inspect the URL, confirm the bounded evidence and project, register privately, finish secure setup, and verify readiness. For a reviewed catalogue entry, use add-mcp-from-catalog instead. The package itself grants no organization access.

Safety rules

• Never ask the user to paste API keys, passwords, access or refresh tokens, OAuth codes, client secrets, secret headers, or MCP credentials into chat. Authentication and headers are configured only through secure AICP dashboard setup.
• Use inspect_mcp_candidate as the only read-only inspection step for a user-supplied URL. It returns bounded evidence and does not register or distribute anything.
• Keep the target project explicit. Never infer it from a previous conversation or silently substitute another project.
• Before registration, show the user the returned URL, transport, tool count and names, authentication posture, setup requirement, and OAuth-discovery state. State any missing evidence honestly.
• Register only after the user explicitly confirms this exact remote server and project. Registration revalidates and re-inspects the URL; an earlier inspection is never trusted as admission evidence.
• Registration is private. Do not claim the server works until fresh readiness succeeds. Once it does, the person who added it can use it; other people receive it only once it is put into a plugin, which is optional.
• When the project has a Shadow MCP policy that blocks unreviewed servers, the administrator's own distribute_mcp_to_plugin counts as the review: the server is recorded in Shadow MCP as approved for exactly the people that plugin reaches, and the result's shadow_mcp says so with the page where that standing is seen, narrowed, or revoked. Tell the administrator that before they confirm the distribution, and again from the result. Registration itself never consults the policy; nobody else receives the server until it is in a plugin.
• Show non-secret setup and authorization URLs only when a Platform MCP tool returns them.
• Use send_platform_mcp_feedback only after asking for consent, and never include identifiers, URLs, credentials, payloads, headers, logs, or attachments.

Workflow