Claude Code for Clinicians Chapter 15
Part IV — Pushing the Limits

Chapter 15: MCP Servers — Letting Claude Talk to Your Other Systems

By default, Claude Code can read and write files in the folder you launched it from, run shell commands, and edit code. That is a lot. But the AI Office pipelines you read about in Chapter 0.5 do not live in one folder. The AKI cohort SQL lives in Azure SQL. The eval-run logs live in a Slack channel. The pathology extractions land in a Databricks table. If Claude could only see files on your laptop, half of the real work would still require you to copy and paste between windows.

MCP servers are how you close that gap.

What MCP Is, Slowly

MCP stands for Model Context Protocol. It is a published standard — Anthropic wrote it, but it is open, and other AI tools have adopted it — for how an AI agent (like Claude) connects to an external tool or data source.

Think of how the VistA EMR talks to the lab system. The two systems were written by different teams in different decades. They do not share code. They share a specification: when the lab has a new result, it sends a message in a known format on a known channel, and VistA knows how to receive it. Neither side has to know how the other side is implemented internally. They just have to agree on the wire between them.

MCP is the same idea, for AI agents. An MCP server is a small program that speaks the MCP wire format. On one side it talks to Claude. On the other side it talks to whatever external thing you want Claude to reach — a Postgres database, a Slack workspace, a Figma file, a Google Drive folder, an internal API, a real web browser.

Claude asks the server: what tools do you offer? The server replies with a menu, the way the lab system tells VistA which test codes it accepts. From then on, Claude can call those tools the same way it calls its built-in Read or Bash.

🧠 Remember. MCP does not make Claude smarter. It makes Claude’s reach longer. The same model that edits a Python file can now query your production database, read a Slack thread, or open a real browser, because an MCP server has exposed those actions as tools Claude knows how to call.

Installing One

The command has two shapes, depending on where the server runs.

For an MCP server that runs locally as a small subprocess on your machine, you give it a name, then a -- separator, then the command that launches it (everything after the -- belongs to the server, not to Claude). For example, Playwright (which gives Claude a real browser):

claude mcp add playwright -- npx @playwright/mcp@latest

For a server that already runs somewhere on the network, you name the transport and give it the URL:

claude mcp add --transport http aidi-sql https://mcp.khcc.jo/aidi-db

After installing, claude mcp list shows what is connected, and inside a Claude session the /mcp command shows which servers are live and which tools each one exposes. Removing one is claude mcp remove <name>.

💡 Tip. MCP servers can be installed at three scopes, chosen with the --scope flag: local (the default — this project only, private to you), project (shared via a .mcp.json file checked into git so the whole team gets the same connection), or user (every project on your machine, still private to you). Use project scope when the whole team needs the same database connection (like AIDI-DB). Use user scope for personal connections like your own Notion workspace.

The Four MCP Servers Worth Installing First

There are hundreds of MCP servers in the wild. Most you will never need. Four cover most of the real-world value for a clinician learning to build.

1. Playwright. Playwright is a browser-automation library. The Playwright MCP gives Claude a real web browser it can drive — opening URLs, clicking buttons, filling forms, taking screenshots. In a clinical context, this is how you ask Claude to “open the chemo-prep dashboard, log in with these test credentials, search for patient X, and tell me whether the alert badge is showing.” It is also how Claude verifies its own UI work: after building a screen, Claude can open it, click through it, and confirm the button actually does what was asked.

2. Postgres / MySQL / SQL Server. A database MCP server lets Claude describe your schema, run SELECT queries, and explain a slow query plan, without you copying schema definitions into chat. For KHCC, where the AI Office silver tables live in Azure SQL, this is the connection that earns its keep. (More on this in the KHCC Example below.)

3. Slack. A Slack MCP lets Claude read a thread directly. When the on-call pharmacist posts “last night’s AKI alert was empty, who’s looking?”, Claude can pull the thread, read the timestamps and screenshots, and start debugging without you re-typing context.

4. Figma. Figma is the design tool that UI designers use. If your project has a Figma file, the Figma MCP lets Claude read the design and write the React or Streamlit component that matches it. Design-to-code in one hop, instead of you describing the design in prose.

