01services · mcp.consulting

MCP consulting. Servers included.

Most MCP integrations fail at auth, not at tools. I've shipped OAuth 2.1 on a remote server that Claude connects to daily. If your team is wiring LLMs into internal systems and improvising the protocol layer, that's the conversation.

02the problem

Everyone is wiring LLMs into internal systems. Almost nobody has a protocol strategy.

The usual path: one team hardcodes function-calling glue between one model and one internal API. It demos well. Then a second model arrives, a third system needs wiring, and auth turns out to be a static bearer token pasted into a config file. By the time a security review asks who can call what, nobody can answer.

The Model Context Protocol is the standard layer for exactly this: your systems expose capabilities as tools, and any MCP client can use them. But adopted casually, MCP reproduces the same mess with extra ceremony. The decisions that matter are made before the first tool is registered: which capabilities become tools and which stay plain APIs, whether the server runs locally over stdio or remotely over Streamable HTTP, how a client obtains a token, and what an attacker sees when they probe the endpoint.

The last one is not hypothetical. Remote MCP servers that answer tools/list without authentication are common enough to be a research finding. Auth is where these integrations fail, and auth is decided at the architecture stage.

03what I do

Three shapes, all hands-on.

No discovery decks. Every shape below ends in something written or something running.

shape.01
fixed scope

Architecture review

I read your integration plans, or the glue you already have, and hand back a written read: the tool inventory, transport choice, auth design, and deployment path, with the tradeoffs stated rather than buried. Includes the honest case that you do not need MCP yet.
shape.02
fixed scope

Remote server build

End-to-end MCP server development in TypeScript, on your infra or mine. Streamable HTTP transport, OAuth 2.1 with PKCE, discovery metadata, dynamic client registration, token rotation, and a smoke suite that exercises the whole flow against the live deployment. Handed over documented.
shape.03
retainer

Ongoing advisory

Protocol decisions as they come up: vendor pitches sanity-checked, tool designs reviewed, auth changes vetted before they ship. Weekly written memo. Scoped to an exit from day one.
04proof

Real servers, deployed.

Skapis is a personal knowledge vault: a remote TypeScript MCP server with a self-hosted OAuth 2.1 authorization server. PKCE, discovery metadata, dynamic client registration, refresh-token rotation, hashed tokens at rest. Five tools over Streamable HTTP, deployed on Hetzner behind a Cloudflare Tunnel, so the MCP service itself exposes no inbound port. Claude connects to it as a custom connector. The auth layer is 399 lines, roughly 38 percent of the server source, which tells you where the real work in a remote MCP server lives.

auseklis is an ephemeris and astrology MCP server on Cloudflare Workers: twelve tools that compute real astronomy so the model never guesses a number. MIT-licensed and public. aisthesis gives models senses: image generation, speech, transcription, vision, moderation, in eight tools. Also public.

The full OAuth 2.1 build is written up, endpoint by endpoint, in OAuth 2.1 for remote MCP servers: a production implementation. If you are deciding whether to hire anyone at all, start with what an MCP consultant actually does: it includes the cases where the answer is no.

If your team is wiring LLMs into internal systems and improvising the protocol layer, that's the conversation. One email, one business day to a reply.