Draftt MCP Server

Connect AI agents to your cloud infrastructure lifecycle data through the Model Context Protocol.

Draftt is the unified control plane for proactive tech stack governance. It provides 360° visibility into every component across your cloud estate -- from databases and serverless functions to Kubernetes clusters and container images -- tracking version drift, end-of-life risk, compliance posture, and upgrade planning across AWS, GCP, and Azure. This MCP server connects AI agents directly to the Draftt API, letting you query, analyze, and plan infrastructure upgrades through natural language. All tools are read-only except draftt_policy_create and draftt_policy_create_batch, which create governance policies inside Draftt.

Features and Use Cases

• Inventory your entire cloud estate -- Search and inspect databases, Kubernetes clusters, serverless functions, container images, and every other tracked component across AWS, GCP, and Azure.
• Assess compliance and EOL risk -- Surface which components are past end-of-life or drifting from the latest stable version, with urgency scores and smart prioritization.
• Plan Kubernetes upgrades end-to-end -- Get structured upgrade guides covering control plane, nodes, deprecated APIs, and application-level changes, then inventory every container image and Helm chart running in the cluster.
• Quantify extended support costs -- See the financial impact of running past-EOL components on vendor extended support and prioritize remediation by urgency, effort, and business impact.
• Author governance policies from plain English -- Turn a requirement like "all RDS instances must have storage encryption enabled" into a real Draftt policy, with detail fields discovered from the live API schema so rules never reference invented fields.
• Guided workflows via prompt templates -- Use pre-built prompts for compliance reports, K8s upgrade plans, policy creation, and EOL risk assessments that orchestrate multi-tool workflows automatically.

Quick Start

1. Get a Draftt API key at draftt.io

2. Run the server with npx:

npx -y @draftt-io/draftt-mcp --access-key YOUR_ACCESS_KEY

3. Connect from Claude Desktop -- add the following to your Claude Desktop configuration file:

{
  "mcpServers": {
    "draftt": {
      "command": "npx",
      "args": ["-y", "@draftt-io/draftt-mcp", "--access-key", "YOUR_ACCESS_KEY"]
    }
  }
}

Prerequisites

• Node.js 20.0.0 or later (download)

Installation

Add the following to your Claude Desktop config file.

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "draftt": {
      "command": "npx",
      "args": ["-y", "@draftt-io/draftt-mcp", "--access-key", "YOUR_ACCESS_KEY"]
    }
  }
}

Alternatively, use an environment variable for the API key:

{
  "mcpServers": {
    "draftt": {
      "command": "npx",
      "args": ["-y", "@draftt-io/draftt-mcp"],
      "env": {
        "DRAFTT_ACCESS_KEY": "YOUR_ACCESS_KEY"
      }
    }
  }
}

Add to your VS Code settings.json or workspace .vscode/settings.json:

{
  "mcp": {
    "servers": {
      "draftt": {
        "command": "npx",
        "args": ["-y", "@draftt-io/draftt-mcp", "--access-key", "YOUR_ACCESS_KEY"]
      }
    }
  }
}

Add to your Cursor MCP configuration file (.cursor/mcp.json):

{
  "mcpServers": {
    "draftt": {
      "command": "npx",
      "args": ["-y", "@draftt-io/draftt-mcp", "--access-key", "YOUR_ACCESS_KEY"]
    }
  }
}

claude mcp add draftt -- npx -y @draftt-io/draftt-mcp --access-key YOUR_ACCESS_KEY

Add to your Kiro MCP configuration file (.kiro/settings/mcp.json).

{
  "mcpServers": {
    "draftt": {
      "command": "npx",
      "args": ["-y", "@draftt-io/draftt-mcp", "--access-key", "YOUR_ACCESS_KEY"]
    }
  }
}

For remote clients, start the stateless Streamable HTTP transport:

DRAFTT_ACCESS_KEY=YOUR_ACCESS_KEY npm run start:http

The server listens on 127.0.0.1:3000 (set DRAFTT_MCP_BIND_ADDRESS and PORT to change it) and serves:

