Skip to main content
The Project MCP server gives MCP clients a semantic, permission-checked way to inspect and change Aion Projects. It works with the Ions in a Project graph. Every change is a two-step operation. A mutation tool first returns a preview. The caller reviews that preview and then calls project_config_confirm_mutation to apply it. The server does not expose raw collaborative-document mutations.
The Project MCP server and the Project Configuration Agent are separate surfaces. Direct MCP clients call the tools described here. The hosted agent interprets natural-language requests and selects the same tools on behalf of its authenticated caller. Both paths enforce the caller’s current permissions.

Before you begin

You need:
  • an active Aion organization;
  • access to the Global catalog under Resources > MCP Servers;
  • permission to execute the Project MCP capability;
  • the resource permissions required by each Project operation;
  • the UUID of an existing Project for Project-scoped operations.
See MCP Servers for OAuth, personal API-key, deployment credential, and client configuration guidance.

Enable and connect

  1. Open Resources > MCP Servers.
  2. Select Global.
  3. Find Aion Project Configuration and turn on Enabled.
  4. Open the server and select Usage.
  5. Choose Direct server, then copy the generated endpoint and configuration for your MCP client.
  6. Connect the client and verify that tools/list includes project_config_inspect.
The server is organization-managed and authenticated. It does not use a fixed public endpoint.

How changes work

Use this workflow for Project creation, Project deletion, and graph changes:
  1. Inspect the current Project.
  2. Call a mutation tool to create a preview.
  3. Review the preview’s summary, affected resources, required permissions, validation issues, target hash, and expiry.
  4. Ask the user to approve the proposed change.
  5. Call project_config_confirm_mutation with the preview’s operationId and confirm: true.
  6. Check the returned operation status. Retry the same confirmation when the operation is still accepted or pending.
Unconfirmed previews expire after 30 minutes. Confirmation rechecks authorization and verifies that the Project still matches the previewed baseline. If the Project changed, inspect it again and create a new preview. Mutation tools accept optional request metadata: Reusing a requestId for the same normalized request returns the existing operation. Reusing it for different input returns request_id_conflict.

Inspect a Project

Call project_config_inspect before proposing a change:
The response includes:
  • Project metadata without collaborative-document state;
  • ionsByType, with Ion labels, positions, safe attributes, and persisted entity references;
  • directed edges and ordered Sequence paths;
  • graph validation issues and environment names;
  • availableIonCreationActions, containing the actions available to the caller;
  • operations supported by the caller’s current Project permissions.
The inspection projection excludes capability authentication, secrets, attachment payloads, attachment runtime overlays, and arbitrary editor data.

Preview an Ion addition

First call project_config_list_ion_creation_actions with the Project UUID:
Each returned descriptor identifies the action ID, produced ionType, parameter schema, additional authorization actions, and interaction hint. Use the returned schema rather than hard-coding the available actions; availability can depend on the caller and installed Aion modules. Then call project_config_add_ion with one returned action:
Supply every required value from the selected action’s parameters descriptor. The response is a preview, not a persisted change. Review these fields before confirmation: Do not confirm a preview when canApply is false.

Confirm the preview

After the user approves the preview, call:
Confirmation can report Accepted, Pending, Committed, or ExecutionFailed. A committed response can include the resulting Project checkpoint UUID. A terminal failure includes a stable code, a safe message, and whether the operation is retryable. Calling confirmation again with the same operation UUID recovers the durable outcome when the initial response was lost or execution was still pending. It does not create a second mutation.

Preview a batch

Use project_config_preview_change when later commands depend on Ions added earlier in the same change. Each command must define exactly one of addIon, connectIons, or updateIonConfig. This example adds an existing Behavior Ion and connects an existing Distribution Ion to it:
An Ion reference must define exactly one of:
  • existingIonId for an Ion already in the Project; or
  • addedByCommandId for an Ion produced by an earlier command in the batch.
Assign a UUID commandId when a later command needs to reference the added Ion. The entire ordered batch receives one preview and one confirmation.

Tool reference

All mutation tools in this table create previews. Only project_config_confirm_mutation can apply a preview. The MCP capability also requires execution permission. Ion-creation actions can add more specific requirements, such as permission to read a selected behavior or create a Deployment. The server publishes static requirements in the tool’s aion.authorization annotation and resolves request-specific targets before preparation.

Project creation

project_config_create_project accepts:
  • required organizationId and projectName;
  • optional description and environmentName;
  • optional request metadata.
It allocates the Project identity during preview. The Project is not persisted until confirmation succeeds.

Project deletion

project_config_delete_project requires projectId and confirmedProjectId to contain the same Project UUID. This explicit acknowledgement creates a deletion preview; the preview still requires a separate confirmation call.

Ion configuration

project_config_update_ion_config applies a closed patch to supported non-auth configuration variables on Behavior and Distribution Ions:
  • set inserts or replaces key-value pairs;
  • remove deletes keys;
  • the same key cannot appear in both collections;
  • at least one key must be set or removed.
Capability authentication, secret fields, and identity selection are not supported through this tool.

Common errors

Errors use structured MCP output:

Security and attribution

  • Direct OAuth and personal API-key calls are authorized as their authenticated user.
  • Deployment and agent calls are authorized as the resolved Identity selected by the trusted Aion runtime context.
  • Agent-mediated A2A calls require an authenticated caller and cannot fall back to the hosted daemon’s authority.
  • Cross-organization Project access is rejected even when the MCP server is globally visible.
  • Project checkpoints are attributed to the user or Identity whose permissions authorized the change.

What to do next

  • Use MCP Servers to configure a direct client or an Aion deployment.
  • Review Roles & Permissions for Project reach and Identity assignments.
  • Open Composer to inspect the resulting Project graph and checkpoint history.