How I Built an MCP Server Exposing 60+ Tools to Claude

Most teams talk to Claude through a chat box. The interesting work starts when you let Claude actually do things through your own systems: read a project board, check a calendar, pull a metric. That is what the Model Context Protocol (MCP) enables, and it is where I have spent a lot of my recent engineering time. I built and shipped a production MCP server, Studio OS, that exposes 60+ tools to Claude across project management, email, and health data. Here is how it is put together and what I learned.

What an MCP server actually is

An MCP server is a small, well-defined service that advertises a set of tools (functions Claude can call) and resources (data Claude can read). Claude decides when to call a tool; your server executes it against real systems and returns structured results. The protocol handles the handshake, the tool schemas, and the transport, so you can focus on the tools.

The mental model that helped me most: an MCP server is an API designed for an LLM to consume, not a human. That reframes everything: naming, error messages, and payload shape all get optimized for a model that reads them literally.

The architecture

Studio OS is a FastAPI + Python server that aggregates several external systems behind one secure interface. A single codebase ships two transports: a local stdio build (packaged as a Windows .exe with PyInstaller) and a remote Streamable HTTP deployment on Fly.io. State lives in Neon Postgres, with a nightly, idempotent GitHub Actions job ingesting data and a full write-audit log for anything Claude changes.

• Tools layer: 60+ typed tools across ClickUp, Microsoft Outlook (dual M365 tenants via Microsoft Graph), Apple Health, and Oura.
• Auth layer: OAuth 2.0 device-code flow, multi-tenant, so one server can act on behalf of different accounts.
• Transport layer: stdio for local desktop use, Streamable HTTP for the hosted deployment, from the same core.
• Persistence: Neon Postgres with nightly idempotent ingest and audit logging.

Auth was the hard part

Exposing write access to real systems means auth cannot be an afterthought. I used the OAuth 2.0 device-code flow so users authorize once, per tenant, without pasting secrets into config files. Credentials are encrypted at rest with AES-256-GCM, and every write Claude performs is logged with enough context to answer 'who changed what, when, and why' after the fact.

Migrating transport without breaking clients

The MCP spec evolved from Server-Sent Events toward Streamable HTTP. Migrating a live server is exactly the kind of change that looks trivial and then eats a week. Keeping the tool layer transport-agnostic, so tools never knew which transport invoked them, is what made the migration a swap at the edges rather than a rewrite.

Lessons if you are building your own

1. 1Design tools for the model. Clear names, tight schemas, and human-readable errors dramatically improve how reliably Claude uses them.
2. 2Treat writes as dangerous. Confirmations, scoping, and audit logs turn 'the AI touched production' from a risk into a feature.
3. 3Keep transport at the edges. A clean core means new transports are integrations, not rewrites.
4. 4Ship it as a real product. A one-click installer and sane defaults are the difference between a demo and something a team actually uses daily.

The value of an MCP server is not the AI. It is the boring, careful engineering around auth, transport, and safety that makes trusting the AI reasonable.

If you are building AI features and want tools Claude can safely use against your real systems, this is exactly the kind of work I do. Have a look at my projects or get in touch.