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 ツールが表示されるはずです。
接続を確認するための2つのデモツール：
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…
