Existing proposals
Problem
Agent Zero needs a safe and portable way to extend an agent with repository-specific instructions, reusable skills, and external tools without hard-coding those capabilities into the core runtime. Today skills can exist in the repository, but there is no complete configuration model for selecting, enabling, disabling, discovering, or constraining them, and no first-class MCP configuration layer for built-in or user-added servers.
Parent roadmap: #5
Desired outcome
Deliver a configurable extension layer for Agent Zero covering both Agent Skills and Model Context Protocol (MCP) servers.
Configurable skills
- discover repository-local and installed Agent Skills
- configure which skills are enabled for a repository, project, task type, or agent role
- support explicit allow/deny lists and deterministic precedence
- allow skills to declare metadata, capabilities, required tools, and compatibility requirements
- validate skill configuration before task execution
- expose active skills in task metadata and diagnostic output
- allow skills to be installed/updated independently from the Agent Zero core where practical
- keep skill instructions versionable with the repository
- prevent an untrusted repository skill from silently expanding execution permissions
Preconfigured MCP servers
Ship a curated configuration model for commonly useful MCP integrations, with adapters/presets where appropriate for capabilities such as:
- source-control and repository tooling
- documentation and library context
- issue/project management
- observability and deployment tooling
- browser/web tooling where explicitly enabled
Preconfigured MCPs should be opt-in when they require credentials or external access. Agent Zero should provide sensible metadata and setup requirements rather than embedding user secrets.
User-added MCP servers
- allow users and repositories to register additional MCP servers declaratively
- support local/stdio and remote transports where supported by the MCP ecosystem
- configure commands, endpoints, environment-variable references, scopes, timeouts, and enabled state
- support per-repository and deployment-level MCP configuration
- discover server capabilities/tools before exposing them to an agent
- expose MCP health and connection diagnostics
- allow individual MCP tools to be allowlisted or denied
- provide a clear distinction between trusted administrator MCPs and repository-requested MCPs
- make MCP configuration portable without committing credentials
Runtime integration
- introduce a provider-neutral tool registry combining native Agent Zero tools, skills, and permitted MCP tools
- expose only capabilities authorized for the current task and repository policy
- record which skill or MCP tool was used as part of task evidence/audit events
- fail explicitly when a required skill or MCP capability is unavailable
- keep MCP and skill implementation details outside the core reasoning/state-machine contracts where possible
Likely area
Agent runtime
Safety and compatibility
High impact. Skills and MCP servers can introduce instructions, network access, filesystem access, credentials, or arbitrary tools. Repository-controlled configuration must never be able to grant itself privileges that the deployment or user has not authorized. Secrets must be referenced through secure configuration and must not be written to repository files, task logs, or model prompts unless explicitly required and safely scoped.
Every MCP tool should have an explicit trust/capability classification. Tool calls must remain subject to Agent Zero policy, observe/fix mode, approval gates, sandbox boundaries, timeouts, and audit logging. A malicious skill or MCP description must be treated as untrusted input rather than as authority to bypass these controls.
Alternatives considered
Hard-coding integrations directly into the agent runtime was rejected because it would make Agent Zero difficult to extend and couple releases to third-party services. Automatically enabling every discovered MCP or skill was rejected because discovery is not authorization. A declarative, capability-aware registry with explicit policy and trust boundaries is preferred.
Existing proposals
Problem
Agent Zero needs a safe and portable way to extend an agent with repository-specific instructions, reusable skills, and external tools without hard-coding those capabilities into the core runtime. Today skills can exist in the repository, but there is no complete configuration model for selecting, enabling, disabling, discovering, or constraining them, and no first-class MCP configuration layer for built-in or user-added servers.
Parent roadmap: #5
Desired outcome
Deliver a configurable extension layer for Agent Zero covering both Agent Skills and Model Context Protocol (MCP) servers.
Configurable skills
Preconfigured MCP servers
Ship a curated configuration model for commonly useful MCP integrations, with adapters/presets where appropriate for capabilities such as:
Preconfigured MCPs should be opt-in when they require credentials or external access. Agent Zero should provide sensible metadata and setup requirements rather than embedding user secrets.
User-added MCP servers
Runtime integration
Likely area
Agent runtime
Safety and compatibility
High impact. Skills and MCP servers can introduce instructions, network access, filesystem access, credentials, or arbitrary tools. Repository-controlled configuration must never be able to grant itself privileges that the deployment or user has not authorized. Secrets must be referenced through secure configuration and must not be written to repository files, task logs, or model prompts unless explicitly required and safely scoped.
Every MCP tool should have an explicit trust/capability classification. Tool calls must remain subject to Agent Zero policy, observe/fix mode, approval gates, sandbox boundaries, timeouts, and audit logging. A malicious skill or MCP description must be treated as untrusted input rather than as authority to bypass these controls.
Alternatives considered
Hard-coding integrations directly into the agent runtime was rejected because it would make Agent Zero difficult to extend and couple releases to third-party services. Automatically enabling every discovered MCP or skill was rejected because discovery is not authorization. A declarative, capability-aware registry with explicit policy and trust boundaries is preferred.