MCPサーバーをTypeScriptで初めて作ってInspectorで叩いてみた（v2ベータ）A hands-on beginner's guide to building an MCP server in TypeScript targeting…

The Model Context Protocol (MCP) has quickly become a common way to connect large language models to external tools, data sources, and services, and this tutorial walks through building a working MCP server in TypeScript before validating it with the MCP Inspector. For developers new to the ecosystem, the appeal is practical: rather than wiring bespoke integrations into each AI client, an MCP server exposes capabilities through a standardized interface that any compatible host can consume. The article targets the v2 beta specification, which makes it a useful reference point for those tracking how the protocol is evolving.

At a high level, MCP defines a client-server relationship in which a host application, such as an AI assistant or an IDE plugin, launches or connects to one or more servers. Each server can advertise tools that the model may call, resources it can read, and prompts it can reuse. The protocol was originally introduced by Anthropic and has since attracted a broader set of implementations and SDKs. TypeScript is a natural starting point because the official SDK is well maintained and the Node.js toolchain is familiar to many web developers, lowering the barrier to a first working prototype.

The tutorial appears to follow a conventional setup path. That typically means initializing a Node project, adding the MCP TypeScript SDK as a dependency, and configuring the project for modern module resolution and TypeScript compilation. Beginners often stumble at exactly this stage, and the piece emphasizes those pitfalls: mismatches between CommonJS and ES modules, incorrect "type" fields in package.json, TypeScript target and module settings that do not align with the SDK, and path or build output issues that prevent the server from starting cleanly. Getting the build and run commands right is a prerequisite before any protocol-level behavior can be tested.

Once the scaffolding is in place, the core work is defining the server and registering at least one tool. A tool in MCP is essentially a named function with a described input schema and a handler that returns structured results. Input validation is commonly handled with a schema library, and the SDK exposes the tool metadata so that clients can discover what is available and how to call it. The v2 beta spec may introduce changes to how capabilities are declared, how content is structured, or how transports are negotiated, so readers following along should verify details against the current specification and SDK version, since beta interfaces are likely to shift before a stable release.

Transport is another key decision. MCP servers frequently communicate over standard input and output, which is convenient for locally launched processes, while HTTP-based transports suit remote or networked deployments. The choice affects how the server is started and how a client connects to it. For a first project, the stdio transport is usually the simplest, because the Inspector or a host can spawn the process directly and exchange JSON-RPC messages without additional network configuration.

The verification step is where the MCP Inspector earns its place. The Inspector is an interactive tool for exercising a server without needing a full AI client in the loop. It lets a developer connect to the server, list the advertised tools, inspect their schemas, and invoke them with sample arguments to confirm the responses. This tight feedback loop is valuable for debugging, since it isolates server behavior from the complexity of a model deciding when and how to call a tool. Confirming that a tool call returns the expected payload in the Inspector is a strong signal that integration with a real host will behave predictably.

For context, MCP sits alongside a growing set of related efforts to standardize how AI systems reach external capabilities, and it is already supported by desktop assistants and several coding tools. Building a server by hand, as this guide does, clarifies what those integrations are doing under the hood. Readers should treat v2 beta specifics as provisional and pin their SDK and Inspector versions, but the end-to-end workflow described here, from project setup through tool definition to Inspector-based validation, reflects the typical path for anyone starting to build on MCP today.