Introduction

Webdock MCP is a standards-based remote MCP server.

Webdock MCP URL: https://mcp.webdock.io

If your AI client supports remote MCP, Streamable HTTP and OAuth, there is a good chance it can connect even if Webdock does not yet have a client-specific setup article.

Generic configuration

When your client asks for an MCP server:

• Name: Webdock
• Transport: HTTP / Streamable HTTP
• Server URL: https://mcp.webdock.io
• Authentication: OAuth

Do not append /mcp unless a future Webdock document explicitly tells you to. The Webdock MCP endpoint is the URL above.

A typical connection flow is:

1. Add the remote MCP URL.
2. Start or connect the MCP server.
3. The client discovers Webdock’s OAuth configuration.
4. Your browser opens.
5. Sign in to Webdock.
6. Review and approve the requested permissions.
7. Return to the AI client.
8. Verify that Webdock tools have been discovered.

Minimal JSON example

Clients use different configuration formats, but a remote MCP definition often looks conceptually like:

{
"servers": {
"webdock": {
"type": "http",
"url": "https://mcp.webdock.io"
   }
  }
}

Use your client’s documented format rather than copying this blindly.

Test with read-only prompts first

Try:

Use Webdock to list the available locations and server profiles. Do not create anything.

Then:

Show me my current Webdock servers and summarize their state without making changes.

If these work, authentication, tool discovery and basic reads are functioning.

If OAuth permissions fail later

Some clients support OAuth scope escalation better than others.

If a later task fails because the client does not have the required Webdock permission:

1. disconnect/reconnect the Webdock MCP integration;
2. authorize again;
3. grant the permissions needed for the task.

For clients you intend to use as broad infrastructure operators, it can be simpler to approve the required management permissions during initial setup.

Recommended infrastructure prompts

Prefer native capabilities

Prefer native Webdock MCP operations when an appropriate managed operation exists. Do not automatically replace a failed managed operation with manual shell work unless I ask you to.

Snapshot before risk

Before a major or destructive change, create a Webdock snapshot and verify it completed.

Wait for async work

Wait for each asynchronous Webdock operation to finish successfully before starting a dependent action.

Use the right image

This is a PHP application. Prefer a Webdock LAMP or LEMP image when appropriate instead of assembling the whole web stack manually.

Inspect before provisioning

Before creating anything, inspect available profiles, capabilities, images and human-readable monthly prices. Propose the configuration first.

Model choice matters

For autonomous infrastructure work, use a strong model.

Lightweight models can be useful for read-only inventory questions, but provisioning and server administration require more reliable tool selection, planning and error handling.

When a client does not work

Check that the client supports:

• remote MCP servers;
• Streamable HTTP;
• OAuth for remote MCP.

If it only supports local STDIO MCP servers, or only supports static bearer-token authentication, it may not currently be compatible with Webdock’s normal OAuth setup.

When we publish a client-specific guide, prefer that over this generic article.

Please reach out to Webdock Support if you need assistance.