• POST /mcp: MCP requests. Each request is handled on its own; there are no sessions, so a GET or DELETE /mcp that passes the checks below answers 405.
• GET /health: answers {"status":"ok"} without any check, for load balancer and Kubernetes probes.

Binding to a non-loopback address, or setting DRAFTT_MCP_PUBLIC_URL to a non-loopback host (for example a tunnel to a loopback bind), requires DRAFTT_MCP_SHARED_SECRET; without it the server refuses to start. When the secret is set, a /mcp request that passes the Host and Origin checks must send it in the x-api-key header, or gets 401 (a CORS preflight from a listed origin is answered 204 without it):

curl -X POST http://127.0.0.1:3000/mcp \
  -H 'x-api-key: YOUR_SHARED_SECRET' \
  -H 'content-type: application/json' \
  -H 'accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Before the key is checked, a request whose Host is not the DRAFTT_MCP_PUBLIC_URL host (or a loopback name when it is unset) gets 403, and so does one whose browser Origin hostname is not listed in ALLOWED_ORIGINS (scheme and port are not compared).

Run a single instance. Pending confirmations (their tokens and the key that signs prompt state) live in the server process, so another replica cannot redeem them; a restart invalidates them, and the agent asks again.

Upgrading from 1.7: sessions are gone, the server binds to loopback by default, no browser origin is accepted unless listed, and /health no longer reports a session count.

Configuration

| Name | Required | Default | Description | |------|----------|---------|-------------| | DRAFTT_ACCESS_KEY | Yes | -- | API authentication key. Also available as --access-key CLI flag. | | DRAFTT_API_BASE_URL | No | https://api.draftt.io/v1 | Draftt API base URL. | | PORT | No | 3000 | HTTP server port (HTTP transport only). | | DRAFTT_MCP_BIND_ADDRESS | No | 127.0.0.1 | Address the HTTP server listens on. A non-loopback bind requires DRAFTT_MCP_SHARED_SECRET, and without DRAFTT_MCP_PUBLIC_URL it answers 403 on /mcp to every non-loopback Host (HTTP transport only). The container image sets 0.0.0.0 and PORT=3000, so it needs DRAFTT_MCP_SHARED_SECRET. | | DRAFTT_MCP_SHARED_SECRET | For a non-loopback bind | -- | At least 32 characters. Clients send it in the x-api-key header (HTTP transport only). | | DRAFTT_MCP_PUBLIC_URL | No | -- | Public URL of /mcp, e.g. https://mcp.example.com/mcp. Only its host is accepted in the Host header. A non-loopback value requires DRAFTT_MCP_SHARED_SECRET, which covers a tunnel to a loopback bind (HTTP transport only). | | ALLOWED_ORIGINS | No | none (browser origins rejected) | Comma-separated list of allowed CORS origins, e.g. https://app.example.com, matched by hostname only (HTTP transport only). | | DRAFTT_CONSOLE_URL | No | https://app.draftt.io | Draftt console URL, used for the links in the overview tools' results. | | DEBUG | No | false | Enable verbose debug logging. Also available as --debug CLI flag. | | DRAFTT_ALLOW_UNCONFIRMED_CREATE | No | false | Bypass the confirmation flow entirely for all clients, allowing draftt_policy_create and draftt_policy_create_batch to run without user approval. See Creating Policies. |

