Three months ago, I spent 47 minutes setting up a single MCP server.

It was a simple GitHub integration. Should have been straightforward. Instead, I navigated dependency conflicts, environment variables that weren't documented, and a configuration file format that changed between versions. When I finally got it running, I realized I needed to do the same dance for Slack, then Notion, then my database.

This is not a story about MCP being bad. MCP is brilliant: an open protocol that lets AI agents talk to external tools. The installation experience is the painful part, and it is exactly why we built Tap.

The MCP Promise vs. Reality

The Model Context Protocol launched with a simple idea: universal connectors between AI agents and external tools. Write once, use anywhere. One protocol, any tool.

The reality for developers? Something closer to this:

bash 
# Step 1: Install the server
npm install -g @someorg/mcp-github

# Step 2: Find the config file
# Is it ~/.cursor/mcp.json? ~/.config/mcp/settings.json?
# Depends on your client.

# Step 3: Set environment variables
export GITHUB_TOKEN=ghp_...
export GITHUB_API_URL=https://api.github.com
# Wait, is it GITHUB_TOKEN or GITHUB_PAT?

# Step 4: Configure the JSON
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@someorg/mcp-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

# Step 5: Restart your editor
# Step 6: Debug why it's not connecting
# Step 7: Check logs somewhere
# Step 8: Realize the server needs Node 18+, you have 16

By the time you've set up three MCP servers, you've spent an hour on configuration plumbing without writing a single line of actual code.

The Prompting Treadmill

But MCP setup was only half the problem.

Even with tools connected, every new task required the same ritual:

  1. Explain the context — "This is a Rust project using Axum..."
  2. Define the constraints — "Don't modify the auth module..."
  3. Specify the output — "Generate tests that use the existing fixtures..."
  4. Clarify misunderstandings — "No, I meant the other database..."

Two hours later, your agent finally understands your codebase. Then you start a new session and do it all again.

We kept hearing the same thing from developers: "I spend more time setting up my AI than using it."

The Insight: Agents Should Be Ready-to-Run

We asked ourselves: what if agents came pre-configured?

Not just tools — entire specialist agents that know their domain, include their dependencies, and ask for exactly the credentials they need. Install in one command. Run immediately. No JSON editing. No dependency mess. No repetitive prompting.

That's Tap — a registry of specialist AI agents, installable like Homebrew packages, ready to work.

How Tap Works

Instead of this:

bash 
# Install server
npm install -g @mcp/github

# Edit config
vim ~/.cursor/mcp.json

# Set env vars
export GITHUB_TOKEN=...

# Write system prompt
# "You are a helpful assistant with GitHub access..."

You do this:

bash 
# Run a specialist agent directly
octomind run devops:kubernetes

# Dependencies resolved automatically: kubectl ✓, helm ✓
# Done. The agent understands K8s and is ready.

The Tap handles:

  • Dependencies — kubectl, helm via the kubernetes capability; cargo, clippy via programming-rust; each capability declares its own deps
  • Configuration — Capabilities resolve to MCP servers at runtime
  • Inputs — {{INPUT:KEY}} prompts once, stores the value (e.g., {{INPUT:LAWYER_COUNTRY}} remembers your jurisdiction)
  • Environment — {{ENV:KEY}} reads from your environment or prompts and saves to .env
  • Domain knowledge — System prompt and skills baked into the agent manifest

No JSON editing. No dependency conflicts. No repetitive prompting.

Built for Specific Domains

This is where Tap gets interesting. These are not generic assistants with tools bolted on. They are specialists.

developer:general — Knows Rust idioms, cargo workflows, and clippy lints. Includes the Rust toolchain via programming-rust capability.

devops:kubernetes — Understands K8s, Helm, and your cloud provider. Reads pod logs, suggests fixes, generates manifests. Uses kubernetes and docker capabilities.

security:owasp — Static analysis, dependency scanning, vulnerability research. Comes with knowledge of CWE categories.

