Skip to main content
← Blog
Product · engineering

Your projects, in the terminal:
we built an MCP server for Claude Code.

Haunch already holds the structured record of a project — calcs with their cited clauses, the calc ↔ drawing graph, tasks, an immutable audit trail. An MCP server hands that record to Claude Code as grounded context — so an AI can answer questions about your job without making anything up.

Why bother

The record is the hard part. AI is the easy part.

Plenty of tools can now talk about engineering. Almost none can talk about your project — because they can't see it, and when they guess, they guess wrong in a discipline where someone signs the calc.

Haunch's whole value is that the record is structured and trustworthy. So the question wasn't “can we add a chatbot” — it was “how do we let the AI an engineer already uses read our record, with the citations intact?” The answer turned out to be a standard one.

MCP — the Model Context Protocol — is an open standard for connecting AI clients to outside systems. A client like Claude Code connects to an MCP server that exposes two things: resources it can read, and tools it can call. We wrote a Haunch MCP server. Point Claude Code at it, and your projects become something it can actually reason over.
Two minutes to wired-up

Connect it once

The server ships as a small package. You add it to Claude Code's MCP config with a scoped token from your Haunch account — read-only by default — and that's the whole setup.

~/.config/claude/mcp.jsonjson
{
  "mcpServers": {
    "haunch": {
      "command": "npx",
      "args": ["-y", "@haunch/mcp"],
      "env": {
        "HAUNCH_TOKEN": "hnch_sk_••••••••",  // scoped, read-only
        "HAUNCH_SCOPE": "projects:read calcs:read drawings:read"
      }
    }
  }
}

Writes — creating a task, marking a drawing re-issued — need an explicit write scope, and every one of them lands in the project's audit trail with “via Claude Code” against your name. More on that below.

The surface

What Claude Code can see — and do

We kept the surface deliberately small and honest. Resources are the things it can read; tools are the things it can run. The writes are few, and all of them are gated.

search_projectsResource

Find projects and jobs by name, ref, client or address across the whole practice.

get_calcResource

A calculation with every result tied to its Eurocode clause, formula and value.

list_stale_drawingsResource

Drawings issued against an older calc revision than the one now approved.

get_audit_trailResource

The immutable who-did-what-when for any project, calc or drawing.

create_taskTool

Draft a task with members, files and a note attached — proposed, never silent.

write scope · audit-logged
flag_drawingsTool

Mark the drawings a revised calc affects as behind — the consequence cascade, by API.

write scope · audit-logged
What it feels like

From an architect's email to a flagged project

Here's where the conductor earns its place. A revised drawing lands in your inbox from the architect. Instead of reading it, opening the job, working out what it touches and remembering to act — you ask once, and Claude works across both connectors.

claude code — 14 Maple Avenuehaunch + gmail
>The architect just emailed. Read it and update the project to match whatever changed.
gmail.search{ project: "MAP-24", unread: true }1 from architect
get_calc{ id: "beam" }ok
get_drawings{ calc: "beam" }2 linked
Newest unread is from Orla Devlin · Studio MAA (2 hours ago) — “Revised rear elevation”, with A-204 rev C attached. The change: the rear glazed opening is widened from 3.6 m to 4.2 m for a larger bifold.
That opening is spanned by B1 on the Steel Beam Calc — currently 203×133×25 UB, sized for a 3.6 m clear span. A 600 mm wider opening changes the span, so the beam has to be re-checked before the drawings can follow. (cited: gmail → A-204 rev C, get_calc → B1 span)
Here's what I'd do, on your say-so:
File A-204 rev C to the projectDraft task: re-check B1 for 4.2 mHold S-01, S-02 until the calc is re-run
I won't resize the beam — that calc is yours to run and sign. File the drawing and open the task?
Two connectors, one ask. Claude read the architect's email, worked out what it touches in Haunch, and proposed the update — then stopped at the beam. The sizing, and the signature, stay yours.
Under the hood

The server is a gate, not a pipe

Claude Code never touches the Haunch database. It talks to the MCP server, and the server is where scope is enforced and every call is recorded. That middle layer is the whole point.

Claude Code
The engineer's terminal. Asks questions, proposes actions.
Haunch MCP server
Enforces scope. Logs every call to the audit trail. Returns results with their citations.
Haunch record
Calcs, drawings, tasks, the immutable audit trail.
Read-only by default · writes need scope and are stamped “via Claude Code” · the human still signs.
How far it goes

Claude Code as the place the work happens

The MCP server is one connector, not the whole story. Claude Code already reaches your filesystem, the CLIs on your machine, and other MCP servers — Git, cloud storage, email. Haunch is one source among several, and Claude Code is the conductor. The job stops being “open six tools and copy between them” and becomes “ask once, where you already work.”

Claude Code
one place the work happens
Haunch record
Calcs, drawings, tasks, audit — via the MCP server.
Your filesystem
The calc PDFs and drawing sets on your own machine.
Email & client comms
Send the RFI or transmittal through the CLIs you already use.
Cloud & CDE
Push issued files to the shared common data environment.
Each connector is separate and scoped — Claude orchestrates across them; none of them see each other.
01

The local ↔ record bridge

The thing only a tool on your machine can do: reconcile the files on disk against the Haunch register, and file new ones where they belong.

>Drop a new calc PDF in this folder → filed against MAP-24, set to rev B, affected drawings flagged.
02

The firm's own memory

Precedent search across every past job — grounded in what your practice has actually done, not the internet.

>How have we detailed a 6 m steel beam over a patio door before?
03

Grounded drafting

RFI responses, transmittals, the revision note from a calc diff — written into your repo as plain text for you to sign off.

>Draft a reply to the rebar RFI from the approved foundation calc.
04

The cascade, end to end

One revision, the whole chain — draft the tasks, assign them, and hand to your email CLI to tell the client. Proposed as a single batch.

>Calc → rev B: 2 tasks drafted for Declan, client email queued for your review.
The line we hold

Grounded, scoped, logged

01

Read before write

The default token reads. Writing anything is an explicit scope a person turns on — and even then the server only ever drafts and proposes.

02

Every answer cites its source

Results carry the tool call and the audit entry behind them. An answer you can't trace is an answer Haunch won't give.

03

The AI never computes the calc

It reads results a human signed. It does not re-derive load paths or invent capacities. The signature stays human.

04

The trail captures the assistant too

Anything done through Claude Code is logged as such, against your name. The record stays complete — and honest about how it was made.

Get early access

An open door onto a closed record

The server is in private beta with a handful of practices. The resources are stable; we're adding tools carefully, write by write, each one gated and logged. If you run Claude Code and want your Haunch projects in reach of it, tell us — we'll get you a token.

An MCP server for Claude Code — Haunch blog — Haunch