> ## Documentation Index > Fetch the complete documentation index at: https://docs.aion.to/llms.txt > Use this file to discover all available pages before exploring further. # MCP Resources > How Aion lists MCP server bindings across control-plane and project filters. 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. Most require `control_plane_capability.list` to discover and `control_plane_capability.execute` to use. The metatools MCP server is the permissionless exception so agents can search the visible MCP catalog and execute visible project-scoped MCP tools. The MCP Servers screen shows visible control-plane 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 permissionless control-plane MCP resources plus any permissioned control-plane MCP resources the selected principal may list. 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.