---
title: "Roadmap"
description: "Which RFCs HCP/1.1 holds, which drafts the reference SDK already runs on trial, what is proposed for 1.2 and reserved for 2.0, and which gaps remain."
canonical: https://harnesscontextprotocol.io/docs/community/roadmap
---

# Roadmap

> Which RFCs HCP/1.1 holds, which drafts the reference SDK already runs on trial, what is proposed for 1.2 and reserved for 2.0, and which gaps remain.

HCP/1.1 is the current draft, and the reference SDK also implements five draft
RFCs on trial, one of them in part. Everything after that is a proposal that
binds no one until it passes the [RFC process](/docs/community/governance#rfc-process),
so open an issue titled `RFC idea: <title>` on `hcp-protocol` to move an item
forward.

## In the current draft

The reference SDK and runtime (0.3.0) and the CLI (0.2.0) implement both
versions below. The protocol repository is tagged `v0.1.0` with HCP/1 and RFC
0001, and the next tag adds RFC 0003, the RFC 0001 erratum and the RFC 0008
errata.

| Version | Contents |
|---------|----------|
| HCP/1.0 | Pack model (three files), Execute + isolated Sense, Policy (`operation`, `land`), Binding modes and hubs, five capability grants, sandbox default, CLI bootstrap pack (`hcp-cli`), availability flags, host projections (tool naming, `hcp__read_skill`) |
| HCP/1.1 | RFC 0001: named commands required for wrap; installer family; land `local`; `confirm` defined for writes; health commands never mint; control vs runtime plane. RFC 0003: `wrap.workspace` exec plane (local driver in the reference runtime). RFC 0008: errata where the specification disagreed with itself and with its working notes, and the `write_stimulus` lint. |

## Drafts the reference SDK implements

These RFCs are drafts in `hcp-protocol`. The reference SDK, runtime and CLI
implement them on trial before acceptance, and the
[Specification](/docs/specification) section does not contain them yet.

| RFC | Adds | Explained in |
|-----|------|--------------|
| [0002](https://github.com/harnesscontextprotocol/hcp-protocol/blob/master/rfcs/0002-skill-four-faces.md) Skill four faces | Lint fails on drift between the Skill and the commands, host paths, credentials, and MCP as the install path | [Skill](/docs/concepts/skill#rules) |
| [0004](https://github.com/harnesscontextprotocol/hcp-protocol/blob/master/rfcs/0004-wrap-json-flag.md) Wrap JSON flag | `wrap.json_flag`, a per-command `json_flag`, and no flag when `cli[]` already selects JSON | [CLI projection](/docs/concepts/command#the-json-flag) |
| [0005](https://github.com/harnesscontextprotocol/hcp-protocol/blob/master/rfcs/0005-wrap-project-mode.md) Wrap project mode | `wrap.workspace.mode: project`, and `no_project` where a runtime has none | [Manifest](/docs/packs/manifest#where-the-cli-runs) |
| [0006](https://github.com/harnesscontextprotocol/hcp-protocol/blob/master/rfcs/0006-access-modes.md) Access | Modes, allow/ask/deny rules, human approvals, `confirm: "always"`, approval views, audit | [Access](/docs/concepts/access) |
| [0007](https://github.com/harnesscontextprotocol/hcp-protocol/blob/master/rfcs/0007-host-projection.md) Host projection | Command titles, approval options | [Titles](/docs/concepts/command#titles), [Answers a host can offer](/docs/concepts/access#answers-a-host-can-offer) |

The SDK does not implement the rest of RFC 0007 yet: a call record a host shows
for each exec (`call_id`, `title`, `effect`, `status`, `locations`), rules for
cancelling a run (open approvals answered as cancelled, no call started after a
cancel), and an access mode a person picks per session.

## Proposed for HCP/1.2

Each item is a candidate RFC for a minor version, which may only add.

| Item | Why | Shape |
|------|-----|-------|
| Pack `version` | Upgrades and pinning need it | `version: "1.4.0"` in manifest; semver; runtimes report it in availability |
| Argument schema | Hosts generate tool parameters by hand today | `verbs.<k>.args` as JSON Schema; lint validates; hosts project directly |
| Result schema | Agents cannot rely on result shape | `verbs.<k>.result` as JSON Schema, optional |
| Error codes | The specification has only `error` strings, matched by regex | Normative `code` alongside `error` in the result envelope, with a registry; the reference implementation already returns the [codes in Errors](/docs/reference/errors#error-codes) |
| Extension namespace | Runtimes need private fields without lint noise | `x-*` keys ignored by lint, reserved for extensions |
| Trigger payload schema | Sinks cannot validate | `stimulusTriggers[].payload` as JSON Schema |
| Manifest `$schema` | Editor validation | Optional `$schema` pointing at the published schema |
| Deprecation markers | Renaming commands is breaking | `verbs.<k>.deprecated: "<replacement>"` |

## Reserved for HCP/2.0

These change meaning, which only a major version may do.

| Item | Why it is major |
|------|-----------------|
| Registry protocol | Discovery, publish, fetch by `pack_id@version`; integrity hashes; provenance. The [community catalog](/docs/packs/share#catalog) is a PR-based index and stays separate from it. |
| Pack signing | Signature over the three files; runtimes verify before install |
| Capability wire profile | Grants as a portable token so a runtime can accept an upstream decision |
| Transport adapters | Normative MCP export and A2UI projection with round-trip guarantees |
| Rename wire fields | `surface.json` → `pack.json`, `verb_key` → `command`, with a compatibility shim |
| Streaming results | Long-running commands, progress events |

## What HCP still lacks

Set against MCP, Agent Plugins, OpenAPI and package ecosystems, HCP still has
these gaps.

| They have | HCP status | Plan |
|-----------|-----------|------|
| Multi-language SDKs | TypeScript only | Python next; the pipeline is small |
| A registry protocol (signed `pack_id@version`) | None | HCP/2.0 |
| A community catalog (search + share) | [Catalog](/docs/packs/share#catalog), `/api/v1/packs`, `hcpx search` | Grow entries by PR |
| A conformance badge | Vectors exist, no badge | Publish a checklist and self-attestation format |
| A public implementations list | Starting | [Implementations](/docs/community/implementations) |
| A security disclosure process | Starting | [Security](/docs/community/security) |
| Versioned spec permalinks | Single draft | Freeze `/docs/specification` per `hcp-protocol` tag |
| Changelog | In §13.5 | Dedicated page per version |
| Interactive examples / playground | None | Browser sandbox running the reference runtime on gold packs |
| Editor tooling | The [schemas](/docs/reference/schemas) are live; no editor maps them yet | VS Code validation through the published schemas |
| A test-suite runner for third parties | Bun test in the monorepo | Extract vectors to a language-neutral fixture format |
| Governance charter | [Governance](/docs/community/governance) | Ratify once a second implementer joins steering |

## Not planned

The protocol will not add a verb ontology, tenant identifiers or credentials in
packs, a mandatory UI, or polling as Sense. The
[non-goals](/docs/introduction/design-principles#non-goals) give the reasons.

## Sitemap

- [Documentation](https://harnesscontextprotocol.io/docs)
- [Packs](https://harnesscontextprotocol.io/packs)
- [Glossary](https://harnesscontextprotocol.io/docs/reference/glossary)
- [llms.txt](https://harnesscontextprotocol.io/llms.txt)
- [llms-full.txt](https://harnesscontextprotocol.io/llms-full.txt)
- [OpenAPI](https://harnesscontextprotocol.io/openapi.json)
- [MCP](https://harnesscontextprotocol.io/mcp)