KCP - Knowledge Context Protocol

Feature	KCP knowledge.yaml	llms.txt	AGENTS.md	A2A Cards
Structured knowledge index	✓	✓ (flat)	—	—
Dependency graph	✓	—	—	—
Intent / question mapping	✓	—	—	—
Freshness dating	✓	—	—	—
Audience targeting	✓	—	—	—
Scales to enterprise corpora	✓	—	—	—
Auth & access metadata	✓	—	—	✓
Compliance / data residency	✓	—	—	—
Payment metadata	RFC	—	—	—
Cross-repo federation	RFC	—	—	—
Codebase working instructions	—	—	✓	—
Agent capability discovery	—	—	—	✓
File-only, no server needed	✓	✓	✓	—

Specification

The knowledge unit fields

Each unit in a KCP manifest describes a self-contained piece of knowledge. Five fields are required; the rest add structure as you need it.

id Required

Unique identifier within the manifest. Lowercase ASCII, digits, hyphens, and dots. Example: api-authentication-guide

path Required

Relative path from the manifest to the content file. Forward slashes only. Example: docs/api/auth.md

intent Required

One sentence: what question does this unit answer? The primary signal for agent task routing. Written as a question, not a title.

scope Required

Breadth of applicability: global, project, or module. Tells agents how broadly this knowledge applies.

audience Required

Who this unit is for: human, agent, developer, architect, operator. A unit can target multiple audiences.

validated Recommended

ISO 8601 date when a human last confirmed the content was accurate. Agents can refuse to act on knowledge that has not been revalidated.

depends_on Optional

Unit IDs that should be loaded before this one. Enables dependency-ordered context building. Cycles are detected and handled gracefully.

supersedes Optional

The unit ID this replaces. Agents prefer the superseding unit. The old unit can stay in the manifest for historical reference.

triggers Optional

Keywords or task contexts for retrieval. An agent working on authentication finds relevant units via triggers, without scanning every unit.

kind Optional

Type of artifact: knowledge (default), schema, service, policy, executable. Tells agents how to interact with the unit.

format Optional

Content format: markdown, pdf, openapi, json-schema, jupyter, html, and more. Agents may infer from extension if omitted.

content_type Optional

Full MIME type for precise format identification. Example: application/vnd.oai.openapi+yaml;version=3.1. Overrides format when both are present.

language Optional

BCP 47 language tag: en, no, de, fr, ja. Can be set at root level as a default for all units, and overridden per unit.

license Optional

SPDX identifier (e.g. Apache-2.0, CC-BY-4.0) or structured object with spdx, url, and attribution_required. Inheritable from root.

update_frequency Optional

How often this content changes: hourly, daily, weekly, monthly, rarely, never. Helps agents decide when to re-fetch.

indexing Optional

AI crawling permissions: open, read-only, no-train, none, or structured object with allow/deny lists. Inheritable from root.

Level 1 — Minimal

id + path + intent + scope + audience. What knowledge exists, what it answers, who it is for. Five minutes to add.

Level 2 — Structured

Adds validated, depends_on, kind, format, and language. Freshness-aware retrieval, dependency-ordered loading, and content-type awareness.

Level 3 — Full

Adds triggers, supersedes, relationships, license, update_frequency, and indexing. Task-based routing, knowledge graph navigation, and governance.

A JSON Schema (draft-07) is available for editor autocompletion and pre-parse validation. See SPEC.md §7.1.

Examples

From minimal to production

Real knowledge.yaml files from the KCP repository, showing the adoption gradient from a single unit to a full knowledge graph.

The KCP Adoption Gradient: from Minimal to Multi-Agent across five stages

Foundation

Start here. These examples cover the first three stages of the adoption gradient.

# Minimal KCP example — five minutes to add.
# This is a valid knowledge.yaml at Level 1 conformance.

kcp_version: "0.11"
project: my-project
version: 1.0.0

units:
  - id: overview
    path: README.md
    intent: "What is this project and how do I get started?"
    scope: global
    audience: [human, agent]

# Personal site / portfolio example
# Shows: audience differentiation, freshness, depends_on

kcp_version: "0.11"
project: wiki.example.org
version: 1.0.0
updated: "2026-02-28"
language: en
license: "CC-BY-4.0"

