Python으로 Model Context Protocol (MCP) 서버를 구축하기 위한 스켈레톤입니다. Claude Desktop, Claude Code 또는 기타 MCP 호환 클라이언트에 사용자 지정 도구/데이터 세트를 노출해야 할 때 이 저장소를 포크하여 사용하세요.
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…
