Agent Capability Standard (ACS) was designed to solve the "token tax" problem with MCP. As many have experienced, when using MCP-based capabilities, a large amount of tokens are injected into the Agent/LLM context window, in order for the tools to be presented and used. The root cause of this issue has to do with how capabilities are defined and delivered. Instead of providing only what is needed to select a tool, the full schema of the tool is injected, creating a scenario where the Agent/LLM is receiving too much information too soon. This is what creates the "token tax" problem with MCP. There is no standard for what the planner should see. There is no standard for when it should see it. There is no standard for who authorized it. Until now.

The Agent Capability Standard is THE capability routing and governance layer for Agent/LLM planning

ACS is an open, vendor-neutral standard that defines how Agents/LLMs discover, evaluate, and invoke capabilities at the planning layer. It operates as a governance layer above MCP, REST, and skill libraries, without modifying any of them. ACS separates planning-relevant information (what a capability does, how risky it is) from execution-relevant information (how to call it), delivering only what the planner needs, when it needs it, to the planner that is authorized to see it.

Beyond token waste, unrestricted schema injection creates a security problem that no existing mechanism addresses: an LLM planner that sees a restricted tool's schema has already incorporated it into its reasoning trajectory. Transformer attention is non-retractable. Authorization enforced after schema injection has already failed at the planning layer. Level 1 ACS conformance delivers measurable token reduction with no governance infrastructure and no changes to existing MCP servers. You read that right, no server changes, no new identity providers.

Existing mechanisms for connecting LLM agents to tools are insufficient at scale:

• Token Tax! Full schema injection via MCP's tools/list consumes 40–50% of context budget before the first instruction is processed
• Pre-authorization schema injection exposes restricted capability topology to the planner before any access control evaluation
• No existing mechanism provides a standardized, vendor-neutral, governance-aware capability discovery layer
• No existing mechanism separates planning-relevant from execution-relevant information in the agent workflow
• No existing mechanism provides planning-layer authorization that operates before context injection, not after

ACS closes those gaps with a two-layer architecture: a token-minimal Capability Summary Index that is always present, and on-demand Capability Manifests that deliver full planning contracts without invocation metadata; they are governed, when required, by a Planning Authorization Enforcement Point that filters visibility before the planner reasons.

• Token reduction - replaces full schema injection with a token-minimal Capability Summary Index; 50 tokens per capability instead of hundreds
• Routing accuracy - Capability Summaries describe outcomes, not operations; the planner selects what it needs to accomplish, not how to call an API
• Planning-layer authorization - the Planning Authorization Enforcement Point (PAEP) filters capability visibility before reasoning begins, not after
• Audit trail - every capability exposure, selection, and execution is logged in a tamper-evident, session-correlated audit stream

For the complete formal specification, including definitions, requirements, and conformance criteria, see the full reference document:

ACS-v1_0_0-Standard.md

Status: Draft for Public Comment

Version: v1.0.0

License: Apache License 2.0

Date: 2026-03-15

Author: Shawn Kahalewai Reilly

Agent Capability Standard (ACS) is a Standard, not a service/tool. A reference implementation of the ACS Standard has been created, and is currently in testing. At this time, you can use the ACS Standard to begin incorporating these concepts into your existing MCP-based applications and solutions. ACS defines three conformance levels. Levels are cumulative and designed for incremental adoption, each level delivers independent value without requiring governance infrastructure from higher levels.

Level 1 - Basic (Token Reduction, No Governance Infrastructure)

Replace full schema injection with ACS capability routing. No changes to MCP servers. No identity provider. Implementable in one working day.

• Deploy ACS Runtime as a sidecar or proxy between your LLM client and MCP servers
• Run Automated Manifest Generation (AMG) against each MCP server or OpenAPI spec
• Replace tools/list schema injection with get_capability_index()
• Replace direct tools/call with the four-operation ACS pattern

index    = runtime.get_capability_index()
manifest = runtime.get_capability_manifest(cid_from_index)
contract = runtime.select_capability(cid)
result   = runtime.execute_capability(contract, params)

Permitted claim: "ACS Level 1 token reduction and execution isolation are active for this deployment."