units:
  - id: home
    path: index.md
    intent: "Who is this person and what is this site about?"
    scope: global
    audience: [human, agent]
    validated: "2026-02-25"
    triggers: [overview, about, biography, portfolio]

  - id: about
    path: about/index.md
    intent: "What has this person built and what are they doing now?"
    scope: global
    audience: [human, agent, architect]
    validated: "2026-02-25"
    depends_on: [home]
    triggers: [biography, background, current work]

  - id: cv
    path: about/cv.md
    intent: "What is this person's full professional history?"
    scope: project
    audience: [human, agent]
    validated: "2026-02-25"
    depends_on: [about]
    triggers: [cv, resume, employment, education]

  - id: reading
    path: interests/reading/index.md
    intent: "What books has this person read?"
    scope: project
    audience: [human]         # human-only, not for agents
    validated: "2026-02-25"

  - id: llms-index
    path: llms.txt
    intent: "Machine-readable site index"
    scope: global
    audience: [agent]          # agent-only entry point
    validated: "2026-02-25"

relationships:
  - from: about
    to: home
    type: context
  - from: cv
    to: about
    type: context

# Open source community wiki — 16 units, full topology
# Dependency chains across architecture layers
# Freshness: archived (2022) vs active (2026) content

kcp_version: "0.11"
project: community-wiki
version: 1.0.0
updated: "2026-02-28"
language: en
license: "Apache-2.0"
indexing: open

units:
  - id: home
    path: index.md
    intent: "What is this community and how is the wiki organised?"
    scope: global
    audience: [human, agent, developer, architect]
    validated: 2022-12-01
    triggers: [overview, navigation, community]

  - id: iam-sso
    path: whydah/Getting-started.md
    intent: "How do I get started with the IAM and SSO platform?"
    scope: module
    audience: [human, agent, developer, operator]
    validated: 2022-12-01
    depends_on: [projects-index]
    triggers: [SSO, IAM, identity, OAuth2, OpenID Connect]

  - id: iam-architecture
    path: whydah/Architecture-Overview.md
    intent: "How is the IAM platform architected?"
    scope: module
    audience: [human, agent, architect, developer]
    validated: 2022-12-01
    depends_on: [iam-sso]
    triggers: [SSO architecture, SecurityTokenService]

  - id: software-architecture
    path: architecture/index.md
    intent: "What architectural patterns does this community recommend?"
    scope: module
    audience: [human, agent, architect, developer]
    validated: 2022-12-01
    triggers: [DDD, microservices, CQRS, event sourcing]

  - id: security
    path: security/index.md
    intent: "How should microservice security be approached?"
    scope: module
    audience: [human, agent, architect, developer]
    validated: 2022-12-01
    depends_on: [software-architecture]
    triggers: [security, STRIDE, threat modelling, OWASP]

relationships:
  - from: software-architecture
    to: iam-architecture
    type: enables
  - from: security
    to: iam-sso
    type: context

Enterprise Patterns

Access control, rate limiting, compliance, and cross-org federation.

A healthcare system with PII sensitivity, restricted access, delegation chains, and mandatory human-in-the-loop for patient data.

access sensitivity delegation human_in_the_loop

View on GitHub

Public and internal API documentation with per-unit rate limits, tiered access (public vs restricted), and advisory throttling metadata.

rate_limits access auth_scope

View on GitHub

DAG cross-manifest federation with typed relationships, cross-manifest dependencies, on_failure semantics, and local_mirror for air-gapped operation.

manifests external_depends_on external_relationships local_mirror

View on GitHub

Advanced

Relationship graphs, chunking hints, A2A integration, and well-known discovery.

A platform migration scenario exercising five of the six relationship types: depends_on, enables, context, supersedes, and contradicts. (The sixth, governs, is demonstrated in the federation example.)

depends_on supersedes contradicts enables

View on GitHub

Large documents with token-budget hints, chunking strategies, and summary-first loading patterns for context-window-aware agents.

hints chunking token_budget

View on GitHub

Composing Google A2A agent identity with KCP knowledge manifests. The Front Door (agent.json) meets the Filing Cabinet (kcp.json).

