JSON Schema cross-field rules, _meta namespace enforcement, schema
tightenings, and Appendix A completion. Still within the 2.0 draft window;
the schema additions reject shapes the spec text already forbids and the spec
edits are editorial or additive.
@afps-spec/schema@2.0.5)generate.ts injects JSON Schema 2020-12
if/then/anyOf/oneOf/minProperties so JSON-only validators reject the
same shapes Zod rejects: auths ≥1 entry; oauth2 requires issuer or both
endpoints; credentials.schema required for api_key/basic/mtls/custom;
connect only on type: custom with exactly one of login/tool; delivery
≥1 channel with http mutually exclusive of env/files; server.type: "uv"
requires manifest_version: "0.4"._meta key validation (§10.1 + Appendix B META_NAMESPACE_KEY) — keys
must match the namespaced-key pattern and MUST NOT use the MCP-reserved mcp
/ modelcontextprotocol prefixes; values remain constrained to JSON objects.
Bare names and the dev.appstrate.afps/ transitional alias are accepted._meta permitted on the input/output/config schema wrappers (§10) while
keeping the rest of each wrapper closed.user_config entries are now typed (type ∈ string/number/boolean/
directory/file, plus title/description/required/default/multiple/
sensitive/min/max) instead of an opaque record.token_endpoint_auth_method widened to the full RFC 7591 / OIDC set
(client_secret_jwt, private_key_jwt, tls_client_auth,
self_signed_tls_client_auth added) — the spec wording was already open.issuer/authorization_endpoint/
token_endpoint/userinfo_endpoint and source.remote.url (SSRF surface).AUTH_KEY_REGEX now applied to tools_policy.<name>.required_auth_key
and the deprecated integrations_configuration.<id>.auth_key._meta["dev.afps/mcp-server"] contract.integration.source.kind:"local" → mcp-server nesting; dropped the
“an mcp-server manifest is an MCPB manifest” / “.mcpb rename works” claims that
contradicted §2.5/§3.4 (also corrected the §1.3 glossary entry).dependencies: documented both compact and object dependency forms.prompt.md.integrations_configuration map as canonical; per-field merge precedence.token_endpoint_auth_method value list expanded to match the schema.prompt.md, server.entry_point/mcp_config,
source.{server,remote} sub-fields, all delivery.{http,env,files} leaf
fields, and connect.login.{expires_in_output,identity_outputs} /
connect.{tool,limits}; clarified the _meta scope.examples/integration-local-mcp (source.kind:”local” + env delivery).agent-full: auth_key added to the gmail dependency entry.integration-oauth2: →.Schema tightenings + §7.6 editorial correction. No spec breaking changes: both schema tightenings reject shapes the spec text already forbids; the §7.6 edit aligns the prose with the worked example (and with RFC 7617).
@afps-spec/schema@2.0.4)connect.login.outputs AFPS-extractor variant (§7.7) — the loose
{ from: <any-string> } shape is replaced by a discriminated union over
from ∈ "cookie" | "jwt" | "regex", each variant requiring its
spec-mandated fields (cookie: name; jwt: token, path; regex:
source, pattern, optional non-negative integer group). Producers can
no longer smuggle non-spec extractor shapes through the schema.mcp-server.manifest_version (§3.4 + Appendix A) — format constraint
^\d+\.\d+$ is now enforced. The recommended values 0.3 (baseline) /
0.4 (required when server.type === "uv") remain a soft recommendation
(the uv ⇒ 0.4 cross-field rule continues to be enforced by
superRefine); the hard format check rejects shapes like "1",
"0.3.1", "abc", and the empty string.v2/integration.schema.json and v2/mcp-server.schema.json
from the updated Zod source.manifest_version regex (0.3, 0.4, 1.0 accepted;
"1", "abc", "", "0.3.1" rejected).encoding: "base64" is applied to
the rendered value only (NOT to prefix+value), with the encoded result
concatenated after prefix. This matches the worked HTTP Basic example
per RFC 7617 and resolves the internal contradiction between the prose
and the example. No normative behaviour change for implementations that
already followed the example.README.md — removed dead link to non-existent packages/platform-tools/;
added §7 integration-authentication metadata to the Scope bullets so the
v2.0 auth model (OAuth2/OIDC discovery, credential delivery, connect,
per-tool policy, URI restrictions, setup-guide) is surfaced on the
landing page.packages/README.md — refreshed stale “AFPS 1.3+ protocol” wording to
“AFPS 2.0 contracts” and bumped release-tag examples to current versions
(afps-types@2.0.0, afps-schema@2.0.3).Breaking refactor of the mcp-server package type + rename of integration
per-tool policy field. AFPS 2.0 is still flagged Draft in spec.md; this
revision lands while the draft window is open. Producers that emitted
mcp-server or integration manifests under v2.0.0/v2.0.1 must migrate.
mcp-server manifest is now AFPS-native at the
root. Top-level fields are the same as for agent/skill/integration:
scoped name, type: "mcp-server", schema_version, common metadata,
optional dependencies. The manifest_version, server, tools, and
user_config fields continue to adopt the MCPB vocabulary verbatim..afps → .mcpb runs in any MCPB host”
invariant. AFPS no longer claims strict-MCPB interoperability; a
publish-time projection to a strict MCPB bundle is reserved for a future
minor (§10.2).dependencies is a top-level field for all four package types
(the previous _meta["dev.afps/mcp-server"].dependencies placement is
removed).schema_version applies to mcp-server (was previously declared
not applicable).mcp-server special-case annotations on
name, type, author, repository, compatibility, dependencies,
schema_version.integration.tools renamed to
integration.tools_policy to disambiguate from mcp-server.tools
(the two had the same field name but distinct shapes — a sparse policy
table vs an advisory catalog). All sub-fields (required_scopes,
required_auth_key, url_patterns) and semantics are unchanged.@afps-spec/schema@2.0.2)mcpServerManifestSchema rewritten on top of the shared commonFields
shape; no longer enforces _meta["dev.afps/mcp-server"].mcpServerAfpsMeta export removed (no replacement; AFPS identity is now the
top-level name).A v2.0.0 / v2.0.1 mcp-server manifest of the form
{
"manifest_version": "0.3",
"name": "fetch-json",
"version": "1.0.0",
"server": { ... },
"_meta": { "dev.afps/mcp-server": { "name": "@example/fetch-json", "type": "mcp-server" } }
}
migrates to
{
"name": "@example/fetch-json",
"version": "1.0.0",
"type": "mcp-server",
"schema_version": "2.0",
"manifest_version": "0.3",
"server": { ... }
}
(scoped name lifted from _meta to the root; type and schema_version
added; the _meta AFPS-identity block deleted).
Post-release clarifications and corrections from the SOTA alignment audit
(claudedocs/spec-audit-2026-05-26.md). No breaking-by-design changes; one
default value corrected to match the upstream RFC, one additive auth type.
mcp-server packages,
dependencies MUST live under _meta["dev.afps/mcp-server"].dependencies
(the MCPB schema forbids unknown top-level fields). Producers MUST NOT emit a
top-level dependencies field on an mcp-server manifest.author, repository) — annotated the rows to note that the
object form is the only valid shape on mcp-server (MCPB schema rejects the
string shorthand).compatibility) — annotated the row to note that on
mcp-server the field follows the MCPB strict shape
({ claude_desktop?, platforms?, runtimes? } with python/node runtimes
only); the AFPS-extended clients? map applies to agent/skill/integration
only.token_endpoint_auth_method default
realigned to client_secret_basic per RFC 8414 §2 and [RFC 7591] §2.
Previously listed client_secret_post, which contradicted the RFC default.type: "mtls" for
mutual TLS client authentication. credentials.schema is REQUIRED and
SHOULD describe the client certificate, private key, and optional chain.
Maps to OpenAPI mutualTLS (3.1+).@afps-spec/schema@2.0.1)authTypeEnum adds "mtls".tokenEndpointAuthMethodEnum order changed to list "client_secret_basic"
first (cosmetic; the enum members are unchanged).refineAuthMethod now requires credentials.schema for mtls.mtls.Major, breaking revision. AFPS 2.0 adopts a snake_case field vocabulary across all package types, replaces the tool and provider package types with mcp-server and integration, and adopts the Model Context Protocol _meta mechanism as the single extension point.
agent, skill, mcp-server, integration. tool and provider are removed; 2.0 producers MUST NOT emit them. See Appendix D for the 1.x→2.0 migration mapping.mcp-server (§3.4) — an entirely new model: an mcp-server manifest is a verbatim MCP Bundle (MCPB) manifest. A built mcp-server validates against the MCPB manifest schema and runs unmodified in any MCPB host (rename .afps → .mcpb). Supersedes the 1.x tool type.integration (§3.5, §7) — supersedes the 1.x provider type. Adds an explicit capability source (local / remote / api), a multi-method auths map, discovery-first OAuth2 using RFC 8414 / OpenID Connect Discovery vocabulary (RFC 8707 resource indicators, RFC 7636 PKCE), a scope_catalog, declarative connect.login acquisition aligned with OpenAPI Arazzo, and explicit credential delivery (http / env / files).snake_case (e.g. display_name, schema_version, integrations_configuration). Embedded JSON Schema keywords (e.g. contentMediaType) retain their standard spelling.x- extension convention is removed in favor of a top-level _meta object with reverse-DNS namespaced keys (dev.afps/…). _meta is the only schema-blessed extension point for mcp-server packages, whose MCPB manifest schema forbids unknown top-level fields.dependencies.providers → dependencies.integrations; dependencies.tools → dependencies.mcp_servers. Agent providersConfiguration → integrations_configuration.schema members; the only AFPS constraint is the container shape (type: "object" + properties).@afps-spec/schema@2.0.0)v2/ schemas: agent, skill, mcp-server, integration. mcp-server.schema.json validates the embedded MCPB manifest.$id pattern: https://afps.appstrate.dev/packages/schema/v2/<type>.schema.json.x- convention).definition.uploadProtocols, an OPTIONAL array declaring the resumable upload protocols a provider’s API supports. Closed enum: google-resumable, s3-multipart, tus, ms-resumable. Consumers MUST reject manifests declaring values outside the enum. New protocols require a minor version bump.definition.uploadProtocols row.uploadProtocols remain valid; the field’s absence MUST be treated as “no resumable upload capabilities declared”.@afps-spec/schema@1.5.0)providerDefinition gains uploadProtocols optional field (UploadProtocol[] with closed 4-value enum and uniqueItems).uploadProtocolEnum.v1/provider.schema.json.@afps-spec/schema@1.4.0) — 2026-04-25packages/schema/. The hosted $id follows: https://afps.appstrate.dev/schema/v1/<type>.schema.json → https://afps.appstrate.dev/packages/schema/v1/<type>.schema.json.v1/{agent,skill,tool,provider}.schema.json with the new $id.examples/*/manifest.json $schema references.$id over the network MUST update; consumers that bundle @afps-spec/schema will pick this up via the npm version bump.$id is observable to strict validators even though the schema content is unchanged.definition.credentialEncoding and its associated enum entirely. The field had been introduced as an experimental closed enum in v1.0.2 and deprecated in v1.1.0 in favor of the generic credentialTransform. It is removed now because it had zero production adoption and keeping a deprecated parallel pathway in the spec added no value.credentialEncoding row.credentialEncoding MUST migrate to credentialTransform. The two standard patterns translate as:
basic_api_key_x → credentialTransform: { template: ":X", encoding: "base64" }basic_email_token → credentialTransform: { template: "/token:", encoding: "base64" }@afps-spec/schema@1.3.1)providerDefinition no longer accepts credentialEncoding.credentialEncodingEnum export removed from @afps-spec/schema.schema/v1/provider.schema.json.definition.credentialTransform ({ template, encoding }) as the successor to the fixed credentialEncoding enum. Manifests now express provider-specific Basic-auth conventions directly (e.g. Freshdesk/Teamwork { template: ":X", encoding: "base64" }, Zendesk { template: "/token:", encoding: "base64" }) instead of relying on hard-coded runtime enum values. Adding a new vendor convention no longer requires bumping the spec — only a new encoding does.credentialEncoding is deprecated but retained in the schema for backward compatibility. Consumers MAY continue to honor it; new manifests SHOULD use credentialTransform. When both are present, credentialTransform takes precedence.credentialTransform, credentialTransform.template, credentialTransform.encoding; marked credentialEncoding deprecated.credentialEncoding still validate and still work on every conforming consumer.@afps-spec/schema@1.3.0)providerDefinition gains credentialTransform optional field ({ template: string, encoding: "base64" }).credentialTransform Zod schema and credentialTransformEncodingEnum.schema/v1/provider.schema.json.definition.oauth2:
tokenAuthMethod (client_secret_post |
client_secret_basic) — selects how OAuth2 client credentials are sent on the token endpoint per RFC 6749 §2.3.1. |
tokenContentType (application/x-www-form-urlencoded |
application/json) — selects the body encoding of token endpoint requests. application/json enables interoperability with providers like Atlassian whose token endpoints do not accept form-urlencoded bodies. |
definition.credentialEncoding field for api_key providers, with two standard values (basic_api_key_x, basic_email_token) covering the Freshdesk/Teamwork and Zendesk Basic-auth patterns.@afps-spec/schema@1.2.2)oauth2Config gains tokenAuthMethod and tokenContentType optional fields.providerDefinition gains credentialEncoding optional field.oauthTokenAuthMethodEnum, oauthTokenContentTypeEnum, credentialEncodingEnum.schema/v1/provider.schema.json.flow renamed to agent — the "type": "flow" value in manifests is now "type": "agent". This better reflects the package’s role as an autonomous agent definition. All schema files, examples, and spec text updated accordingly.schema/v1/flow.schema.json replaced by schema/v1/agent.schema.jsonflowManifestSchema renamed to agentManifestSchema in Zod sourceexamples/flow-full/ renamed to examples/agent-full/examples/flow-minimal/ renamed to examples/agent-minimal/Initial release of the Agent Format Packaging Standard (AFPS) v1.0.
spec.md) — 11 sections, 4 appendicesprimer.md) for newcomersagent — complete workflow with prompt.md, dependencies, input/output/config schemas, timeoutskill — reusable instructions (SKILL.md), superset of Agent Skills formattool — single callable capability with entrypoint and tool interface declarationprovider — service connector with auth mode, OAuth endpoints, credential schemaschema/v1/@afps-spec/schema npm package)https://afps.appstrate.dev/schema/v1/<type>.schema.jsonschemaVersion field enforces major version compatibilitydependencies field with skills, tools, and providers maps (semver ranges).afps file extension convention for package archives (standard ZIP)afps.appstrate.dev