Esqueleto para crear un servidor del Protocolo de Contexto de Modelo (MCP) en Python. Haz un fork de esto cuando necesites exponer un conjunto personalizado de herramientas/datos a Claude Desktop, Claude Code o cualquier cliente compatible con MCP.
MCP es un protocolo abierto que permite a los clientes de modelos de lenguaje llamar a herramientas y fuentes de datos externas a través de una interfaz estándar. Un servidor MCP es el pequeño proceso que aloja esas herramientas: tú escribes las funciones, el protocolo se encarga de la detección y la invocación.
Related MCP server: Test MCP Server
Instálalo directamente desde este repositorio con pipx:
pipx install git+https://github.com/roderickch01/mcp-server-starter.gitLuego regístralo en tu cliente MCP. Para Claude Desktop, edita ~/.config/Claude/claude_desktop_config.json (Linux), ~/Library/Application Support/Claude/claude_desktop_config.json (macOS), o %APPDATA%\Claude\claude_desktop_config.json (Windows) y añade:
{
"mcpServers": {
"starter": {
"command": "mcp-server-starter"
}
}
}Una copia de este fragmento se encuentra en examples/claude_desktop_config.json. Reinicia tu cliente y las herramientas echo y add deberían aparecer.
Dos herramientas de demostración para verificar la conexión:
echo(text: str) -> str — devuelve "echo: {text}"
add(a: int, b: int) -> int — devuelve la suma
Ambas se encuentran en src/mcp_server_starter/server.py (menos de 30 líneas).
Abre server.py y decora cualquier función con @mcp.tool(). La firma, las sugerencias de tipo y el docstring se convierten automáticamente en el esquema de la herramienta:
@mcp.tool()
def reverse(text: str) -> str:
"""Return the input string reversed."""
return text[::-1]Reinstala (pipx reinstall mcp-server-starter) y reinicia tu cliente MCP. La nueva herramienta será detectable.
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 — ver 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…
