Production-ready MCP SDK for TypeScript with automatic Bun optimization, streamable HTTP transport, and real-time session management
This TypeScript MCP SDK demonstrates solid tool definition practices with complete schemas and reasonable descriptions for all 4 tools. All tools are READ_ONLY arithmetic/math functions with proper Zod schema validation. Naming follows verb_noun convention (calculate, power, sqrt, factorial). Descriptions are present and adequate (28-75 characters), though on the shorter end for complex parameter relationships. All parameters have proper type definitions and descriptions. However, the tool set is narrow (math-only), lacking natural identifier acceptance and some error-recovery guidance expected in production tools. The SDK itself is well-structured with generator-based handlers and streamable HTTP transport, but the example tools don't fully exercise best practices around error handling, pagination, or complex composition patterns.
Perform basic arithmetic operations (add, subtract, multiply, divide)
Calculate the factorial of a non-negative integer
Calculate a number raised to a power
Calculate the square root of a number
Descriptions are generic and lack WHEN-to-use guidance. 'Calculate a number raised to a power' does not explain when an LLM should select this over other math tools or what typical use cases are. LLMs need explicit use-case context.
No error recovery guidance. Tool descriptions do not explain what happens on invalid input (e.g., negative number to sqrt, n > 20 to factorial). LLMs need to know whether to retry, ask the user, or select an alternative tool.
Missing error categorization. Handlers do not distinguish between retryable errors (transient failure), user-fixable errors (invalid input), and fatal errors (constraint violation). This prevents intelligent error recovery by agents.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 79 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 53 | - | v1 |
No parameter constraints in descriptions. Descriptions state 'Integer from 0 to 20' for factorial but do not explain in plain text what happens if the constraint is violated. LLMs cannot read JSON Schema 'minimum' and 'maximum' fields, they rely on description text.
Output schema not documented. Tool definitions do not explicitly state what the handler returns (e.g., TextResponse with numeric result). LLMs cannot plan downstream composition without knowing the response structure.