Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Minimum Viable MCP Project calculate the sum of 12 and 30"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
这个项目是一个可直接跑通的 MCP 学习样例，包含完整链路：
写 MCP Server（Tool / Resource / Prompt）
本地用 MCP Client 调用并验证
接入 Codex，让 Codex 直接调用你的 MCP 能力
Node.js >= 22（用 --experimental-strip-types 直接运行 TS）
npm >= 9
Related MCP server: JSON MCP Boilerplate
.
├── src
│ ├── server.ts # MCP server (stdio)
│ └── smoke-client.ts # 本地全流程验证客户端
├── tsconfig.json
├── package.json
└── README.mdnpm installnpm run devnpm run startnpm run smoke这个命令会：
在同一个进程内创建 MCP server/client（InMemoryTransport）
用 src/smoke-client.ts 依次调用：
listTools
callTool(sum_numbers)
readResource(note://quickstart)
getPrompt(review_snippet)
ping: 健康检查
sum_numbers: 两数求和，返回文本 + 结构化结果
note://quickstart: 学习提示文本
review_snippet(language, snippet): 生成可复用的 code review prompt
推荐使用 Codex CLI 命令直接添加 MCP server。
codex mcp add learning-mcp -- node --experimental-strip-types /home/fezhang/mcp/src/server.tscodex mcp list
codex mcp get learning-mcp你可以直接对 Codex 说：
列出 learning-mcp 的工具
调用 sum_numbers，a=12，b=30
读取资源 note://quickstart
codex mcp remove learning-mcpMCP stdio 协议使用 stdin/stdout 传输 JSON-RPC。
如果把日志写到 stdout，会污染协议消息，导致调用失败。
src/server.ts 之后，Codex 什么时候生效？这个样例是直接执行 src/server.ts。
下次启动新的 MCP server 进程就会生效，不需要构建。
给 sum_numbers 增加输入边界校验（如最大值）。
增加一个会访问真实 API 的 Tool（例如天气查询）。
再加一个 ResourceTemplate 学习动态资源模式。
Quick health check. Returns current server timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the action ('Returns current server timestamp'), which implies a read-only operation, but does not detail aspects like response format, error handling, or performance characteristics. It adds basic context but lacks comprehensive behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of two short sentences that efficiently convey the tool's purpose and output. Every sentence earns its place without any wasted words, making it highly effective in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is complete enough for a health check tool. It explains what the tool does and what it returns, though it could benefit from more detail on behavioral aspects like error cases or usage constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter information is needed. The description does not add parameter semantics, but this is acceptable given the absence of parameters, aligning with the baseline score for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Quick health check') and resource ('server timestamp'), distinguishing it from the sibling tool 'sum_numbers' which performs mathematical operations. It precisely communicates what the tool does without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('health check') but does not explicitly state when to use this tool versus alternatives or provide exclusions. It offers clear context for its purpose but lacks detailed guidance on specific scenarios or comparisons with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add two numbers and return structured output.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | First number | |
| b | Yes | Second number |
| Name | Required | Description |
|---|---|---|
| result | Yes | |
| expression | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'return structured output,' which hints at the return format, but doesn't specify what that structure entails, error handling, or any constraints like numeric limits. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any wasted words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (basic arithmetic), 2 parameters with full schema coverage, and the presence of an output schema, the description is reasonably complete. It covers the core purpose and hints at the output, though it could benefit from more behavioral details given the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('a' and 'b'). The description adds no additional meaning beyond the schema, as it doesn't explain parameter interactions or constraints. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add two numbers') and the resource ('numbers'), making the purpose immediately understandable. However, it doesn't distinguish from the sibling 'ping' tool, which is unrelated, so it doesn't fully differentiate from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or in what context it should be applied. It simply states what it does without any usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0pingsum_numbersScored across 2 tools
The two tools have completely distinct purposes: ping is a health check returning a timestamp, while sum_numbers performs arithmetic addition. There is no overlap or ambiguity between them, making it trivial for an agent to select the correct tool.
The tools use a consistent snake_case naming convention, but the verb patterns differ slightly: ping is a single verb, while sum_numbers is a verb_noun combination. This minor deviation keeps the naming mostly consistent and readable.
With only two tools, the server feels thin and under-scoped for a general-purpose project. While it might be minimal by design, such a limited set restricts functionality and suggests an incomplete or overly narrow implementation.
The tool surface is severely incomplete for any meaningful domain. There are no CRUD operations, lifecycle management, or coherent workflows; the tools are isolated utilities with no apparent coverage of a broader purpose, leading to significant gaps for agent tasks.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A simple Typescript MCP server built using the official MCP Typescript SDK and smithery/cli. This…
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
A Model Context Protocol server for Wix AI tools