The fleet that plays war

MCP is a standard for how agents access tools, which is genuinely useful, but it doesn't tell you anything about how to manage the servers that expose those tools — how to catalogue them, label them, order them, wrap them in credentials, or decide which ones should even be running in a given session. Before textserve I had twelve shell scripts, one per server, each hand-rolling the same lifecycle: pull secrets from 1Password, start the container, write the registration into ~/.claude.json. Each script slightly different from the others, each accumulating small divergences over time, so that when a credential rotated you'd update most of them and the fourth one would quietly fail two weeks later when you actually needed it. You had a standard for access and no standard for anything around it.

The pain wasn't dramatic. It was the usual kind: a credential rotates, you update three of the twelve scripts, and the fourth one silently fails two weeks later when you actually need it. Or you start a server manually during a session and forget to register it, so Claude doesn't see it. Or you register it but skip the health wait and Claude tries to call a tool that isn't ready yet.

textserve replaced all of that with a single registry and a fleet CLI.

How it works

Every server has an entry in registry.yaml: image or binary, transport, port, tags, health probe. Credentials stay in 1Password and are injected at start time. Registration with Claude Code happens automatically, gated on the health probe passing first.

The two commands I use most are up and down: converge a server (or a tagged group) to running-and-registered, or stop-and-deregistered. They're idempotent — already-running servers are skipped, already-stopped servers don't error.

textserve up --tag knowledge    # start all knowledge-tagged servers, skip healthy ones
textserve down grafana          # stop and deregister grafana
textserve status                # see what's running and healthy across the fleet

doctor runs a full diagnostic when something feels wrong: checks the registry, active Claude config, port conflicts, missing dependencies. Saves a lot of blind docker ps spelunking.

The context problem profiles solve

Running all your MCP servers all the time has a cost that isn't obvious until you have more than three or four of them. Every registered server injects its tool descriptions into Claude's system prompt on every message, whether or not those tools are relevant to what you're doing. A session writing a blog post doesn't need Grafana, Snowflake, and Jenkins tool descriptions in its context. They're just noise, and they're not free.

Profiles are the answer. You define a named set of servers in registry.yaml and converge the fleet to that set in one command:

textserve profile use minimal   # knowledge graph only — blog writing, notes
textserve profile use coding    # sentry, jenkins, textmap — code review sessions
textserve profile use data      # grafana, snowflake, loki — observability work

profile use brings up servers in the profile that aren't running, and brings down servers that aren't in the profile. One command to reshape the tool surface for the session you're actually in.

With textaccounts

textserve respects $CLAUDE_CONFIG_DIR, so it coordinates cleanly with textaccounts profile switching. Switching accounts and switching your MCP surface are two commands:

textaccounts use work
textserve profile use coding

That's the pattern I'm using now: textaccounts handles which Claude identity is active, textserve handles which tools are registered for that identity. Together with textsessions for session triage, the three tools cover the full multi-context Claude Code surface — auth, sessions, MCP — without any of them stepping on each other.