# Plugins: adding tools and lifecycle hooks > Atlas plugins contribute tools the agent can call and hook into agent lifecycle events, extending behavior without changing Atlas itself. Atlas plugins extend the agent in 2 ways. They contribute tools, new capabilities the model can call alongside the built-in ones, and they hook into lifecycle events, running your code at defined points as a session proceeds. Together that covers both what the agent can do and what happens around it, without modifying Atlas itself. ## Key takeaways - Plugins add tools the agent can call, alongside the built-in set. - Lifecycle hooks run your code at defined points during a session. - Plugin-contributed tools are permission-gated like every other tool. - MCP servers cover the adjacent case of connecting existing systems. ## Two extension points, not one Most tools offer 1 extension point and force everything through it. Atlas separates contributing a tool, which changes what the agent is able to do, from hooking a lifecycle event, which changes what happens around what it does. The split matters because the two have different shapes. Adding a deployment command is a tool: the model decides when to call it. Recording every session to an internal audit system is a hook: nobody wants the model deciding whether auditing happens. Collapsing both into one mechanism means one of them ends up modeled badly. ## Plugin tools are still permission-gated A tool contributed by a plugin passes through the same allow, ask, or deny check as the 1st-party ones. Installing a plugin does not create a path around the permission system, and unmatched actions still default to ask. This is what makes third-party extension safe to adopt. The safety properties of Atlas are enforced at the tool-call boundary rather than inside each tool, so they apply uniformly to code the Atlas team did not write. A plugin can add capability; it cannot quietly add authority. ## Plugins or MCP servers The 2 mechanisms answer different questions. Write a plugin when you want to change how Atlas itself behaves. Use a Model Context Protocol server when you want to connect Atlas to a system that already exists and may serve other clients too. MCP is the better choice for anything with an existing API surface, because the server you write is reusable beyond Atlas. Plugins are the better choice for behavior that is specific to how your team runs the agent, since that logic has no meaning outside the tool it customizes. ## FAQ ### Can I extend Atlas with my own tools? Yes. Atlas plugins contribute tools the agent can call and hook into agent lifecycle events. ### Are plugin tools subject to permissions? Yes. A plugin-contributed tool passes the same allow, ask, or deny check as a built-in tool. ### What is the difference between a plugin and an MCP server? A plugin changes how Atlas itself behaves. An MCP server connects Atlas to an existing system and is reusable by other MCP clients. ### Can a plugin run code during a session? Yes. Lifecycle hooks let a plugin run at defined points as a session proceeds, independently of what the model chooses to call. --- Canonical HTML: https://runatlas.sh/resources/features/plugins Source of truth: aeo_pages row `/resources/features/plugins` (segment: Platform) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.