a2a knowledgeManifest .well-known

View on GitHub

HTTP-based discovery via /.well-known/kcp.json endpoint, enabling agents to locate knowledge manifests without prior configuration.

.well-known/kcp.json discovery

View on GitHub

Parsers

Reference implementations

Validate your knowledge.yaml with the official Python or Java parser. Both enforce the conformance rules in SPEC.md section 7.

Python

Requires Python 3.10+. Uses pyyaml with safe loading.

pip install kcp

from kcp import parse, validate

manifest = parse("knowledge.yaml")
result = validate(manifest)

if not result.is_valid:
    print("Errors:", result.errors)
if result.warnings:
    print("Warnings:", result.warnings)

python -m kcp knowledge.yaml

Java

Requires Java 17+. Uses SnakeYAML with SafeConstructor to prevent deserialization attacks.

<dependency>
  <groupId>no.cantara.kcp</groupId>
  <artifactId>kcp-parser</artifactId>
  <version>0.2.0</version>
</dependency>

import no.cantara.kcp.KcpParser;
import no.cantara.kcp.KcpValidator;
import no.cantara.kcp.model.KnowledgeManifest;

var manifest = KcpParser.parse(Path.of("knowledge.yaml"));
var result = KcpValidator.validate(manifest);

if (!result.isValid()) {
    result.errors().forEach(System.err::println);
}
result.warnings().forEach(System.out::println);

java -jar kcp-parser-0.2.0.jar knowledge.yaml

MCP Bridges

Serve knowledge.yaml via MCP

Three ready-to-use MCP servers. Drop a knowledge.yaml in your project and every MCP-compatible agent — Claude, Copilot, Cursor, Gemini — can discover and read your knowledge units instantly.

TypeScript

Requires Node.js 18+. Supports stdio and HTTP/SSE transports.

npm install -g kcp-mcp

kcp-mcp knowledge.yaml
kcp-mcp knowledge.yaml --agent-only
kcp-mcp knowledge.yaml --transport http --port 8000

{ "mcpServers": {
    "project-knowledge": {
      "command": "npx",
      "args": ["kcp-mcp", "knowledge.yaml"]
    }
} }

Python

Requires Python 3.10+. Supports stdio and HTTP/SSE transports.

pip install kcp-mcp

kcp-mcp knowledge.yaml
kcp-mcp knowledge.yaml --agent-only
kcp-mcp knowledge.yaml --transport http --port 8000

{ "mcpServers": {
    "project-knowledge": {
      "command": "kcp-mcp",
      "args": ["knowledge.yaml"]
    }
} }

Java

Requires Java 17+. Build a fat jar from source; no Maven Central release yet.

cd parsers/java && mvn install -q
cd bridge/java && mvn package -DskipTests -q
# Produces: target/kcp-mcp-0.1.0-jar-with-dependencies.jar

java -jar kcp-mcp-0.1.0-jar-with-dependencies.jar knowledge.yaml
java -jar kcp-mcp-0.1.0-jar-with-dependencies.jar knowledge.yaml --agent-only

{ "mcpServers": {
    "project-knowledge": {
      "command": "java",
      "args": ["-jar", "/path/to/kcp-mcp.jar", "knowledge.yaml"]
    }
} }

Use Cases

What you could build with KCP

Example scenarios across different project types and scales. Find the one that matches your situation.

Open Source Docs That Scale

Your project has a README, an API reference, three migration guides, and a changelog. An agent asked "how do I authenticate?" loads all of them and picks at random. With KCP, it finds the right unit by intent, checks the validated date, skips the stale v2 guide via supersedes, and reads the architecture overview before the API reference via depends_on. Five fields. Five minutes.

intent depends_on validated supersedes triggers

knowledge.yaml

units:
  - id: quickstart
    path: docs/quickstart.md
    intent: "How do I install and run my first example?"
    scope: global
    audience: [human, agent, developer]
    validated: "2026-02-15"
    triggers: [install, setup, getting-started]

  - id: api-auth
    path: docs/api/authentication.md
    intent: "How do I authenticate API requests?"
    scope: module
    audience: [developer, agent]
    depends_on: [quickstart]
    supersedes: api-auth-v1
    triggers: [oauth2, bearer-token, jwt]

