Skip to main content
MCP resources are the MCP server bindings available to a user in Aion. The Resources > MCP Servers screen shows those bindings as a read-only catalog. Each card represents one effective MCP server route, including the capability key, binding scope, related project information when applicable, and the runtime MCP path. Tool schemas are loaded only when you inspect a specific resource. Control-plane MCP resources are marked on their cards.

​
Control Plane And Project Resources

Control-plane MCP resources are platform surfaces provided directly by Aion. They do not need to be created in a project, do not require an agent identity to authenticate, and usage is attributed to the Aion user who authenticates. The MCP Servers screen shows these resources by default through the Aion filter toggle. Turning that toggle off hides them. Project-backed MCP resources are derived from project environments, distributions, and enabled capability configuration. Aion does not create a separate MCP resource record for the catalog. Project-backed MCP resources use the daemon.execute permission. Daemon, principal, and personal agent identities are evaluated through their effective daemon.execute scopes. When an MCP resource is routed through a distribution, authorization still targets the distribution’s backing agent environment.

​
Identity Visibility

The Visibility card can evaluate the catalog from the point of view of a selected agent identity. When an identity is selected, Aion narrows project-backed MCP resources to the identity’s effective daemon.execute grants. The response also includes structured explanation data with:
  • grants, including the action key, role key, role label, scope kind, scope id, scope label, and related project metadata when available
  • environmentAnchors, including the project ids, names, environment labels, project resource URIs, anchor kind, and concrete anchor URI used for organization-wide environment matching
  • references, a normalized list of resources mentioned by the explanation
Clients render their own explanation text from those structured fields. The references collection uses abstract Aion resource URIs such as aion://permission/daemon.execute, aion://role/organization_project_agent_isolated, or aion://project/PROJECT_ID. These are not HTTP URLs. Clients can resolve them into their own application routes. For organization-wide grants, clients should describe the rule in terms of the identity’s role, organization, and matching project environment names instead of listing every matching project. Project anchor metadata remains available through environmentAnchors for clients that need details. Anchor kinds identify whether the identity is assigned as an agent-environment daemon or as a distribution principal. Supported resource URI shapes include:
  • aion://system
  • aion://permission/{actionKey}
  • aion://role/{roleKey}
  • aion://organization/{organizationId}
  • aion://project/{projectId}
  • aion://agent/environment/{agentEnvironmentId}
  • aion://agent/identity/{agentIdentityId}
  • aion://agent/identity/name/{atName}
  • aion://distribution/{distributionId}
GraphQL principal selector arguments use the same nullable resource URI string shape. When omitted, Aion uses the authenticated subject as the principal.

​
Project And Environment Filters

The project selector starts with no selected project. In that state, the screen shows only control-plane MCP resources unless another filter is selected. Users can select one project or choose Show all projects. Because many organizations use separate projects for development, staging, and production, the screen also provides an environment-name filter. The filter is derived from the unique environment names used by visible projects in the organization. The environment selector also starts with no selected environment. Users can select one environment or choose Show all environments. Environment names are labels, not lifecycle metadata. Aion does not mark a project as production because its project name contains prod, and it does not add an official production flag for MCP resource listing. This filter uses the project’s environment label. It is separate from an agent environment’s runtime configuration and name.

​
Organization-Wide Discovery

Organization-wide capability discovery is filtered by project environment. This applies generally to capabilities, including MCP server capabilities. Behavior inclusion uses the same project-environment rule for organization-shared behavior deployments. When a daemon looks up an MCP server in another project in the organization, Aion shows that server only if the daemon’s project and the target project have the same project environment. A production daemon in a production project cannot discover test project MCP servers, and a test daemon cannot discover production project MCP servers. If a selected identity has organization-level daemon.execute but is not associated with any project environment, Aion does not infer a production environment. The organization-level grant is not environment-limited in that case. Teams that rely on cross-project daemon discovery should use consistent project environment labels across related projects. Blank, custom, or inconsistent labels are treated as user-owned labels, not lifecycle states.

​
Distribution Identities

MCP resources can be backed by distribution targets when the capability is available through a distribution. Aion keeps existing identity uniqueness constraints for distributions. If you need parallel test and production distributions for the same network type, use separate test identities instead of reusing the same principal or service identity.

​
Tool Listing

The catalog grid does not load every MCP tool schema automatically. Selecting a resource loads the tools advertised by that MCP server. This keeps the catalog fast for organizations with many projects and avoids calling every runtime MCP server just to render the grid.