Backend Engineer's AI Toolkit

What's in this pack

Audience: you write services for a living in Go, Rust, Python, or Node. You already have an LLM in your editor. The thing it's still bad at is anything that touches production reality — a real schema with 80 columns, a contract that downstream teams ratified six months ago, a microservice topology you didn't choose, a 3 a.m. incident where the trace just stops.

This pack is nine tools that close that gap. Every pick is operable by an agent (MCP server or skill), not just a library you could already go get. Three buckets:

• Data layer — give the agent safe, structured access to Postgres so it can read schemas, propose indexes, and dry-run SQL without burning your production cluster.
• API + service layer — let it generate framework-correct handlers, OpenAPI clients, and Go service skeletons that match your house style.
• Debugging + observability — when something is on fire, give it a real debugger and real telemetry, not a print statement.

Install in this order

Order matters. Each tier unlocks the next.

1. PostgreSQL MCP (id 660) — start here. A read-only MCP server pointed at a non-prod replica. Now the agent can describe table users, list indexes, sample 100 rows. This single step changes "AI writes plausible SQL" into "AI writes SQL that compiles against your actual schema."
2. Postgres MCP Pro (id 3283) — once read-only is comfortable, add the index-tuning + safe-SQL layer. Same idea, broader surface: EXPLAIN integration, index recommendations, write tools behind a safety mode. Don't install this before #1; you want to have already learned where the agent gets schema things wrong.
3. Backend Architect agent (id 4367) — a Claude Code skill that takes a feature description and outputs a service shape: tables, endpoints, queue boundaries, failure modes. Read-only, no code yet — this is the thinking step.
4. FastAPI (id 839) — opinionated, type-driven Python framework. Even if you ship Go in production, FastAPI is the fastest way to give an agent a target stack for prototyping or building internal AI endpoints. Pydantic models double as the LLM's schema source of truth.
5. OpenAPI Generator (id 2668) — the contract layer. Hand the agent your OpenAPI spec, generate clients + server stubs in 30 languages. Stop letting agents write hand-rolled HTTP clients that drift from the spec.
6. Golang Pro agent (id 4524) — a Go-specialist Claude Code agent. Knows idiomatic error wrapping, context.Context propagation, table tests, and the standard project layout discussions. Use after Backend Architect has set the shape.
7. Microservices Architect agent (id 4433) — for when the feature crosses service boundaries. Talks about service boundaries, transactional outbox, idempotency keys, saga vs 2PC. Optional — skip if you're a monolith team and proud of it.
8. Debugger agent (id 4393) — a Claude Code skill that runs a four-phase root-cause protocol: reproduce, isolate, hypothesize, verify. Pair with a real debugger (Delve / pdb / node --inspect). Replaces the failure mode where the LLM "fixes" the symptom by adding a try/except.
9. Logfire (id 3235) — Python observability on OpenTelemetry. Even for non-Python services, the OTel pipeline + Logfire's structured views are a sane default to wire spans into so the debugger agent has something to read at 3 a.m.

How they fit together

         ┌─────────────────────┐
         │  Backend Architect  │  ← "design this feature"
         │     (4367)          │     (talks, doesn't code yet)
         └──────────┬──────────┘
                    │ schema + endpoint plan
                    ▼
   ┌────────────────┴────────────────┐
   │       Data layer (read-only)    │
   │  PostgreSQL MCP (660)           │  ← agent reads real schema
   │  Postgres MCP Pro (3283)        │  ← then proposes indexes / dry-run SQL
   └────────────────┬────────────────┘
                    │
                    ▼
   ┌─────────────────────────────────┐
   │       API + service layer       │
   │  OpenAPI Generator (2668) ──┐   │  ← contract is source of truth
   │                             │   │
   │  FastAPI (839)   Golang Pro │   │  ← agents write stack-correct code
   │                  (4524)     │   │
   │  Microservices Architect (4433) │  ← boundary calls, not in-process
   └────────────────┬────────────────┘
                    │
                    ▼
   ┌─────────────────────────────────┐
   │   Debug + observability         │
   │  Logfire (3235) ─── spans ──┐   │
   │                             ▼   │
   │  Debugger agent (4393) ◀────────┤  ← reads spans + repros bug
   └─────────────────────────────────┘

The loop that matters: Architect drafts → MCP servers ground the draft in real schema → code-gen agents emit framework-correct code → observability + debugger close the feedback when production tells the truth. Skip any one tier and the next tier starts hallucinating.

Tradeoffs you'll hit

• Read-only DB MCP vs write-enabled — PostgreSQL MCP (660) is read-only by default, Postgres MCP Pro (3283) opens up write tools behind a safety mode. Start read-only on a non-prod replica for at least two weeks; only widen once you trust the agent's SQL.
• ORM-aware agent vs raw-SQL agent — Backend Architect and Golang Pro don't assume an ORM. If your house style is GORM/sqlx/SQLAlchemy, paste a CLAUDE.md snippet stating that — otherwise you'll get half raw-SQL, half ORM proposals on the same PR.
• Monolith vs microservice tooling — Microservices Architect (4433) is genuinely useful for boundary work, but it tends to recommend a service split where a package would do. If you're under ~5 services, install but use sparingly.
• Hand-rolled clients vs OpenAPI Generator — openapi-generator produces a lot of code, some of it ugly. The win isn't pretty code; it's that drift between spec and client becomes a compile error instead of a 4 a.m. bug.
• Logfire vs your existing OTel stack — Logfire is Python-flavored but speaks OTel, so a Go or Rust service can export spans there too. If you already run Tempo or Honeycomb, treat Logfire as a side-channel for AI-readable views rather than ripping out what works.

Common pitfalls

• Pointing DB MCP at production — don't. Use a logical replica, a read-only role, or a sanitized snapshot. The agent will eventually try a 12-way join on events and pin a CPU.
• Letting the agent invent endpoints not in the OpenAPI spec — once #5 is installed, gate code review on "does the spec say this endpoint exists." Otherwise the contract becomes fiction.
• Stacking two architecture agents on one task — running Backend Architect + Microservices Architect on the same prompt produces 4× the text and zero extra signal. Pick one per planning round.
• Skipping Logfire because "we have Datadog" — fine, skip it. But your debugger agent then has nothing to read; either point it at your existing OTel exporter or accept that #8's effectiveness drops in half.
• Treating the Debugger agent as a 1-shot "fix this" button — it's a four-phase protocol; if the first phase (reproduce) fails, stop, don't let it skip to a guess-fix.