Agent-Navigable API Reference

Your API reference is 62,000 tokens. An agent with 16,000 tokens of remaining context tries to load it and fails. With KCP, the manifest declares the full reference as load_strategy: never and exposes it as five named chunks. The agent loads only the "Authentication endpoints" chunk when the user asks about tokens — the rest stays available without ever touching the context window.

hints.token_estimate hints.chunked hints.chunk_of hints.load_strategy kind

knowledge.yaml

units:
  - id: api-reference
    path: api/reference.md
    kind: schema
    format: openapi
    intent: "What endpoints does the API expose?"
    scope: module
    audience: [developer, agent]
    hints:
      token_estimate: 62000
      load_strategy: never
      chunked: true
      chunk_count: 5

  - id: api-ref-auth
    path: api/reference-auth.md
    intent: "What are the authentication endpoints?"
    hints:
      token_estimate: 9400
      chunk_of: api-reference
      chunk_index: 1
      chunk_topic: "Authentication and token management"

Multilingual Knowledge Base

Your engineering wiki exists in English and Norwegian. An agent defaults to English. A Norwegian user expects Norwegian. Without language metadata, agents pick whichever file appears first. With KCP, each unit declares its BCP 47 language tag. Agents select the right variant for the user's locale. Translation staleness is visible at a glance through mismatched validated dates between language variants.

language audience validated

knowledge.yaml

project: engineering-wiki
language: en               # default for all units

units:
  - id: methodology-en
    path: methodology/overview-en.md
    intent: "What development methodology is used?"
    language: en
    scope: global
    audience: [human, agent, developer]
    validated: "2026-02-20"

  - id: methodology-no
    path: methodology/overview-no.md
    intent: "Hvilken utviklingsmetodologi brukes?"
    language: "no"
    scope: global
    audience: [human]
    validated: "2026-01-10"    # stale — translation not synced

RFC Extensions

These scenarios use KCP RFC proposals. Fields are extensions to the core spec — open for community feedback.

GDPR-Safe Knowledge for Agents

An autonomous agent loads a customer PII schema and sends it to an external LLM for summarization — violating GDPR. There was no machine-readable signal that this unit cannot leave the EEA. With KCP compliance metadata, the manifest declares data residency, regulation scope, sensitivity level, and processing restrictions. The orchestration layer reads these before loading the content and routes to an on-premise model instead.

compliance.data_residency compliance.regulations compliance.sensitivity compliance.restrictions access

knowledge.yaml

compliance:                    # root-level defaults
  data_residency:
    regions: [EEA]
    hard_requirement: true
  regulations: [GDPR]
  sensitivity: confidential

units:
  - id: customer-pii-schema
    path: data/customer-pii.md
    intent: "How is customer personal data structured?"
    scope: module
    audience: [developer]
    access: restricted
    compliance:
      restrictions:
        - no-external-llm
        - audit-required
        - human-approval-required

Monetized Knowledge APIs

You publish a knowledge API: free documentation, and real-time data at $0.002 per request via stablecoin micropayment. Agents discover your pricing by crashing into a 402 error. With KCP, the manifest declares payment methods (including x402), rate limits per authentication tier, and per-unit overrides. An agent reads the manifest, checks its budget, picks the free summary over the paid corpus, and plans its request rate — before issuing a single request.

payment.methods payment.default_tier rate_limits

knowledge.yaml

payment:
  default_tier: free
  methods:
    - type: free
    - type: x402
      currency: USDC
      price_per_request: "0.002"
      networks: [base, ethereum]

rate_limits:
  default:
    requests_per_minute: 10
  authenticated:
    requests_per_minute: 60

units:
  - id: docs
    path: docs/index.md
    intent: "What knowledge is available?"
    # inherits root defaults: free, 10 rpm

  - id: realtime-data
    path: data/feed.json
    intent: "What are the current prices?"
    payment:
      default_tier: metered
      methods:
        - type: x402
          currency: USDC
          price_per_request: "0.05"

Cross-Team Knowledge Federation

