My Skills
Model Context Protocol
MCP end to end — servers published to PyPI and the official registry, clients wired into agent runtimes across four transports, an authenticated gateway in front of internal servers, and protocol-level defects reported upstream, one of them already fixed and released.
Details & related links
My Model Context Protocol skill is organized around the protocol as an engineering surface rather than a feature to switch on — I have worked all four sides: the servers that expose tools, the clients that consume them, the gateway between, and the tool surface an agent sees. The servers run deepest: a durable agent-memory server published to PyPI and listed in the official MCP Registry; a production server that turns a project system of record into agent-callable tools, with a second, deliberately narrow endpoint exposing only search and fetch, the exact pair ChatGPT's Deep Research connector accepts; and a retrieval platform that presents one capability twice, as REST and MCP interfaces sharing one set of connections, graphs, and embedders. On the client side I wire MCP servers into agent runtimes as typed tools across stdio, streamable HTTP, SSE, and WebSocket transports.
The interesting problems sit above the transport, in what a server chooses to say and to refuse. Which tools to expose is a design decision: in one curated environment I keep only the language-server-backed navigation and symbol-editing tools and disable the server's file, shell, memory, and dashboard tools so they never compete with the host agent's own. Responses are curated by default and raw one parameter away, because an agent parsing a full upstream payload for one field spends its context on plumbing. Errors are a teaching surface, not a status code: the platform underneath accepts some malformed requests and answers them with plausible, well-formed, wrong results, so the server recognizes those shapes, refuses them, and returns the correction. Credentials and degradation follow the same rule — per-user tokens whose responses are never cached, and partial answers that mark the inaccessible corner rather than failing the whole call.
Working at this level means the defect is upstream about as often as it is mine. I have filed issues against the MCP Python SDK — a benign client disconnect that produces an ERROR cascade on stateless streamable HTTP, and a non-UTF-8 request body that returns a 500 instead of the parse error it is — each rebuilt as a minimal repro against the upstream package alone. Two more came out of the authenticated MCP gateway I have been building on ToolHive, where corporate sign-in and per-user, per-tool authorization sit in front of internal servers: reading the proxy's source turned up defects in its session and tool-filter paths, the second fixed upstream and shipped in the next release. Every report clears a written gate — independently re-verified, scrubbed of project references, adversarially reviewed — because a public issue is hard to retract, and some findings are deliberately left unfiled. The concrete systems are listed in the Related Projects and Related Experience panels above.