The project: build the latex-mcp infrastructure

The starter you have is the seed — a small working agent that turns a maths topic into a typeset LaTeX image. The goal of Track 3 is to grow that seed into the MCP-first architecture: a latex-mcp server that exposes the LaTeX pipeline as MCP tools, driven by orchestration agents — and structured so other modules (like manim-mcp) drop into the same shape later.

What you start with (the seed)

A Flue agent calls one tool, render_latex, which compiles LaTeX → SVG:

The target (where you’re taking it)

The same render capability, but exposed over MCP and wrapped in a server, so any MCP client or orchestrator can drive it — and so a second content type is just another server of the same shape:

The seed already is the latex-mcp pipeline in miniature (LLM authors LaTeX → TeX Live compiles → SVG) — and the Flue agent it ships with already plays the orchestration role. The orchestration layer can be Flue, the OpenAI Agents SDK, or LangGraph — pick what fits; the seed gives you Flue for free. So the work is to lift the render into an MCP server and have the orchestrator call it over MCP, with everything structured so adding manim-mcp later means copying the pattern, not redesigning.

Why this shape

• MCP makes the tools reusable. Once render_latex is an MCP tool, the same capability is callable by Claude Code at dev time and by a runtime orchestration agent — no bespoke glue per consumer.
• It scales by repetition, not rewrite. manim-mcp, a shared-mcp for common skills/data — each is the same FastMCP-server-over-a-Docker-pipeline shape.
• (Out of scope now) Manim itself isn’t built in this kit — but the LaTeX route is designed so it could be, which is the whole point of the architecture.

Your path

The staged build from seed → architecture is the roadmap, done spec-first with Claude Code. Runbook: Track 3. The companion goal — getting Hermes to run the basic job automatically — is Automate with Hermes.

Track 3 builds the infrastructure; Track 1 automates the work.