Five teams each have their own knowledge.yaml. Product Alpha's deployment guide depends on Platform's infrastructure docs. Security's GDPR policy governs Product Alpha's data handling. Each manifest is an island. With KCP federation, a hub manifest composes sub-manifests with typed relationships: Platform is "foundation," Security is "governs." Units declare cross-manifest dependencies. Agents follow the graph across team boundaries.

manifests external_depends_on external_relationships

knowledge.yaml

project: engineering-hub
manifests:
  - id: platform
    url: "https://platform.internal/knowledge.yaml"
    label: "Platform — infrastructure, CI/CD"
    relationship: foundation
  - id: security
    url: "https://security.internal/knowledge.yaml"
    label: "Security — policy, compliance"
    relationship: governs

units:
  - id: product-deployment
    path: ops/deployment.md
    intent: "How do I deploy Product Alpha?"
    scope: global
    audience: [developer, agent]
    external_depends_on:
      - manifest: platform
        unit: deployment-architecture
      - manifest: security
        unit: gdpr-policy
        on_failure: warn

Secure Agent Delegation Chains

A human authorizes an orchestrator, which delegates to a sub-agent, which calls a tool that accesses sensitive clinical data. Nobody knows how many hops the content has traveled from the original decision-maker. With KCP delegation metadata, the manifest declares maximum chain depth, mandatory capability attenuation, human-in-the-loop consent, and W3C Trace Context requirements for full audit chain reconstruction. An orchestrator two hops deep knows before it tries: this content requires direct human approval.

delegation.max_depth delegation.human_in_the_loop trust.audit trust.agent_requirements

knowledge.yaml

delegation:                    # root-level defaults
  max_depth: 2
  require_capability_attenuation: true
  audit_chain: true

trust:
  audit:
    require_trace_context: true

units:
  - id: patient-summary
    path: reports/patient-cohort.md
    intent: "What does the patient cohort analysis show?"
    scope: module
    audience: [operator]
    access: restricted
    delegation:
      max_depth: 1
      human_in_the_loop: always
    trust:
      agent_requirements:
        require_attestation: true
        trusted_providers: ["agents.hospital.internal"]

Scenarios & Simulators

Stress-testing the protocol

Five runnable Java simulators exercise the A2A + KCP composition model at increasing complexity — from happy-path energy metering to adversarial multi-agent AML orchestration. Each scenario surfaces specific spec behaviors and drives the v0.9+ roadmap.

Three simulation levels: Happy Path with HITL, 3-Hop Delegation Chain, and Adversarial Orchestration

Scenario	What it tests	Key spec features	Agents	Tests	GitHub
Energy Metering	Happy path, HITL gate, audit trail	`access`, `delegation`, `human_in_the_loop`	2	36	View
Legal Delegation	3-hop chain, max_depth:0, capability attenuation	`delegation.max_depth`, `auth_scope`	3	36	View
Financial AML	Adversarial multi-agent, GDPR, rogue agent	`compliance`, `sensitivity`, `delegation`	5	27	View
Rate-Limit Aware	Advisory rate_limits, PoliteAgent vs GreedyAgent	`rate_limits` §4.15	2	34	View
Dependency Ordering	Topological sort, cycle detection, 5 of 6 relationship types	`depends_on`, `supersedes`, `contradicts`	1	34	View

Level 2 Simulator: Capability Attenuation across a 3-agent delegation chain with max_depth:0 rejection

Scenario 2: 3-hop delegation with scope attenuation

Level 3 Simulator: RogueAgent attempting GDPR bypass, scope elevation, max_depth bypass, and delegation depth violations

Scenario 3: Adversarial RogueAgent stress test

Stage 4: The Multi-Agent Composition Model showing the Front Door (agent.json) connected to the Filing Cabinet (kcp.json) via knowledgeManifest

A2A + KCP composition: Front Door meets Filing Cabinet

Escalating access control pyramid: public, authenticated, restricted (PII), and human-in-the-loop layers

Escalating access: public to HITL-gated

Which simulator tests what?

Spec Feature	Tested by
`rate_limits` (§4.15)	scenario4, api-platform-rate-limits
`delegation` (§3.4)	scenario2, scenario3
`compliance` (§3.5)	scenario3, compliance-audit
`human_in_the_loop`	scenario1, scenario2
`relationships` (§5)	scenario5, dependency-graph

