mcp-servers

Three MCP servers + agent runtime. mcp-ops-handbook, mcp-data-tier, mcp-platform-ctl expose basecamp's surface as typed tools. The LangGraph-based agent runtime composes them. Ships at Year 5 Phase 48.

Three MCP servers + a LangGraph agent runtime. Agents that actually use basecamp’s surface as typed tools.

What this is

The Model Context Protocol (MCP) is Anthropic’s open standard for exposing tools to LLM clients. This project ships three MCP servers that expose basecamp’s operational surface to agents:

  1. mcp-ops-handbook — exposes runbooks, postmortems, ADRs, weekly logs as MCP resources. Agents read them.
  2. mcp-data-tier — exposes Iceberg tables via Trino as a query tool. Agents run analytical queries.
  3. mcp-platform-ctl — exposes a subset of platform-ctl actions as tools. Approval-gated (agent proposes; human approves).

Plus a LangGraph-based agent runtime that uses the three MCP servers to provide useful agent capabilities: “summarize last week’s incidents”, “draft a new service called X” (with approval), “investigate alert Y”.

Why it exists

Three reasons:

  1. The MCP standard is the right tool surface. Built right, agents work across multiple LLM clients (Claude Desktop, custom runtimes). Built wrong, you couple agents to one framework.
  2. basecamp’s surface needs exposure. Without MCP servers, the basecamp platform is invisible to agents. With them, agents become first-class platform consumers.
  3. The senior-IC signal for agents. “I built MCP servers and an agent runtime that uses them” is concrete evidence of AI infrastructure thinking, not just LLM API plumbing.

Spec (v0.1.0)

mcp-ops-handbook

MCP server exposing:

  • Resources: runbooks, postmortems, ADRs, weekly logs (read-only)
  • Tools: search_postmortems(query, time_range), find_runbook(category), get_recent_weekly_logs(N)
  • Read-only; no write tools

Storage: reads from ops-handbook Git repo (cloned + cached); falls back to vector search via pgvector for similarity queries.

mcp-data-tier

MCP server exposing:

  • Tools: query_iceberg_table(table, sql) — bounded query against Trino; returns sample of results
  • Resources: schema definitions of all Iceberg tables
  • Read-only; bounded query size to prevent runaway costs

mcp-platform-ctl

MCP server exposing a careful subset of platform-ctl:

  • Tools (read-only): list_services(), describe_service(name), get_slo_breaches()
  • Tools (approval-gated): propose_new_service(spec), propose_runbook_execution(runbook)
  • Approval gates require human confirmation via Slack/Studio before execution

Agent runtime

LangGraph + MCP client. Loop: read query → reason → call MCP tool → reason → … → respond. With safety:

  • Capability allowlist per agent
  • Max iteration budget
  • Trajectory eval against benchmark

Architecture

┌──────────────────────────────────┐
│ User / Studio UI                 │
└──────────────┬───────────────────┘
               │
               ▼
┌──────────────────────────────────┐
│ Agent Runtime (LangGraph)        │
│  - reads user query              │
│  - reasons (via llm-gateway)     │
│  - selects MCP tool              │
│  - executes → result → reason... │
└─┬────────────┬──────────────┬────┘
  │            │              │
  ▼            ▼              ▼
mcp-ops-     mcp-data-     mcp-platform-
handbook     tier          ctl
  │            │              │
  ▼            ▼              ▼
ops-handbook  Trino +       platform-ctl
(Git + cache) Iceberg       (Phase 26)
              + pgvector

Each MCP server is a small Go or Python service. The agent runtime is Python (LangGraph + MCP Python SDK).

/root phases involved

PhaseWhat happens
Y5 Phase 48Author all three MCP servers + agent runtime; ship publicly
Y5 Phase 49AI security hardening: capability allowlists enforced at MCP server level
Y5 Phase 50AIOps custom operator uses agent runtime via mcp-platform-ctl
Y5 CapstoneStudio integrates agent runtime as a panel

Public vs private

MCP servers public from Y5 Phase 48 (the code; the actual ops-handbook content stays private). Agent runtime public.

Launch energy

Quiet ship for MCP servers. The Studio launch at the Y5 capstone consumes the loud energy for the whole agent layer.

Integration with basecamp

The three MCP servers expose basecamp’s surface. The agent runtime composes them. AIOps (Phase 50) consumes the agent runtime. Studio (Capstone) exposes the runtime via UI. The whole AI tier composes around MCP.

Validation criteria

[ ] All three MCP servers operational on basecamp
[ ] LangGraph agent runtime working with Claude via llm-gateway
[ ] Agent successfully reads + cites ops-handbook entries
[ ] Agent runs Iceberg queries via Trino
[ ] Agent proposes platform-ctl actions; approval gate works
[ ] Capability allowlist enforced at MCP server level
[ ] Eval suite: 30+ scenarios, regression-tracked
[ ] Prompt injection defenses verified (Phase 49)
[ ] MCP servers public on GitHub
[ ] At least 1 external integration (e.g., Claude Desktop connects to mcp-ops-handbook)

Status

Created:           not yet
Started:           Y5 Phase 48 (after Phase 47 prompt engineering)
Target v0.1.0:     end of Y5 Phase 48
Public visibility peak: Y5 Capstone (Studio surfaces)

Anti-patterns

Anti-patternWhy
Agent calling kubectl directlyDefeats the MCP abstraction; expose typed tools only
Approval gates on read-only actionsFriction without safety value
No approval gates on destructive actionsBlast radius too large
Tools that are bags of stringsJSON Schema validation is the contract
Skipping eval suiteAgent quality regressions are silent

Cross-references