AI-Native SDK Model · Developers Hub

MyronCMS is AI-native because its runtime treats AI as a scoped operator client, not as a separate automation layer. Extension authors and AI tool builders should understand three primitives before documenting or building against the SDK:

operator actions as tools,
manifest as discovery,
AI as user with role.

Together, those primitives keep the system deterministic. AI clients discover what the running install can do, call registered actions with declared schemas, and operate only through scopes an operator granted.

Human Path

A developer designs an extension or integration around MyronAction contracts. Each action declares:

a versioned URI,
method,
domain, resource, and verb,
input and output schemas,
required scope,
summary,
side effects,
preconditions and postconditions,
MCP exposure and snapshot metadata when relevant.

The developer should treat action metadata as the source of truth for runtime behavior. Documentation explains the contract and safe patterns, but the running install reports its actual surface through manifest and MCP discovery.

AI Path

There are two AI paths:

AI role	What it can do	Current route
AI coding agent in the repository	Author local files, update extension packages, and run verification commands.	Local file authoring under the approved contract.
Installed MCP/API client	Discover and call loaded, exposed, scope-allowed actions in a running install.	`/api/v1/manifest`, MCP `tools/list`, `tools/call`, `resources/list`, and `resources/read`.

An installed MCP client cannot create PHP files under app/extensions/{vendor}/, register itself, grant itself scopes, or bypass the dispatcher. It can call what the operator made available through scopes and action exposure.

Operator Actions As Tools

An operator action is a deterministic API operation the system already understands. The action code runs service-layer behavior and returns a canonical envelope. MCP tools/call delegates to the same dispatcher used by direct /api/v1/... calls, so authentication, scope checks, validation, audit binding, and rate limiting stay shared.

Do not document an AI workflow as "generate PHP and run it in the CMS" for a live install. The supported runtime path is "call an action." Code generation belongs to local-authoring workflows under an explicit development contract.

Manifest As Discovery

The manifest is the live action catalog. AI clients should read the running install instead of relying on copied lists from docs:

GET /api/v1/manifest
MCP tools/list
MCP resources/list

Docs should name contracts, examples, and discovery routes. They should not maintain static lists of every current tool, because installed actions and caller scopes can differ by site.

AI As User With Role

An AI integration is a caller with held scopes. MyronActionCallerContext carries caller type, caller id, and held scope list into every action. The dispatcher checks the action's requiredScope before the action runs.

Base scopes include:

Scope	Meaning
`design.read`	Read design surfaces.
`design.write`	Mutate design surfaces.
`content.read`	Read content surfaces.
`content.write`	Mutate content surfaces.
`administration.read`	Read administration surfaces.
`administration.write`	Mutate administration surfaces.

Sub-scopes can be covered by base scopes through namespace inclusion. For example, a base write scope can cover a same-domain write sub-scope when source code declares that relation through MyronApiScopes::covers().

Scopes

This concept page has no runtime scope requirement. Runtime calls use the scope declared by each action. MCP tool discovery is filtered by caller scope and exposeToMcp.

Extension packages also have a separate grant gate: the extension must be registered, enabled, and granted its manifest scopes before its actions load.

Artifacts

Primary source contracts:

app/system/api/Action.php
app/system/api/ActionRegistry.php
app/system/api/ActionDispatcher.php
app/system/api/Scopes.php
.amphion/control-plane/architecture-log/ai-native-enablement-2026-05-10.md
.amphion/control-plane/architecture-log/full-parity-mcp-2026-05-10.md

Runtime discovery surfaces:

/api/v1/manifest
MCP tools/list
MCP resources/list

Safety Boundary

Do not document authorization failures as something an AI should solve by creating, rotating, revoking, or expanding its own integration. Trust gates are operator-controlled.

Do not document marketplace installation, dependency resolution, code signing, sandbox isolation, public render hooks, or extension snapshot contribution as current AI-native SDK behavior. Those are outside extension v1 unless a later contract changes the platform.

Verification

For documentation review:

Check that a page names the human workflow.
Check that it names either a runtime AI path, a local-authoring AI path, or an explicit parity gap.
Check that runtime claims point to source contracts and live discovery.
Check that scope and grant boundaries are not blurred.
Check that unsupported surfaces are marked future, prohibited, or parity gap.

For runtime discovery, use the running install:

GET /api/v1/manifest
MCP tools/list
MCP resources/list

Failure Modes

Failure	Likely cause	Safe response
Docs list a tool that is absent from `tools/list`	Caller lacks scope, action is hidden, or the copied list is stale.	Re-read live discovery and document the contract instead of a frozen list.
AI workflow says to edit extension files through MCP	Local authoring and installed MCP operation were mixed.	Move file edits to local-authoring instructions.
Runtime action is described without a scope	Documentation skipped the caller gate.	Add the required action scope or mark the route as public only when source says so.
AI is told to broaden its own grants	Trust-gate boundary was violated.	Route grants through operator/admin workflows.
Future marketplace behavior reads as current	Support status is wrong.	Mark future-planned or prohibited-current and defer implementation to a new MCD cycle.