Getting Started

Four steps to adopt KCP

KCP wraps your existing documentation with metadata. Your files stay where they are. The only new file is knowledge.yaml.

Audit

Walk your project. List the key documents: README, architecture docs, API guides, agent definitions. For each, ask: what question does this answer?

Declare

Create knowledge.yaml at the root. Add id, path, intent, scope, and audience for each unit. This is Level 1 — already useful.

Structure

Add validated dates and depends_on relationships. Agents now understand reading order and can flag stale content. This is Level 2.

Navigate

Add triggers and relationships for task-based retrieval. Agents find the right unit by context, not by scanning everything. This is Level 3.

Pick a template and start

Copy a ready-made knowledge.yaml at your target conformance level, then validate it in the browser.

kcp_version: "0.11"
project: my-project
version: 1.0.0

units:
  - id: readme
    path: README.md
    intent: "What is this project and how do I get started?"
    scope: global
    audience: [human, agent]

  - id: contributing
    path: CONTRIBUTING.md
    intent: "How do I contribute patches, issues, and pull requests?"
    scope: global
    audience: [developer]

Five required fields per unit: id, path, intent, scope, audience. Agents can already fetch and route with this alone.

kcp_version: "0.11"
project: my-project
version: 1.0.0
updated: "2026-01-01"

units:
  - id: readme
    path: README.md
    intent: "What is this project and how do I get started?"
    scope: global
    audience: [human, agent]
    validated: "2026-01-01"
    update_frequency: monthly

  - id: architecture
    path: docs/architecture.md
    intent: "What are the key architectural decisions and component boundaries?"
    scope: global
    audience: [developer, architect, agent]
    kind: knowledge
    format: markdown
    depends_on: [readme]
    validated: "2026-01-01"

  - id: api-guide
    path: docs/api.md
    intent: "How do I authenticate and call the API?"
    scope: module
    audience: [developer, agent]
    kind: knowledge
    format: markdown
    depends_on: [architecture]
    validated: "2026-01-01"

Adds validated, update_frequency, kind, format, and depends_on. Agents understand reading order and can flag stale units.

kcp_version: "0.11"
project: my-project
version: 1.0.0
updated: "2026-01-01"
language: en
license: "Apache-2.0"
indexing: open

units:
  - id: readme
    path: README.md
    intent: "What is this project and how do I get started?"
    scope: global
    audience: [human, agent]
    validated: "2026-01-01"
    update_frequency: monthly
    triggers: [overview, introduction, getting-started, install]

  - id: architecture
    path: docs/architecture.md
    intent: "What are the key architectural decisions and component boundaries?"
    scope: global
    audience: [developer, architect, agent]
    kind: knowledge
    format: markdown
    depends_on: [readme]
    validated: "2026-01-01"
    triggers: [architecture, design, components, decisions, adr]

  - id: api-reference
    path: docs/api.md
    intent: "What endpoints does the API expose and how do I authenticate?"
    scope: module
    audience: [developer, agent]
    kind: schema
    format: openapi
    depends_on: [architecture]
    validated: "2026-01-01"
    triggers: [api, endpoints, authentication, rest, openapi, swagger]

relationships:
  - from: readme
    to: architecture
    type: enables
  - from: architecture
    to: api-reference
    type: enables

Adds triggers for task-based retrieval, root-level language / license / indexing, and a relationships block. Agents find the right unit by context without scanning everything.

Roadmap

Where KCP is headed

v0.11 is the current release. Fields are promoted from RFC proposals to core as they accumulate real-world validation. Remaining RFCs are open for community feedback through 2026.

v0.3 — Shipped

Core specification

Required fields + optional fields promoted from RFC-0001.

id path intent scope audience validated depends_on supersedes triggers kind format content_type language license indexing update_frequency relationships

v0.4 — Shipped

Context window hints

RFC-0006 promoted to core. Agents can plan context budgets and prefer summaries over full documents.

hints.token_estimate hints.load_strategy hints.priority hints.density hints.summary_available hints.summary_unit hints.summary_of hints.chunked hints.chunk_count hints.chunk_of

v0.5 — Shipped

Access, classification & provenance

