@modelcontextprotocol/sdk (TypeScript)

This isn't a client in the sense of Claude Desktop or Cline. It's the official TypeScript SDK for building your own MCP servers and clients. If you're writing Node tooling that needs to speak MCP, this is the reference implementation. I've used it to build half a dozen custom servers, from filesystem watchers to API wrappers. The API surface is clean: you define tools, resources, or prompts as handlers, then call `server.connect()`. The SDK handles transport (stdio or SSE), protocol negotiation, and error marshalling. Documentation is thorough, with working examples for every capability. The types are tight enough to catch mistakes early without drowning you in generics. What sets it apart is completeness. Full support for all four MCP primitives (tools, resources, prompts, sampling), plus progress notifications and cancellation. The sampling capability lets your server call back into the LLM mid-request, which most third-party SDKs skip. Transport flexibility means you can run servers as stdio subprocesses (the common case) or expose them over HTTP for remote access. The rough edges are mostly about Node itself. Stdio transport requires careful stream handling, especially on Windows. Error messages from protocol violations can be terse. The SDK assumes you understand async iterators and signal handling; there's no hand-holding. Debugging is harder than it should be because most clients swallow stderr. I've learned to log to files early. Config is minimal: you import the SDK, define handlers, start the server. No YAML, no magic. But you're responsible for argument validation, rate limiting, authentication if you expose over HTTP. The SDK gives you primitives, not batteries-included middleware. I reach for this when I need full control or when the server logic is complex enough to warrant TypeScript's type system. For quick Python scripts, I use the Python SDK instead. For production services that need to expose MCP alongside REST, this is the only real choice. Performance is fine for typical workloads (dozens of tool calls per minute). I haven't stress-tested it at scale, but the architecture is simple enough that bottlenecks would be in your handlers, not the SDK. One gotcha: versioning moves fast. The protocol is still pre-1.0, so expect minor breaking changes. Pin your SDK version and test before upgrading.