Over stdio the server reads configuration from its flags and from the environment the client passes (the env block of the client's server entry). From a .env file in the directory the client starts the server in, it takes only DRAFTT_ACCESS_KEY, and only when neither the flag nor the environment gives one.

Upgrading from 1.7 over stdio: only the access key is still read from a .env file, so any other setting kept there (for example DRAFTT_API_BASE_URL or DEBUG) must move to the client's env block; a confirmation prompt that times out now returns a confirmation token instead of CONFIRMATION_FAILED; and a client that speaks the 2026-07-28 protocol revision is now served on it, so its confirmation prompt comes back with the tool result and the client sends the answer in a new call (see User confirmation).

Available Tools

Overviews

Each of these answers a common question in one call. A host that draws MCP Apps (claude.ai, for example) shows the result as a card; every other host gets the same answer as text and structured content.

| Tool | Description | Key Parameters | |------|-------------|----------------| | draftt_cluster_support_overview | Which Kubernetes clusters (EKS, AKS, GKE) are past end of support or about to lose it, from the End Of Life policy. Returns the counts, the next end-of-support deadlines and the most urgent clusters. Pass focus to call out one cluster by name, with its upgrade plan when it has one. | windowDays, focus | | draftt_technology_overview | The number of components per technology across the whole inventory, counted live. | none | | draftt_component_overview | All components of one technology, optionally in one environment: the live count, the split by version and by region, and the first components by name. environment is the value of the environment tag; production matches production and prod, any other value is matched with exact casing. | technology, environment |

Component Management

| Tool | Description | Key Parameters | |------|-------------|----------------| | draftt_component_query | Query cloud infrastructure components with DrafttQL ($eq, $ne, $gt, $lt, $in, $nin, $and, $or). Filter by tags with tags$.<tagKey> / customTags$.<tagKey> keys in filter. Supports field selection, sorting, and cursor pagination up to 1,000 results. | filter, select, sort, pageSize, cursor | | draftt_component_get | Get full details for a single component by numeric ID, including version, region, ARN, and tags. | componentId | | draftt_component_details_schema | Discover the queryable details$. fields for a technology (or technology group), with each field's path, display name, type, and enum availableValues. Detail fields are not listed in any resource -- call this before creating a component policy that checks details. | technology |

Policy and Compliance

| Tool | Description | Key Parameters | |------|-------------|----------------| | draftt_policy_query | Query compliance policies with DrafttQL filtering, field selection, sorting, and cursor pagination. EOL policies flag end-of-life; L&G policies track latest version. | filter, select, sort, pageSize, cursor | | draftt_policy_get | Get full details for a single policy by numeric ID. | policyId | | draftt_policy_create | Write operation -- always requires user confirmation. Create a policy that evaluates resources for compliance. Supports resources component, certificate and types governance, lifecycle. Every referenced details$. field is verified against the live API schema; the create is rejected if a field does not exist. See Creating Policies. | name, description, type, resource, query.filter, statusDefinitions | | draftt_policy_create_batch | Write operation -- always requires user confirmation, once for the whole batch. Create several policies in one call; each element follows the draftt_policy_create schema and is validated the same way. If any policy fails validation, none is created. After confirmation the policies are created one at a time, and the result reports each one's success or error; a policy created before a later one fails is not rolled back. See Creating Policies. | policies (at least one) | | draftt_policy_component_get | Get compliance evaluation of one component against one policy -- compliance status, version gap (current vs required/recommended version), urgency, priority, and due date. | policyId, componentId | | draftt_policy_component_query | Query all component compliance evaluations within a policy. Supports filtering, field selection, sorting, tag filtering, and pagination up to 1,000. | policyId, filter, tagFilters, select, sort, pageSize |

Upgrade Plans

| Tool | Description | Key Parameters | |------|-------------|----------------| | draftt_query | Query upgrade plans (draftts) across the organization. Returns active and completed plans with component ID, technology, current/desired versions, and status. For one component's detailed guide, use draftt_upgrade_guide_get. | filter, select, sort, pageSize, cursor |

Kubernetes

| Tool | Description | Key Parameters | |------|-------------|----------------| | draftt_upgrade_guide_get | Get the active K8s cluster upgrade plan, covering APIs, workloads, nodes, and the control plane. Supports both new and legacy cluster agents. Omit sections to retrieve the full guide. Requires an active plan. | componentId, sections | | draftt_k8s_resource_query | Query resources collected by new cluster agents, including workloads, nodes, CRDs, ConfigMaps, and Secrets. Returns configuration, namespaces, image details, and Helm/ArgoCD/Flux management information. Supports filtering, field selection, sorting, and pagination. | componentId, filter, select, sort, pageSize, pageToken | | draftt_policy_k8s_resource_query | Query Kubernetes compatibility findings for new cluster agents. Returns workload, image, node, API, and CRD findings, with optional related resource details. Distinguishes current-cluster status from next-version compatibility. | componentId, filter, k8sResourceData, select, sort, pageSize, pageToken | | draftt_policy_k8s_component_query | Legacy — planned for deprecation. Query workload compliance for legacy cluster agents. Returns image versions, required actions, warnings, Helm/ArgoCD management, and chart upgrade data. Filter by componentId to scope to a cluster. | filter, k8sCatalogComponentData, select, sort, pageSize, pageToken | | draftt_k8s_api_query | Legacy — planned for deprecation. Query API and CRD compatibility for legacy cluster agents. Returns current/desired API versions, CRD ownership and management, and deprecated resource instances with migration details. | componentId, filter, select, sort, pageSize, pageToken | | draftt_k8s_node_query | Legacy — planned for deprecation. Query nodes for legacy cluster agents. Returns kubelet versions, OS images, node groups, management and runtime information, and upgrade warnings. | componentId, filter, select, sort, pageSize, pageToken |

Resources

| Name | URI | Description | |------|-----|-------------| | API Configuration | draftt://config/api | Current API endpoint configuration and available routes. | | Supported Technologies | draftt://config/technologies | Reference data for technologies, component types, and cloud regions (not exhaustive). | | Domain Glossary | draftt://guide/concepts | Definitions of key Draftt concepts: components, policies, compliance, DrafttQL. | | Common Workflows | draftt://guide/workflows | Step-by-step guides for component discovery, compliance assessment, K8s upgrade planning, and EOL analysis. | | Component Policy Filter Fields | draftt://policy/fields/component | Base (top-level) filter fields for component policies, with types and valid operators. Does not enumerate details$. fields -- discover those with draftt_component_details_schema. | | Certificate Policy Filter Fields | draftt://policy/fields/certificate | All filter fields available for certificate policies. Read before creating a certificate policy. | | DrafttQL Policy Operators | draftt://policy/operators | Complete operator reference for policy filter conditions, including syntax rules, relative date tokens, and common patterns. | | Component Details | draftt://components/{id} | Dynamic template: full details for a specific component by ID. | | Policy Details | draftt://policies/{id} | Dynamic template: full details for a specific policy by ID. | | Draftt Overview Card | ui://draftt/cluster-support-<hash>.html | The MCP App card that shows the results of the overview tools. The hash changes with every build of the card. |

Prompt Templates

| Name | Description | Arguments | |------|-------------|-----------| | compliance-report | Generate a compliance report for a policy. Summarizes compliant vs. non-compliant counts, highlights highest-urgency items, and recommends remediation priorities. | policyId (required), focusTechnology (optional) | | k8s-upgrade-plan | Kubernetes upgrade planning workflow. Discovers the cluster, retrieves the upgrade guide, explores the user's code repo for deployment configs, and produces a concrete implementation plan with file paths, commands, and per-task risk/effort notes. | componentId (optional), clusterName (optional) | | policy-creation | Guide for creating a policy from a compliance requirement. Translates natural language into a policy structure with scope, statuses, and filter-based rules, referencing the policy field resources for available fields and operators. | requirement (required), resource (optional), type (optional) | | eol-assessment | Assess end-of-life risk across all components of a technology. Categorizes by urgency, calculates total extended support costs, and recommends upgrade paths. | technology (required) |

Creating Policies

draftt_policy_create and draftt_policy_create_batch are the only write tools. A policy has a scope (which resources it applies to) and status definitions (how each in-scope resource is classified).

• Scope (query.filter) -- a DrafttQL filter selecting the resources the policy evaluates, e.g. { "technology": { "$eq": "rds" } }. Use {} (or omit) for all resources of the type. Don't repeat scope conditions inside rules.
• Status definitions -- a map of status name to definition. Exactly one status must be the default (isDefault: true, no rules); every other status needs rules. criticality must be unique per status (convention: Non-Compliant 20, Compliant 10).
• Rules and conditions -- multiple rules are OR-ed (matching any one is enough); conditions within a rule are AND-ed. Each condition checks a single field.
• Prerequisites -- optional per-rule filters for multi-segment policies ("if lambda then X, if rds then Y"). Resources matching no prerequisite become unknown.
• Operators -- $eq, $ne, $gt, $gte, $lt, $lte, $in, $nin, $exists, $ilike, $containsAny. There is no $or: use $in for alternatives on the same field, or multiple rules for cross-field OR.
• Field notation -- tags$.<key> for tags, details$.<fieldName> for indexed component details.
• Dates -- ISO strings for absolute dates, or a relative token: $__draftt__$:relativeDate$:{"amount":30,"unit":"days","direction":"ahead"}.

Required workflow

1. Identify the resource type and technology from the requirement ("RDS must have storage encryption" → resource component, technology rds).
2. If the rules check component details, call draftt_component_details_schema for that technology first and copy the returned details$. paths verbatim. Detail fields are not listed in any resource -- the API schema is the only source of truth, so never guess a path.
3. Read draftt://policy/fields/component for base fields and tags (or draftt://policy/fields/certificate for certificates), and draftt://policy/operators for operator syntax.
4. Call draftt_policy_create.

User confirmation

draftt_policy_create and draftt_policy_create_batch always need the user's confirmation before they create anything. A batch is confirmed once for all its policies. What enforces the confirmation depends on how it is collected:

• A prompt the client shows is enforced by the server. Only an accept creates; a decline creates nothing; a dismissed prompt falls back to a token. The approval is single-use and covers only the exact arguments it showed.
• A token in the conversation relies on the agent and the client. The agent is told to send the token back only after the person approves, but the server accepts it from any call that presents it with the same arguments, so a client that auto-approves tool calls lets an agent that ignores that instruction create a policy without a person's approval. Over HTTP, a client on the older protocol revision always gets a token, because the server keeps no session to remember that the client can show prompts.

A user sees one of three outcomes:

• A confirmation prompt in the client, showing the exact JSON payload that will be submitted so the rules and conditions can be reviewed. Approving creates the policy. One approval creates once: it cannot be replayed, and it does not carry over to other arguments.
• A token in the conversation, when the client cannot show a prompt, the prompt is dismissed, or the server stops waiting for an answer (see below). The tool returns CONFIRMATION_REQUIRED (an intermediate step, not an error) with a summary of what would be created and a single-use confirmationToken valid for 5 minutes. The agent must include the summary, confirmationToken, and expiresAt verbatim in its reply to the user -- so approval can happen later, or from another session -- and, only after explicit approval, call the tool again with the same arguments plus the token. The token is bound to the exact payload: any change to the arguments, reuse, or expiry yields CONFIRMATION_TOKEN_INVALID and the flow starts over.
• Declined, when the user says no to the prompt. Nothing is created and the tool returns CONFIRMATION_DECLINED.

| Result | Code | |--------|------| | User declined the prompt | CONFIRMATION_DECLINED | | Prompt could not be sent or answered (other than a timeout) | CONFIRMATION_FAILED | | Client cannot prompt, prompt dismissed, or prompt timed out while the tool call was still open -- token issued | CONFIRMATION_REQUIRED | | Token unknown, expired, already used, or arguments changed | CONFIRMATION_TOKEN_INVALID |

How long a prompt can wait depends on the client. Where the client keeps the tool call open while it shows the prompt, the server waits 2 minutes and then returns a token. Where the client sends the answer back in a new call, an answer given more than 5 minutes after the prompt, or after a server restart, is refused with an error, and the agent calls the tool again.

Set DRAFTT_ALLOW_UNCONFIRMED_CREATE=true to bypass the confirmation flow entirely — no prompt, no confirmation token. When set, policy creates proceed immediately without requiring user approval.

Do not auto-approve or allow-list the create tools, and where no policy should ever be created, use an access key whose Draftt role cannot write (Viewer). In Claude Code, add the create tools to ask in .claude/settings.json:

{ "permissions": { "ask": ["mcp__draftt__draftt_policy_create", "mcp__draftt__draftt_policy_create_batch"] } }

Field validation

The tool validates every referenced details$. field against the live schema and rejects the request without creating anything if a field doesn't exist. If Draftt doesn't track the requested property, the policy cannot be created -- substituting a different field would produce a policy whose name doesn't match what it evaluates.

Example

{
  "name": "RDS Storage Encryption",
  "description": "All RDS instances must have storage encryption enabled.",
  "type": "governance",
  "resource": "component",
  "query": { "filter": { "technology": { "$eq": "rds" } } },
  "statusDefinitions": {
    "Compliant": {
      "criticality": 10,
      "color": "#7083CE",
      "rules": [
        {
          "conditions": [
            {
              "type": "filter",
              "condition": { "filter": { "details$.rds$.storageEncrypted": { "$eq": true } } }
            }
          ]
        }
      ]
    },
    "Non-Compliant": {
      "criticality": 20,
      "color": "#FF4747",
      "isDefault": true
    }
  }
}

Example Queries

Overviews

• "Which clusters lose support within 90 days?"
• "Show me my current technologies"
• "Which production Lambdas do I have?"

Component Discovery

• "Show me all RDS PostgreSQL databases in us-east-1"
• "List every EKS cluster tagged with environment=production"
• "What Lambda functions are running Node.js 16?"

Compliance and EOL

• "Which components are non-compliant with the End of Life policy?"
• "Show me the 10 most urgent RDS upgrades sorted by extended support cost"
• "Generate a compliance report for policy 1 focused on elasticache"
• "How much are we spending on extended support for past-EOL components?"

Kubernetes Upgrades

• "Get the full upgrade guide for EKS cluster 42"
• "What container images are running in our production GKE cluster?"
• "Create a K8s upgrade plan for our cluster named staging-eks-01"

Policy Creation

• "Create a policy that requires all RDS instances to have storage encryption enabled"
• "What detail fields can I write policy rules against for lambda?"
• "Add a governance policy flagging TLS certificates that expire within 30 days"

Security

• Dedicated API keys -- Each environment or team should use its own DRAFTT_ACCESS_KEY. Never share keys across security boundaries.
• Environment variables for secrets -- Store DRAFTT_ACCESS_KEY and DRAFTT_MCP_SHARED_SECRET in environment variables or a secrets manager. Avoid committing keys to source control. The --access-key CLI flag is provided as a convenience for local development.
• Key rotation -- Rotate API keys periodically through the Draftt dashboard. The server picks up new keys on restart.
• Read-only by default -- Every tool except draftt_policy_create and draftt_policy_create_batch is read-only and idempotent. Those two write only Draftt policy metadata; they are non-destructive and never create, update, or delete resources in your cloud accounts. No tool ever mutates your cloud infrastructure.
• Confirmation for writes -- every policy create needs the user's approval. A prompt the client shows is enforced by the server: only an accept creates, a decline or a failed prompt creates nothing, and an approval is single-use and bound to the exact arguments. When no prompt can be shown, or it is dismissed or times out, the approval is collected by the agent in the conversation with a token, and that path relies on the agent following its instructions and on the client's own per-call approval. Do not auto-approve or allow-list the create tools, and where no policy should ever be created, use an access key whose Draftt role cannot write (Viewer). See User confirmation.
• Transport security -- When using the HTTP transport in production, deploy behind TLS and set DRAFTT_MCP_SHARED_SECRET and DRAFTT_MCP_PUBLIC_URL; list browser origins in ALLOWED_ORIGINS only if a browser client must call the server.

Development

Prerequisites

• Node.js >= 20.0.0
• npm

Scripts

# Install dependencies
npm install

# Build TypeScript to JavaScript
npm run build

# Start STDIO transport server
npm start

# Start HTTP transport server
npm run start:http

# Development mode (ts-node)
npm run dev

# Run tests
npm test

# Run tests with coverage
npm run test:coverage

# Lint
npx eslint src/

# Auto-fix lint issues
npx eslint src/ --fix

License

MIT