用于使用 Python 构建模型上下文协议 (MCP) 服务器的骨架。当你需要向 Claude Desktop、Claude Code 或任何兼容 MCP 的客户端公开一组自定义工具/数据时，请 fork 此项目。
MCP 是一种开放协议，允许语言模型客户端通过标准接口调用外部工具和数据源。MCP 服务器是托管这些工具的小型进程——你编写函数，协议负责处理发现和调用。
Related MCP server: Test MCP Server
使用 pipx 直接从本仓库安装：
pipx install git+https://github.com/roderickch01/mcp-server-starter.git然后将其注册到你的 MCP 客户端。对于 Claude Desktop，请编辑 ~/.config/Claude/claude_desktop_config.json (Linux)、~/Library/Application Support/Claude/claude_desktop_config.json (macOS) 或 %APPDATA%\Claude\claude_desktop_config.json (Windows)，并添加：
{
"mcpServers": {
"starter": {
"command": "mcp-server-starter"
}
}
}此代码片段的副本位于 examples/claude_desktop_config.json。重启你的客户端，echo 和 add 工具就会出现。
两个用于验证连接的演示工具：
echo(text: str) -> str — 返回 "echo: {text}"
add(a: int, b: int) -> int — 返回两数之和
两者都位于 src/mcp_server_starter/server.py 中（不到 30 行代码）。
打开 server.py 并使用 @mcp.tool() 装饰任何函数。函数签名、类型提示和文档字符串将自动成为工具的模式：
@mcp.tool()
def reverse(text: str) -> str:
"""Return the input string reversed."""
return text[::-1]重新安装 (pipx reinstall mcp-server-starter) 并重启你的 MCP 客户端。新工具即可被发现。
git clone https://github.com/roderickch01/mcp-server-starter.git
cd mcp-server-starter
python -m venv .venv && source .venv/bin/activate
pip install -e .
mcp-server-starter # runs the server over stdioMIT — 参见 LICENSE。
Return the sum of two integers.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It accurately describes a pure mathematical operation with no side effects, but does not discuss edge cases like overflow or error handling for non-integer inputs (though schema enforces integers).
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 sentence with no extraneous information, achieving maximum conciseness while conveying the essential purpose.
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?
The tool is simple with two parameters and an output schema (though not shown). The description covers input, operation, and output adequately. Missing a note on edge cases is minor for such a straightforward tool.
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?
Schema description coverage is 0%, and the description adds no information about the parameters beyond what is already in the schema. The parameters 'a' and 'b' are self-explanatory as integers to be summed, but the description does not elaborate on their role or any constraints.
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 it returns the sum of two integers, using a specific verb and resource. It is distinct from the sibling tool 'echo' which does something entirely different.
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?
No explicit guidance on when to use this tool versus alternatives. The only sibling is 'echo', which is unrelated, leaving usage implicitly clear but without explicit recommendations or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the input prefixed with 'echo: '.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly describes the transformation (prefixing with 'echo: '), which is simple and transparent. No hidden behaviors are indicated.
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?
Single sentence, front-loaded, every word earns its place. Extremely concise.
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?
For a simple tool with one parameter and clear output, the description is complete. The output schema exists but is not needed as the return format is explicitly stated.
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?
Schema description coverage is 0%, so description adds no parameter info beyond what schema provides. However, the single parameter 'text' is self-explanatory given the tool's purpose, so the schema suffices.
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 returns the input prefixed with 'echo: '. It identifies the specific verb 'Return' and resource 'input', and distinguishes from sibling 'add' which likely has a different purpose.
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?
No guidance on when to use this tool versus alternatives. The description implies usage for echoing input, but lacks explicit 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.0addechoScored across 2 tools
The two tools have clearly distinct purposes: 'add' handles integer arithmetic, while 'echo' handles string manipulation. There is no overlap or potential for confusion.
Both tool names are single, lowercase verbs ('add', 'echo'), following a consistent and predictable pattern.
With only 2 tools, the set is minimal. While this may be appropriate for a 'starter' server, it is on the low end and could feel thin for general use.
The two tools are unrelated (one math, one string), and there is no coherent domain being covered. The surface feels incomplete for any meaningful workflow, lacking operations like subtraction, string concatenation, etc. if intended as a utility set.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
