MCP TypeScript SDK: One Plugin to Serve All AI Assistants?

Title

MCP TypeScript SDK: One Plugin to Serve All AI Assistants?

Meta Description

MCP TypeScript SDK lets TypeScript developers connect one server to multiple AI assistants, with support for registering tools, resources, and prompts. This article examines its schema validation, local and HTTP deployment capabilities, and the security costs and protocol evolution risks of self-hosting.

Article Content

AI assistants, code editors, and agents are becoming the new entry points for how users interact with applications. But each platform has its own plugin mechanism, and developers who want their app to appear across all AI tools often have to build and maintain a separate integration for every entry point. The MCP (Model Context Protocol) TypeScript SDK attempts to solve this fragmentation problem—officially likened to "the USB-C port for AI applications."

A Unified Entry Point: Build Once, Run Everywhere

The core idea of MCP is to describe application capabilities with a single protocol. Developers register "tools" to perform actions, "resources" to provide data, and "prompts" for users to select. An AI assistant's MCP client lists these capabilities; when the model invokes a tool, your function executes and the result is returned to the model. According to the official documentation, the SDK is open source under a dual Apache and MIT license, and has surpassed 13,000 GitHub stars.

This means you no longer need to write separate plugins for VS Code, Cloud Code, and Cursor. The SDK guide notes that a single startup command is all it takes to connect these environments. For TypeScript developers, one MCP server can serve multiple assistants simultaneously.

The three primitive types in MCP—"tools," "resources," and "prompts"—have clearly defined roles. Tools are functions the model can actively invoke, usually with side effects, such as sending an email or querying a database; resources are read-only data endpoints, similar to files or API responses, and the client decides whether to load them into context; prompts are preset templates that users explicitly trigger from a selector. This division lets the model distinguish between "actions it can perform" and "data it can read," and makes it easier for clients to control permissions and context size on demand. Understanding the boundaries between these three is a prerequisite for designing a server that conforms to the MCP specification.

Three Practical Capabilities of the SDK

1. Schema-Driven Input Validation

Tool inputs only need to be described once with a schema. The SDK rejects invalid calls before your code runs, keeping parameter errors out of your business logic and reducing runtime exceptions.

The schema here typically refers to JSON Schema, which the MCP specification uses to describe the types, required fields, and constraints of tool input parameters. The SDK converts this schema into runtime validation logic and checks parameters before invoking your handler function. Because JSON Schema is itself a language-agnostic standard, the same tool definition can be read and rendered into forms by clients in different languages—this is also the foundation for MCP's cross-assistant reusability. For TypeScript developers, schemas can also be linked with type definitions, reducing the work of writing validation code by hand.

2. Flexible Deployment Options

A server can run locally over standard input/output, or be deployed as an HTTP endpoint for web-based AI assistants to call. The same codebase covers both local and remote scenarios.

The standard input/output (stdio) transport is suited to local processes: the client starts the server as a subprocess and communicates over pipes, requiring no network port, making it a natural fit for desktop AI assistants. The HTTP endpoint targets remote or web scenarios, typically paired with Server-Sent Events (SSE) or streaming HTTP for server-to-client push. Both transports share the same tool definitions; the differences mainly lie in connection establishment and session management. Which one to choose depends on whether your users run assistants locally or access a hosted service through a browser.

3. Build Clients Too

The SDK is not only for writing servers; it also supports building MCP clients.

Hosting and Security Are Your Responsibility

Convenience comes at a cost. The SDK validates access tokens but does not issue them; hosting and security protection for the server are entirely the developer's responsibility. The specification requires servers to validate tool inputs, control access, rate-limit calls, and sanitize outputs. These are not optional suggestions but mandatory work when deploying an MCP service.

If you don't want to self-host, Composio offers a ready-made hosted app tools solution, with a free plan available to try.

Access token validation in the MCP specification is typically based on the OAuth 2.1 flow: the server needs to verify the token's signature, expiration, and authorization scope, but token issuance and user authorization must be integrated with your own identity provider. On rate limiting, since tool calls can trigger expensive backend operations, it's advisable to set quotas per client or per user. Output sanitization addresses the risk of the model being induced to perform dangerous actions, escaping or whitelist-filtering returned content. Together, these requirements form the security baseline before an MCP server goes live.

The Protocol Is Still Evolving Rapidly

MCP is not a static specification. According to the video, July brought specification revisions and SDK version 2. Different assistants also vary in their support for MCP features, which means "write once, run everywhere" still requires adaptation testing for specific clients in practice.

Who Is It For

This SDK is aimed at TypeScript developers who want one server to serve multiple AI assistants and who are capable of secure operations. The onboarding path is straightforward: follow the SDK's "first server" guide, install dependencies, add a tool, then verify by invoking it from the MCP inspector.

For small teams, before deciding to build it themselves, it's worth evaluating the monthly cost of hosted solutions against the operational investment required for self-hosting. Security requirements (token issuance, rate limiting, output sanitization) significantly affect the workload—this is the most easily underestimated part when choosing the self-hosted route.

One-line Summary

MCP TypeScript SDK uses a unified protocol to connect one server to multiple AI assistants, but hosting and security are on you.

Paragraph Summary

The MCP TypeScript SDK is the official toolkit for the Model Context Protocol, designed to solve the fragmentation of plugin mechanisms across AI assistants, code editors, and agents—likened to "the USB-C port for AI applications." Developers describe tool inputs with schemas, and the SDK rejects invalid calls before code executes; servers support both local stdio and HTTP endpoint deployment, with one codebase covering local and remote scenarios, and can also be used to build MCP clients. But the SDK only validates access tokens without issuing them, leaving hosting, rate limiting, output sanitization, and other security responsibilities entirely to developers. The protocol is still evolving rapidly—July brought specification revisions and SDK version 2—and feature support varies across assistants, so real-world deployment still requires client-specific adaptation testing.