Five fields promoted from RFC-0002, RFC-0004, and RFC-0005. Agents can skip units they cannot or should not load, and publishers can declare who they are.

access sensitivity deprecated payment.default_tier trust.provenance

v0.6 — Shipped

Authorization & audit

Three fields promoted from RFC-0002 and RFC-0004. Publishers can name required auth scopes, declare supported auth methods (OAuth 2.0, API key, or none), and require agents to produce audit trails with W3C Trace Context.

auth_scope auth.methods trust.audit

v0.7 — Shipped

Delegation & compliance

Six fields promoted from RFC-0002 and RFC-0004, validated by 150 adversarial tests across three simulation scenarios. Agents can enforce delegation depth limits, capability attenuation, HITL gates, data residency constraints, regulation vocabulary, and processing restrictions.

delegation compliance.data_residency compliance.regulations compliance.restrictions

v0.8 — Shipped

Consolidation & rate limits

Consolidation release: rate_limits promoted from RFC-0005 (default tier: requests_per_minute, requests_per_day), depends_on added to relationship type vocabulary, parser/schema divergences resolved.

rate_limits.default depends_on (relationship type)

v0.9 — Shipped

Federation

Cross-manifest federation promoted from RFC-0003: manifests block, external_depends_on, external_relationships, governs relationship type, on_failure semantics, local_mirror for air-gapped operation, cycle detection, and fetch limits. DAG topology with local authority.

manifests external_depends_on external_relationships governs (relationship type) local_mirror

v0.10 — Shipped

Discovery & Versioning

Federation version pinning (version_pin, version_policy), RFC-0007 Query Vocabulary for pre-invocation capability discovery, instruction file bridge guide, and kcp init specification. Zero breaking changes.

version_pin version_policy RFC-0007 Query Vocabulary kcp init instruction file bridge

v0.11 — Current

Agent Readiness

Three new fields make knowledge manifests self-describing for autonomous agents: freshness_policy (staleness threshold + reaction), requires_capabilities (advisory tool/permission/role hints), and network topology in /.well-known/kcp.json. Plus kcp reflect CLI for session-end skill lifecycle guardrails. Zero breaking changes.

freshness_policy requires_capabilities network (well-known) kcp reflect RFC-0008

Auth & Delegation

auth delegation

Authentication methods (OAuth 2.1, API key, SPIFFE, DID) and multi-agent delegation chain constraints. The access field was promoted to core in v0.5; auth_scope and auth.methods were promoted to core in v0.6; the delegation block was promoted to core in v0.7. Remaining RFC scope: SPIFFE/DID identity, signed delegation tokens, capability attenuation enforcement.

Federation

manifests external_depends_on external_relationships

DAG cross-manifest federation with typed relationships (foundation, governs, peer, child, archive), external_depends_on, external_relationships, cycle detection, fetch limits, and local_mirror for air-gapped operation.

Trust & Compliance

compliance content_integrity audit agent_requirements

Data residency, regulation vocabulary (GDPR, NIS2, HIPAA, DORA…), processing restrictions, content integrity (JWS signing), and audit/attestation (W3C Trace Context, attestation_url, trusted_providers). trust.provenance and sensitivity were promoted to core in v0.5; trust.audit was promoted to core in v0.6; the compliance block was promoted to core in v0.7. Remaining RFC scope: content integrity, attestation URL, trusted providers.

Payment & Rate Limits

payment.methods payment.x402 rate_limits

x402 stablecoin micropayments, metered billing (Stripe, Google AP2), and per-tier rate limits with token-based quotas for LLM pipelines. payment.default_tier was promoted to core in v0.5; rate_limits was promoted to core in v0.8. Remaining RFC scope: payment methods, x402, per-tier rate limit overrides.

Context Window Hints

hints

Token estimates, eager/lazy/never load strategies, priority and density signals, summary relationships, and chunking for large documents — so agents plan context budget before fetching. Fully promoted to core in v0.4.

FAQ

Common questions

How is KCP different from llms.txt?

llms.txt answers "what does this site contain?" — it is a flat, human-readable index. KCP answers "how is this knowledge structured, how fresh is it, and how should an agent navigate it?" They are complementary. A project can maintain both. When both are present, KCP-aware agents prefer knowledge.yaml for navigation and fall back to llms.txt for tools that do not support KCP.

