What the MCP server is and why to use it

Your AI coding assistant already generates code and infrastructure config. The Quake AI MCP server gives that assistant a way to pull current, accurate Quake AI data while it works: documentation pages and compile-checked infrastructure templates. The assistant works from retrieved facts instead of from whatever it absorbed during training.

This page explains what the server is, why you would connect it, what its core tools do, and how an assistant uses them together. For step-by-step setup across Cursor, Claude Desktop, VS Code, Zed, and other tools, see How to connect AI tools to Quake AI docs.

What the MCP server is#

The Model Context Protocol (MCP) is an open standard for connecting AI assistants to external tools and data sources. An MCP-capable assistant calls a server's tools mid-task, reads the results, and folds them into its response.

The Quake AI MCP server is a hosted endpoint at https://docs.quake.ai/api/mcp that implements this protocol. It exposes a set of callable tools. The four you reach for most:

• search_docs retrieves current Quake AI documentation.
• get_template retrieves a curated infrastructure template for a service.
• validate_launch_manifest checks a quake.yaml manifest against the schema, flavor catalog, and template library.
• prepare_launch validates a manifest and returns a launch handoff packet for preview or deploy workflows.

The server also exposes retrieval and export tools such as export_okf (export a linked knowledge bundle in Open Knowledge Format), get_workflow, get_known_issues, get_related, and get_migration_mapping. For the complete tool surface with inputs and return shapes, see the AI tools reference.

The endpoint requires no account and no API key. The doc-retrieval tools read data only, and they serve the same public documentation surface you can browse on this site. The launch tools validate intent only; they do not run builds or deploys. You connect the endpoint once in your tool's configuration, and the assistant calls the tools when a task needs Quake AI specifics.

Why connect it#

An AI assistant generates text from patterns in its training data, which is a fixed snapshot of public text from some point in the past. For a platform the model saw little of, or saw in an older form, it fills the gaps by generating plausible-looking values. That produces wrong API endpoints, flavor names that do not exist, and IaC that fails to parse.

The MCP server closes that gap. When the assistant needs the details of how a Quake AI feature works or wants a starting template, it calls a tool and retrieves the current answer from the live documentation corpus and the template library. The data it returns reflects the same pages this site publishes, regenerated as the docs change.

The read-only endpoint needs no credentials, so there is nothing to provision and no secret to manage. Point your assistant at the URL and the tools become available.

The core tools#

search_docs: retrieve current documentation#

search_docs takes a query and returns ranked Quake AI documentation pages along with their prerequisites, related operations, and known issues. The assistant uses the result as context for whatever it writes next.

Reach for it when the assistant needs the specifics of how Quake AI behaves: which steps a console workflow takes, what a CLI command expects, how a concept like floating IPs or security groups works, or which page documents a given operation. A query phrased in the platform's own vocabulary (floating IP, block volume, flavor) returns the most relevant pages.

get_template: retrieve a validated infrastructure template#

get_template takes a service slug and returns a curated OpenTofu HCL or Heat HOT template for that service. The tool retrieves an existing template from the library; it does not synthesize new HCL, so what you get back is a reviewed starting point rather than freshly generated config.

Reach for it when the assistant is about to write infrastructure code for a Quake AI service and you want it to start from a template that already matches the platform's provider and resource names.

What "validated" means here#

Each template in the library passes tofu validate in continuous integration. That check confirms the template is syntactically valid and configures Quake AI's OpenStack provider correctly. The template parses, and its resource definitions are well-formed against the provider schema.

"Validated" does not mean anyone ran the template against the live platform. It does not guarantee that a specific tofu apply in your project succeeds, because that depends on your quotas, image availability, network setup, and the values you supply. Treat a retrieved template as a correct, well-formed foundation to adapt, and verify the plan before you apply it.

validate_launch_manifest: check a launch manifest#

validate_launch_manifest takes a parsed quake.yaml manifest (as JSON) and returns structured errors and warnings: schema rules, flavor alias resolution, and service-to-template mapping. The assistant uses it before a preview or deploy handoff to catch invalid manifests early.

Reach for it when the assistant is about to call prepare_launch or when you want a fast sanity check on a manifest without generating a handoff packet. For field definitions, see the quake.yaml reference.

prepare_launch: emit a launch handoff packet#

prepare_launch validates the manifest, then returns a downloadable launch handoff packet with a request id, resolved environment and templates, an evidence stub, and manual next steps. The platform validates intent only; it does not run builds or deploys.

Reach for it when you want a structured handoff for a preview or deploy action (preview, deploy, promote, or rollback). If validation fails, the response carries the same error list as validate_launch_manifest with no handoff packet.

A worked example#

Suppose you ask your assistant to stand up a VM on a new private network in Quake AI using OpenTofu. With the MCP server connected, the assistant works through two tools:

1. Retrieve the documentation. The assistant calls search_docs with a query like private network VM OpenTofu. The result returns the relevant pages: how private networks attach to instances, which prerequisites the workflow needs (a network, a subnet, a router, a security group), and the related operations. The assistant now has the platform's actual model in front of it.
2. Retrieve a template. The assistant calls get_template for the compute or network service and gets back a validated OpenTofu template that provisions instances and networking with Quake AI's provider already configured.
3. Adapt and present. The assistant fills the template with your specifics (image, flavor, network name, security group rules) and explains the result using the documentation it retrieved.

The generated configuration uses real Quake AI resource names and starts from a template that already parses, so you spend your time reviewing a plan rather than correcting invented endpoints and flavor names.

Where to go next#

• How to connect AI tools to Quake AI docs: per-tool setup for Cursor, Claude Desktop, Claude Code, VS Code, Continue, Zed, and tools without MCP support.
• AI tools reference: tool inputs, return shapes, no-match behavior, the response envelope, JSON-RPC, and the knowledge-graph.json schema.
• AI tool rules starter for Quake AI projects: an AGENTS.md plus per-tool adapter files that ground your assistant on Quake AI conventions.