SDK (Software Development Kit)
An SDK is a collection of libraries, tools, code samples, and documentation that helps developers build against a specific platform or protocol.
Also known as: devkit, client library
What is an SDK?
A software development kit (SDK) is everything a platform vendor or protocol maintainer packages up so developers can build against their system without reimplementing it from scratch: libraries that wrap the raw interface, type definitions, code samples, test utilities, and documentation. Where an API is the contract, the SDK is the toolbox for honoring it.
Good SDKs collapse weeks of protocol-reading into an afternoon of coding. They encode the maintainer's knowledge of edge cases — retries, encoding rules, version negotiation — so each developer does not rediscover them in production.
SDK vs API: the distinction
An API defines what requests a system accepts and what responses it returns; it exists whether or not anyone wraps it. An SDK is a concrete artifact — usually a package on npm or PyPI — that speaks that API for you in your language, with native types and idiomatic error handling. You can always call an API directly over HTTP; you use the SDK because hand-rolling request framing and auth for every call is wasted effort and a source of bugs.
The official MCP SDKs
The Model Context Protocol project maintains official SDKs in multiple languages — TypeScript and Python are the most used, with others including Java, Kotlin, C#, and Go. They handle the protocol plumbing: JSON-RPC 2.0 framing, transport setup over stdio or Streamable HTTP, capability negotiation, and the lifecycle of requests and notifications.
The practical effect is that an MCP server author writes almost no protocol code. Registering a tool is a function call with a name, a schema, and a handler; the SDK does the rest. The same applies on the client side, where the SDK manages connecting to servers and dispatching tool invocations.
SDKs in agentic commerce
Payment protocols follow the same pattern as transport protocols: the standard defines the wire format, and SDKs make it usable. On the seller side, x402 middleware libraries let a server answer unpaid requests with HTTP 402 and verify payment headers before the handler runs; Loomal's @loomal/sdk reduces MCP monetization to wrapping a tool registration with requirePayment(). On the buyer side, wallet SDKs let an agent detect a 402 response, sign a USDC payment, and retry — without the agent's business logic knowing payments exist.
When the SDK boundary is drawn well, the entire commercial layer — pricing, settlement on Base, Ed25519 receipts — lives in library code rather than in every developer's application.
Evaluating an SDK before depending on it
Before adopting an SDK, check maintenance signals: release cadence against protocol revisions, issue responsiveness, and whether it is the official implementation or a community port. For MCP work specifically, SDK version matters because the protocol has evolved — Streamable HTTP superseded the older SSE transport, and an outdated SDK can quietly lock you to deprecated behavior. The Loomal Index records each listed server's package name and registry, which is a quick way to see what an implementation is actually built on.