🧠 Remember. Four MCP servers used well beats forty installed and forgotten. Every connected server adds tool descriptions to Claude’s context window on every turn. More servers means less room for your actual work.

Why CLI Tools Often Beat MCP Servers

Here is a rule that surprises people: a command-line tool is almost always more efficient than an MCP server that does the same job.

The reason is context cost. When an MCP server connects at session start, it registers every tool it offers — name, description, argument schema — into Claude’s context window. Even tools you never call sit there, taking up tokens, on every single turn. Ten MCP servers with eight tools each is eighty tool definitions Claude must re-read on every message.

A regular CLI tool, by contrast, costs zero tokens until Claude actually runs it. Claude already knows from training how to call git, gh (the GitHub CLI), psql, az (the Azure CLI), curl, and most other standard tools. If it doesn’t know a flag, it can run --help once and learn.

The medical analogy: an MCP server is like a consultant whose card sits on every page of the chart. Even when you don’t need her, you read her name. A CLI tool is like a number on a sticky note — you only look when you call.

So:

🔧 Technical Stuff. The context-cost difference is measurable. After installing five servers, run claude mcp list, then watch /cost and /context on your next session. You will see per-turn input tokens climb by several thousand just from the registered tool definitions. Multiply that across a long session and the difference is real money.

When MCP Actually Wins

MCP is the right choice when:

⚠️ Warning. Every MCP server you install can read whatever it is connected to. A Postgres MCP pointed at production can run DROP TABLE. A Slack MCP can post to any channel its token has access to. Treat MCP credentials like database credentials — because that is what they are. Never install a third-party MCP server from a random GitHub repo without reading its source code first.

The KHCC Example

Here is the AI Office MCP setup that earns its keep.

An MCP server for Azure SQL AIDI-DB. Recall from Chapter 0.5 that the AI Office silver tables are the cleaned-up versions of VistA data — one row per patient encounter, dates parsed, units normalized, free text stripped of obvious noise. They are the starting point for most analyses. They live in Azure SQL inside a database called AIDI-DB.

A small Python program — roughly 200 lines — runs on the AI Office bastion server and exposes three tools to Claude over MCP: list_tables (returns a list of all SILVER_ and GOLD_ tables), describe_table (returns the columns and types of one table), and run_select (runs a read-only query, hard-coded to reject anything that is not a SELECT).

Now when an analyst asks Claude “build me a cohort of bone-only metastatic breast cancer patients diagnosed in the last three years,” Claude no longer has to guess that the table is named GOLD_DIAGNOSIS or that the column flagging bone metastasis is met_site_bone. It calls describe_table GOLD_DIAGNOSIS, sees the real schema, writes the right query, runs it through run_select, sanity-checks the row count, and only then asks the analyst to approve the final SQL. No DBA paged. No schema document that is six months out of date.

An MCP server for the Optimus encoder. Recall again from Chapter 0.5 that Optimus is the reversible scrambler that turns a real MRN into a safe identifier that can be logged, emailed, and dashboarded without exposing PHI. Without an MCP, Claude either hard-codes an MRN into a script (a privacy violation waiting to happen) or asks the user for the already-encoded form (a workflow break). With the MCP, Claude calls optimus_encode "<mrn>", gets the safe identifier back, and uses it. The real MRN never leaves the encoder process.

Both servers sit in a folder called aidi-mcp-servers/ inside the AI Office repo, and both were registered once at project scope, so the connection details live in the repo’s .mcp.json. Every analyst who clones the repo gets the same connection after approving it once.

💡 Tip. When you write your own MCP server, give every tool a description that tells Claude when not to use it. “Runs a read-only SELECT against AIDI-DB. Use only for cohort queries. Do not use to count rows; use describe_table for size estimates.” Claude follows tool descriptions far more reliably than it follows free-form instructions in your prompt.

Try This

  1. Run claude mcp list to see what (if anything) is already installed.
  2. Install Playwright — it is the most fun first one: claude mcp add playwright -- npx @playwright/mcp@latest.
  3. In a Claude session, ask: “Open google.com, search for KHCC, and tell me the title of the first result.” Watch Claude drive a real browser.
  4. Now uninstall it: claude mcp remove playwright. Compare /cost on a one-turn session before and after. The difference is what every always-installed MCP server costs you on every turn.

Watch Out