Does KCP compete with MCP?

No. MCP defines how agents connect to tools. KCP defines how the knowledge those tools serve is structured. MCP is the transport layer; KCP is the metadata layer. A knowledge server can expose KCP-structured content via MCP. The relationship is the same as HTTP (transport) and HTML (content format).

Do I need Synthesis to use KCP?

No. KCP is a file format specification, not a runtime tool. It requires no server, no database, and no running process. A static site or git repository can be fully KCP-compliant. Synthesis is one tool that implements KCP natively, but any tool can parse knowledge.yaml — it is standard YAML.

What is the minimum viable knowledge.yaml?

A project name and one unit with id, path, intent, scope, and audience. That is five fields per unit. Three minutes of work. The format allows complexity without demanding it.

How do I keep the manifest in sync with documentation?

The validated field is your sync signal. Set it when you confirm content is accurate. When content changes, update the date. A unit with a validated date more than 90 days old is a candidate for review. Tooling can automate this — a pre-commit hook that warns when a changed doc does not update its validated date.

Where does knowledge.yaml go in a monorepo?

Place it at the root of each subproject that has its own documentation. Each manifest is independent (SPEC.md section 1.3). Cross-manifest federation — linking knowledge across repos with dependency chains — is now part of the core specification (v0.9 §3.6, promoted from RFC-0003). Alternatively, place a single manifest at the monorepo root using relative paths to all subprojects.

I have 80+ documents. Do I need to declare all of them?

No. KCP is not exhaustive — it describes the knowledge that matters for navigation. Start with the 10-20 documents that agents and developers consult most. Add more as the value becomes clear. A project with 20 key documents can reach Level 2 KCP compliance in under two hours.

What about authentication, compliance, and federation?

Each topic has a dedicated RFC. RFC-0002 covers authentication and multi-agent delegation. RFC-0003 covers cross-manifest federation. RFC-0004 covers trust, provenance, agent attestation (attestation_url for credential-based, trusted_providers for identity-based), and compliance (GDPR, NIS2, HIPAA). RFC-0005 covers payment methods (including x402 micropayments) and rate limits. RFC-0006 covers context window hints, token estimates, and chunking. RFC-0001 is the omnibus overview and proposal tracker. Community feedback is open through March 2026.

Give AI agents a map,not just files

AI agents are flying blind

Context stuffing fails at scale

Stale knowledge looks authoritative

No topology, no navigation

KCP in the landscape

A knowledge manifest for the AI age

Three steps to navigable knowledge

Write

Parse

Navigate

The knowledge unit fields

Level 1 — Minimal

Level 2 — Structured

Level 3 — Full

From minimal to production

Foundation

Enterprise Patterns

Compliance Audit

API Platform Rate Limits

Federation

Advanced

Dependency Graph

Hints & Chunking

A2A Agent Card

Well-Known Discovery

Reference implementations

Python

Java

Serve knowledge.yaml via MCP

TypeScript

Python

Java

What you could build with KCP

Open Source Docs That Scale

Agent-Navigable API Reference

Multilingual Knowledge Base

GDPR-Safe Knowledge for Agents

Monetized Knowledge APIs

Cross-Team Knowledge Federation

Secure Agent Delegation Chains

Stress-testing the protocol

Which simulator tests what?

Watch the simulators run

Four steps to adopt KCP

Audit

Declare

Structure

Navigate

Pick a template and start

Validate your knowledge.yaml

Who's using KCP

Add your project

Known adopters

knowledge-context-protocol

Could be your repo

Where KCP is headed

Core specification

Context window hints

Access, classification & provenance

Authorization & audit

Delegation & compliance

Consolidation & rate limits

Federation

Discovery & Versioning

Agent Readiness

Auth & Delegation

Federation

Trust & Compliance

Payment & Rate Limits

Context Window Hints

Common questions

Get involved

Report a bug or request a feature

Propose an RFC

Contribute a parser or integration

Ask a question or start a discussion

RFC lifecycle

Give AI agents a map,
not just files

Validate your `knowledge.yaml`