Level 2 - Governed (Planning-Layer Authorization + Audit)

Add planning-layer authorization and a complete audit trail. Requires an identity provider, a policy engine, and a write-once audit destination. No changes to Level 1 application code.

// JWT claims required for PAEP evaluation
{
  "sub": "planner-identity",
  "acs_roles": ["finance-operator"],
  "acs_trust_domain": "internal",
  "acs_risk_authorization": "WRITE"   // READ | WRITE | DESTRUCTIVE
}

# OPA policy example — deny-by-default PAEP
allow {
  input.planner.acs_roles[_] == input.capability.AUTHORIZED_ROLES[_]
  risk_authorized
  trust_domain_match
  jurisdiction_permitted
}

Permitted claim: "ACS Level 2 planning-layer authorization, PAEP enforcement, and tamper-evident audit trail are active. This deployment satisfies EU AI Act Article 12 logging obligations."

Level 3 - Federated (Cross-Organization Trust-Domain Routing)

Extend Level 2 with trust-domain-constrained provider selection across federated MCP deployments. Multiple organizations share a capability inventory; each planner routes only to providers within its trust domain.

• Deploy a provider eligibility registry mapping each Source Binding to its trust domain
• Declare CID equivalence across cross-organization Source Bindings
• PAEP evaluates provider trust domain at Execution Contract issuance

Permitted claim: "ACS Level 3 federated trust-domain routing is active. Cross-organization capability routing is governed and audited."

The ACS specification defines:

• Capability Identifier (CID) specification - globally unique, outcome-scoped, human-readable identifiers that decouple planning semantics from invocation mechanics; ABNF grammar, namespace governance, semantic versioning
• Capability Summary format - token-minimal (≤50 tokens) planning-context representation containing CID, outcome description, domain tag, risk classification, and semantic quality designation
• Capability Manifest format - full planning contract containing preconditions, effects, risk classification, governance metadata, and source binding; never exposes invocation-layer metadata
• Capability Summary Index - pre-loaded, token-bounded planning context artifact; one Summary per authorized capability; constructed before the planner begins reasoning
• ACS Runtime behaviors - session lifecycle, on-demand manifest retrieval protocol, execution contract issuance and resolution, failure mode handling
• Planning Authorization Enforcement Point (PAEP) - deny-by-default, synchronous authorization gate evaluating risk class, role, trust domain, and jurisdictional constraints before any capability is exposed to the planner
• Execution Contract specification - short-lived (≤300s TTL), session-scoped, CID-bound artifacts that map a selected CID to a provider invocation; issued post-selection, never delivered to the planner
• Audit logging requirements - mandatory event types, required fields, Execution Intent Hash (SHA-256/JCS), chain hash construction, buffer and retention requirements
• Risk classification system - READ / WRITE / DESTRUCTIVE with state mutation type; conservative assignment rules; DESTRUCTIVE requires Confirmation Event before execution
• Automated Manifest Generation (AMG) - normative algorithm for generating conformant Summaries and Manifests from MCP tool schemas, OpenAPI operation definitions, and A2A Agent Cards
• Three conformance levels - Level 1 (token reduction), Level 2 (governed), Level 3 (federated); each a strict superset of lower levels
• Conformance test suite - 10 test categories (T-TOKEN, T-ISOLATE, T-AUTHZ, T-CONTRACT, T-ROUTING, T-RISK, T-AUDIT, T-FEDERATED, T-ONBOARD, T-INTEROP) covering every normative requirement
• Governance metadata reference vocabulary - normative GOVERNANCE_TAGS (SOX_FINANCIAL, GDPR_PERSONAL_DATA, HIPAA_PHI, PCI_CARDHOLDER, AI_ACT_HIGH_RISK, and more), DOMAIN_TAG vocabulary, extension tag format
• Threat model - 10 named threats with mitigations, residual risks, and accepted risks
• Regulatory compliance mapping - EU AI Act, NIST AI RMF, NIST CSF 2.0

Understanding the boundary is as important as understanding the capability:

