From MCP Chaos to One Command: Why I Built ATK

I like MCPs. I use coding agents every day. But my setup got messy fast.

One MCP installed from a random repo. Another ran in Docker.
Claude configured one way, Codex another way, Auggie in a third format.
Some configs lived in JSON files, some in shell history, some only in my head.
It worked until it didn't.

Changing machines broke things. Reproducing setup was painful.
A tool upgrade could silently break another integration, and none of it was really transferable.
I stopped patching it and consolidated everything into one place.
While managing different tools, I started seeing the same patterns and automating them.
People kept asking about my setup, and I kept repeating the same explanation.
At some point it was obvious: this problem needed a tool, so I built atk.

What ATK does

atk is a CLI plugin manager for AI-assisted development.

It gives you a consistent interface for tools that are usually fragmented:

• Install from a registry, a Git repo, or a local plugin
• Wire one MCP into multiple coding agents in one command
• Inject usage skills (SKILL.md) so agents know how to use tools, not just connect to them
• Manage lifecycle with the same commands regardless of whether the tool is Docker, Python, Node, or shell
• Keep everything git-backed and reproducible

Example:

atk add openmemory
atk mcp add openmemory --claude --codex --gemini --auggie --opencode

That's the core point: one command path instead of five different setup paths.
These two lines show the basic flow: install and configure a plugin, then wire it into your agents.
ATK handles prompts and agent-specific setup for you.
The second command wires the MCP into whichever agents you select with flags and adds usage skills where available.

Why this matters

If you use MCP seriously, setup entropy is real.
The hard part is not installing one tool once. The hard part is keeping everything working over time.

ATK turns that into a repeatable workflow:

• predictable commands
• explicit configuration
• repeatable environment
• easier rollback and migration

When you use ATK, your configuration lives in ~/.atk (a git repo), and each mutation is committed.
If you remove something by accident, pull a plugin version that doesn't work for you, or change your mind, you can revert with normal git workflow.

Typical workflows

Most of the value shows up in routine tasks:

# Discover and install a tool
atk search memory
atk add openmemory

# Wire it into your agents
atk mcp add openmemory --claude --codex --gemini --auggie --opencode
# Unwire it
atk mcp remove openmemory --claude --codex --gemini --auggie --opencode

# Operate and maintain
atk status
atk upgrade --all
atk restart langfuse
# Run custom scripts
atk run openmemory backup
atk run openmemory restore

Same shape for most tools:

• openmemory for persistent context across agent sessions
• github or gitlab for repo operations from chat
• slack for channel history and messaging workflows
• playwright or fetch for web automation and retrieval
• langfuse for tracing and observability

The point is not just "one more CLI." The point is reducing context switching and setup drift across agents and machines.

If the registry doesn't have what you need

You can still use ATK without waiting on the registry.

If a plugin already exists, install it.
If it doesn't, ask your coding agent to generate one and use the create-atk-plugin skill as context.

You can keep that plugin private in your own ~/.atk setup.
If you want to share it later, you can:

• add a .atk/ directory to your repo so others can install from source with atk add github.com/org/project
• publish it to the ATK registry

So ATK works as both a curated catalog and a personal packaging format.
Use it as far as it helps your workflow, and extend it only when you need to.