MVP scope

Published package: @theorvane/type-mcp@0.2.2 includes this MVP's metadata, validation, resolver, compiler, stdio, HTTP, and tools-only LangChain adapter. Start with the README (opens in a new tab) and getting-started guide for exact exports and boundaries.

Status: Implemented and published in @theorvane/type-mcp@0.2.2: decorator metadata storage, definition validation, the instance resolver seam, compiler behavior, the Node stdio helper, the Fetch Streamable HTTP adapter, and the tools-only LangChain adapter.

Included

CapabilityMVP boundary
Server declaration@McpServer({ name, version }) on a class
Tools@McpTool() with name/description and Zod object input schema
Resources@McpResource() for explicit static URIs
Prompts@McpPrompt() for named prompt handlers
CompilationDecorator metadata compiled to @modelcontextprotocol/sdk McpServer
Instance constructionDirect constructor default plus async-capable InstanceResolver interface
Local transportstdio helper
Web transportFetch-standard Streamable HTTP handler
Agent tool integration@theorvane/type-mcp/langchain converts decorated tools; LangGraph ToolNode composition is consumer-owned
Developer qualitystrict TS, Vitest, tsup build, CI, examples, README

Deferred

CapabilityWhy deferred
OAuth/authenticationRequires explicit threat model, identity contract, and deployment guidance.
Redis or external session storageSDK transport/session semantics must be proven locally first.
Legacy SSE transportStreamable HTTP is the modern target transport for the MVP.
Dynamic resource URI templatesStatic resource semantics provide a smaller, testable first surface.
Prompt argument inferenceExplicit options avoid unstable reflection behavior.
Multi-server route registryOne compiled server per handler keeps the first adapter simple.
Additional release automationInitial publication is complete. Future versions use the reviewed dev to main promotion and OIDC Trusted Publishing workflow.

Constraints

Change control

Any deferred item requires: (1) a dedicated product/architecture decision, (2) a behavior table in docs/api/, (3) failing tests for new safety or compatibility gates, and (4) a revised implementation plan before code begins.