MCP server

Connect Claude, ChatGPT, Gemini, Cursor or any other AI assistant to the TurboStack documentation, so it answers from the real documentation instead of guessing.

TurboStack MCP connects your artificial intelligence (AI) assistant to this documentation. Instead of answering from whatever it happens to remember about hosting in general, the assistant looks up the real TurboStack documentation - the configuration parameters, the example configurations, the technology and application pages and the REST API - and cites the page it used.

It speaks the Model Context Protocol (MCP), the open standard that AI clients use to reach external tools and data. Any client that supports it can connect.

Endpoint:

https://docs.turbostack.app/mcp

No account, no token, no sign-up.

Important

Connected without a token, this is documentation and nothing else. It explains and looks things up. It cannot change anything on the TurboStack platform or on your server, and it cannot see your hosts, your configuration or your data - it has no access to your account. Applying a change stays your own step, in the TurboStack Platform, the REST API or the CLI.

Why connect it

A general-purpose assistant knows Ansible, Docker and Nginx in general. It does not know how TurboStack names things, and it will confidently invent a configuration key that looks plausible and does not exist. Connected to this server, it can check.

It stops guessing parameters. Ask for a configuration and the assistant looks up each key: its scope (host, system user or application), its type, its default and its valid values.
It starts from a working example. Complete configurations for WordPress, Magento 2, Shopware, Odoo, Laravel, Node.js, several applications on one host, and an application server with a separate database server.
It knows the rules between keys. The mistakes that pass a syntax check and still do nothing - Varnish needing two keys, a runtime enabled by setting its version, Elasticsearch and OpenSearch being mutually exclusive.
It can help you build against the API. Endpoints, parameters, request bodies and responses, including what may go inside a host's configuration body.
Every answer links to the page it came from, so you can check it.

Connect it

Claude Code

claude mcp add --transport http TurboStack https://docs.turbostack.app/mcp

Claude Desktop, Cursor, Windsurf, Zed

Add the server to the client's configuration file:

{
  "mcpServers": {
    "TurboStack": {
      "type": "http",
      "url": "https://docs.turbostack.app/mcp"
    }
  }
}

OpenAI

Pass the server in the tools array of a Responses API call:

{
  "type": "mcp",
  "server_label": "TurboStack",
  "server_url": "https://docs.turbostack.app/mcp",
  "require_approval": "never"
}

Assistants that start a local command

Some clients, including Google Gemini's command-line tool, expect to launch a program and talk to it over its input and output rather than over the network. Use the bridge shipped with the server: it passes everything through to the same endpoint.

{
  "mcpServers": {
    "TurboStack": {
      "command": "node",
      "args": ["/path/to/stdio-bridge.mjs"]
    }
  }
}

The bridge is a single file with no dependencies. Ask Support for it, or open the endpoint in a browser: it returns a description of the server and these connection snippets.

With a TurboStack API token

The endpoint stays the same. A token adds the tools that work on your own hosts - see Working on your own servers for what that covers and what it refuses to do.

Create the token under API tokens in your Profile Settings, then send it as an Authorization: Bearer <token> header. Every client that supports MCP can add one.

Claude Code

claude mcp add --transport http TurboStack https://docs.turbostack.app/mcp \
  --header "Authorization: Bearer <token>"

Claude Desktop, Cursor, Windsurf, Zed

{
  "mcpServers": {
    "TurboStack": {
      "type": "http",
      "url": "https://docs.turbostack.app/mcp",
      "headers": {
        "Authorization": "Bearer <token>"
      }
    }
  }
}

OpenAI

{
  "type": "mcp",
  "server_label": "TurboStack",
  "server_url": "https://docs.turbostack.app/mcp",
  "headers": {
    "Authorization": "Bearer <token>"
  },
  "require_approval": "never"
}

Treat the token like a password: it carries whatever access your account has. Keep it out of shared configuration files and out of anything you commit.

Check that it works

