AdrMcp MCP Server

MCP server for Architectural Decision Records: navigate, author, validate, link, and analyze them. Exposed over MCP by the adrmcp mcp server, that capability becomes something an assistant can invoke while it works, not something you go and do afterwards.

What it actually does

Architectural decisions get made in Slack threads, PR comments, and someone's head — then the reasoning evaporates. Months later a teammate asks "why is it done this way?", nobody remembers, and the decision gets silently re-litigated or accidentally reversed. ADRs fix that — if they're written and kept honest. But a folder of Markdown files is inert: you can't ask it what's still accepted, trace what superseded what, or notice a decision that no longer matches the code.

• Read & search ADRs — — list_adrs, get_adr, search_adrs (lexical or semantic), and get_adr_index for the full decision timeline
• Author from a template — — create_adr drafts MADR- or Nygard-format ADRs; update_adr replaces or appends a single section
• Lifecycle-aware transitions — — set_status enforces the ADR lifecycle; supersede_adr creates the replacement and marks/links the old one superseded in a single call
• Relationship graph & staleness detection — — find_related_adrs / get_adr_graph expose links and supersession chains; find_stale_adrs flags ADRs whose code_refs no longer resolve in the codebase
• Conflict & coverage analysis — — detect_conflicts surfaces contradictory accepted decisions; coverage_report highlights ADR coverage gaps by architectural area
• Preview-by-default writes — — every mutating tool defaults to previewOnly: true and returns a unified diff before anything touches disk

Adding it to your client

Being a remote server, there is no local install. You register the endpoint with your client, authorise it once, and the tools appear.

Its toolset

Everything the assistant can do here goes through one of these:

• list_adrs — read
• get_adr — read
• search_adrs — read
• get_adr_index — read
• find_related_adrs — read
• get_adr_graph — read
• create_adr — write
• update_adr — write
• set_status — write
• supersede_adr — write
• link_adrs — write
• validate_adr — read

Configuration

• .NET SDK

Caveats

• Your data travels to the provider's service, so the usual questions apply about what you send and what they retain.
• With 14 tools registered it takes up a noticeable share of the context window; turn it off in projects that never touch AdrMcp.
• MCP clients confirm each tool call by default. Leave that on until you have watched what the adrmcp mcp server does with a few real requests.

When to reach for it

Plenty of cloud and infrastructure servers cover similar ground. The differences that matter in practice are scope of access and how much setup stands between you and a working tool call. AdrMcp's toolset — list_adrs, get_adr, search_adrs and 11 more — is a fair guide to whether it matches your workflow. It is maintained by Atypical-Consulting; worth a glance at recent repository activity before you build anything load-bearing on it.

SyncDev reviews every entry in this directory against the project's own documentation before publishing, and revisits them as servers change.