Each agent is a complete package: model configuration, capabilities that resolve to tools, system prompts, and domain knowledge. Run it, provide credentials, start working.

Community-Driven, Domain-Proven

The best Taps come from developers who solved specific problems.

A legal tech team published lawyer:us — an agent grounded in US federal and state law, with citation verification baked in. A healthcare developer contributed doctor:medications — drug interaction checks backed by medical databases. DevOps engineers maintain devops:terraform — infrastructure as code with cloud-provider awareness.

These aren't theoretical. They're real agents in the registry, built by people who needed them to work. And the catalog keeps growing — compliance agents, financial auditors, research assistants — each one contributed by someone who solved a real problem.

The Tap Registry is community-supported. Anyone can publish. Popular Taps get starred, reviewed, and improved. Manifests (Tap's configuration format) are open and auditable — plain TOML files you can read before you run.

Octomind Is Built on Tap

One detail we do not talk about enough: Octomind itself is built on Tap.

Every feature you use — the interactive sessions, the specialist agents, the tool orchestration — runs through agents defined in the Tap Registry. Our "core" functionality? It's just a well-configured set of Taps that we maintain and optimize.

This isn't marketing fluff. It's architectural. When you extend Octomind with a custom Tap, you're using the same system we use internally. The boundary between "built-in" and "community" features is thin by design.

The Homebrew Moment for AI Agents

In 2009, Homebrew changed how developers installed software. No more sudo make install. No more dependency hunting. Just brew install and get back to work.

We're at a similar moment with AI agents.

The infrastructure is here — large language models, tool APIs, context protocols. What's missing is the packaging layer. A way to distribute complete, ready-to-run agents that don't require an hour of setup.

Tap is that layer.

Getting Started

If you've never used Octomind (the getting started guide has the full walkthrough):

bash 
# Install Octomind
curl -fsSL https://octomind.run/install.sh | sh

# Run your first specialist agent
octomind run developer:general

# Explore available agents on the website or GitHub

If you're already using Octomind:

bash 
# Run a different specialist
octomind run devops:kubernetes

# Or try a domain expert
octomind run lawyer:us

Custom Taps

You can add your own tap — a local directory or a GitHub repo:

bash 
# Add a custom tap from a local directory
octomind tap myorg/agents ./local

# Now run agents from your custom tap
octomind run developer:general

FAQ

Q: Is Tap just a wrapper around MCP?

No. Tap uses MCP where appropriate, but it's a higher-level abstraction. A Tap includes the agent definition, model configuration, system prompts, and dependency management — not just tool connections. For how Octomind itself wires MCP servers to agents, see the MCP tools deep dive.

Q: Can I create my own Taps?

Yes. Taps are TOML files in agents/<domain>/<spec>.toml format. Define capabilities, system prompts, and role configuration. See the GitHub repo for examples.

Q: Are agents from Tap safe to run?

You can audit any agent's TOML manifest before running — it's just a text file with system prompts and capability declarations. On Linux, optional sandboxing adds another layer of protection.

Q: Do agents work with any AI model?

Agents can specify model requirements in their manifest. Octomind supports any OpenAI-compatible API, and you can override models at runtime with --model.

Q: What if an agent needs a dependency I don't have?

Capabilities handle dependencies. For example, programming-rust capability includes cargo, clippy, and rustfmt — either bundled or installed via the capability's dep script. You don't manage this manually.

The Future: A Tap for Everything

We're building toward a future where there's a Tap for every domain:

  • medical-coding — HIPAA-compliant medical billing assistance
  • legal-discovery — Document review and case preparation
  • biotech-research — Literature review and experiment design
  • financial-compliance — Regulatory checklists and audit prep

Specialist agents, one command away, maintained by the people who know those domains best.

That's the future we're building. And it starts with octomind run.

Written for developers tired of configuring AI agents instead of using them.

Browse the Tap Registry → octomind.run/tap
Create your first Tap → GitHub repo
See what's trending → GitHub