• ACS does not replace MCP. ACS operates above MCP as a governance and planning-efficiency layer. MCP servers are unmodified. ACS Runtime acts as an MCP client using standard MCP protocol.
• ACS does not replace invocation-layer authorization. ACS governs capability visibility at the planning layer. OAuth, API keys, and transport security remain in place at the execution layer. Both are necessary; neither is sufficient alone.
• ACS does not modify multi-agent orchestration. ACS governs the interface between a single LLM planner and its capability sources. Agent-to-agent delegation chains are an A2A protocol concern.
• ACS does not perform threat detection. ACS governs what capabilities a planner can see and use. Behavioral monitoring, prompt injection detection, and anomaly detection are performed by external security tools.
• ACS does not guarantee semantic correctness of AMG-generated manifests. AMG produces OPERATIONAL-quality manifests by default. OUTCOME-quality designation requires human review per the checklist in Section 13.4.

ACS was designed to help an Enterprise satisfy the capability governance, audit, and human oversight requirements emerging from global AI regulation. Level 2 conformance provides the technical foundation for the following regulatory claims:

EU AI Act — Article 12 (Record-Keeping, High-Risk AI Systems)

EU AI Act — Article 14 (Human Oversight, High-Risk AI Systems)

NIST AI RMF — GOVERN, MAP, MEASURE, MANAGE

NIST CSF 2.0 — IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER

A full regulatory compliance matrix is available in the ACS Standard Section 16.

ACS was designed with a comprehensive threat model covering planning-layer reconnaissance, schema injection bypass, execution contract forgery, audit log tampering, and authorization revocation races.

Full threat model is available in the ACS Standard Section 12. Design principles are normative and serve as tie-breakers for all implementation decisions. Key security properties include:

Named threats covered:

• T1 - Planning-Layer Capability Enumeration
• T2 - Unauthorized Capability Visibility via Schema Injection
• T3 - Execution Contract Forgery
• T4 - Audit Log Tampering
• T5 - PAEP Bypass via Alternative Context Injection
• T6 - CID Namespace Collision
• T7 - Capability Inference from Authorized Summary Set
• T8 - Execution Contract Replay Attack
• T9 - Provider Identity Leakage via Error Messages
• T10 - Stale Execution Contract After Authorization Revocation

The ACS specification and all reference materials are released under the Apache License 2.0. The standard is open, royalty-free, and vendor-neutral. Organizations are encouraged to adopt, implement, reference, and build upon it.

Future ACS extensions planned:

• ACS v1.1 Routing Benchmark - an independently reproducible benchmark for T-ROUTING conformance testing across standardized goal-state descriptions and DOMAIN_TAG values
• EU AI Act Compliance Companion - a formal compliance mapping document for ACS Level 2 against EU AI Act Title III requirements
• NIST AI RMF Companion - a formal compliance mapping document for NIST AI RMF GOVERN, MAP, MEASURE, MANAGE function alignment
• Multi-Agent Delegation Extension - CID-scoped delegation chains for agent-to-agent capability handoff, developed in coordination with the A2A specification
• ACS Registry Protocol - standardized federation of ACS Capability Summary Indexes across organizations, building on existing MCP registry infrastructure

ACS is an open initiative. The standard is published as a Draft for Public Comment and the community's input will shape its evolution.

The project welcomes:

• Feedback on the specification - technical review, edge case analysis, implementation experience across MCP deployments of varying scale
• AMG implementations - reference implementations of Automated Manifest Generation for MCP, OpenAPI, and A2A sources
• PAEP integrations - OPA policy libraries, AWS Cedar policy sets, and custom policy engine integrations for common enterprise authorization models
• ACS Runtime implementations - open-source ACS Runtime SDKs in major languages and frameworks
• Conformance test contributions - help complete and extend the T-TOKEN through T-INTEROP test suite
• Regulatory and compliance analysis - additional framework mappings, jurisdiction-specific guidance, sector-specific GOVERNANCE_TAGS extensions
• Ecosystem tooling - audit dashboards, SIEM integrations, PAEP policy editors, capability inventory management tools, AMG review workflow tooling

The goal is to establish ACS as the standard capability routing and governance layer for LLM-based agent deployments; so that every enterprise AI system, compliance platform, and human oversight mechanism has a single, reliable, interoperable interface for governing what capabilities an agent can see and use.