Ask your assistant something only this documentation can answer:

"What does php_fpm_pm_max_children do, and where does it belong in the configuration?"
"Give me a TurboStack configuration for a Magento 2 shop with Redis and Varnish."
"Which technologies does TurboStack support?"
"How do I poll the API until a deployment is finished?"

A connected assistant answers with the parameter's scope, type and default, or with a complete example configuration, and links to the page it used. An assistant that is not connected will answer in general terms and invent key names.

What you can ask it

Without a token, the server answers from the documentation. It is exact where an exact answer exists, and searches only when the question is genuinely prose.

Ask about	What comes back
A configuration key	Scope (host, system user or application), type, default, documented values, what it does, what it requires, what to be careful with
"Which key controls X"	The matching parameters with their scope and purpose
A complete setup	A full working example configuration for the scenario - WordPress, Magento 2, Shopware, Odoo, Laravel, Node.js, several applications on one host, an application server with a separate database server
How keys interact	The rules that connect keys: which one enables a runtime, which needs a second key elsewhere, which combinations exclude each other
The REST API	Endpoints with their parameters, request body and responses
A term	What it means on this platform
What is supported	Every documented technology and application
Anything else	The matching documentation passages with a link to each, or a whole page

Some questions that work well:

"What does php_fpm_pm_max_children do, and where does it belong in the configuration?"
"Give me a TurboStack configuration for a Magento 2 shop with Redis and Varnish."
"Is redis_maxmemory_mb a real parameter?" (it is not, and the answer says what is)
"How do I poll the API until a deployment is finished?"

Working on your own servers

Connect with a TurboStack API token and the same endpoint can also work on the hosts that token can reach. Create a token under API tokens in your Profile Settings, and send it as an Authorization: Bearer <token> header - see With a TurboStack API token for the snippet per client.

Then you can	Notes
List your servers	By name, active ones only, however many pages the platform needs
List your groups and accounts	A group carries settings that the hosts in it inherit
Read a host	Its deploy status, and its configuration when you ask about settings or versions. Shown as YAML, the form a configuration is written in
Check a configuration before using it	Parses your YAML and checks every key: does it exist, is it in the right place, is the type right, which rules apply
See exactly what a change would do	A difference against the live host. Writes nothing
Save a change	Reads the host, applies your change to the whole configuration, writes it back. Saving does not deploy
Publish a host	Applies the saved configuration to the server

The platform address is https://my.turbostack.app.

Warning

This part changes live servers, and those changes are yours. An assistant can be wrong, and a configuration change can take a site offline. Read the difference it shows you before you agree to anything, keep a normal deploy as the default, and contact Support when something is unclear - do not let an assistant try another approach instead.

How it protects you:

A key that does not exist is refused. Your YAML is checked against the documented parameters first. An unknown key stops the whole change and the answer names the parameters that do exist.
Nothing is saved without showing the difference first, and the save has to quote a code that belongs to exactly that difference.
A normal deploy is the default. A full deploy happens only if you ask for one, and a full delete deploy - which removes resources and their data - needs a separate confirmation.
Nothing is removed that you did not ask to remove. Your change is merged into the configuration that is already there.

Two things have to be true for any of this. You have to send a token, and the server has to have the platform integration switched on. Hosted Power can switch it off, in which case the endpoint serves the documentation only and no token changes that. If the tools do not appear in your client, that is the first thing to check.

Good to know

It answers from a snapshot. The server carries the documentation as published, refreshed with every documentation release. Version numbers and the option lists behind the dropdowns are maintained in the TurboStack Platform, so treat an exact version in an answer as "documented at the time" and confirm it in the interface before you rely on it. Ask the assistant what its snapshot date is and it will tell you.

It is rate limited. A generous limit per address, enough for interactive use. An assistant that hammers it in a loop will be slowed down, not banned.

It only knows what is published here. Nothing about your hosts, your traffic or your invoices. For those, use the TurboStack Platform, the REST API or Support.