Click on "Install 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., "@mcp-server-starter echo hello world"
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.
Skeleton for building a Model Context Protocol (MCP) server in Python. Fork this when you need to expose a custom set of tools/data to Claude Desktop, Claude Code, or any MCP-compatible client.
MCP is an open protocol that lets language-model clients call into external tools and data sources through a standard interface. An MCP server is the small process that hosts those tools — you write the functions, the protocol handles discovery and invocation.
Related MCP server: Test MCP Server
Install directly from this repository with pipx:
pipx install git+https://github.com/roderickch01/mcp-server-starter.gitThen register it with your MCP client. For Claude Desktop, edit ~/.config/Claude/claude_desktop_config.json (Linux), ~/Library/Application Support/Claude/claude_desktop_config.json (macOS), or %APPDATA%\Claude\claude_desktop_config.json (Windows) and add:
{
"mcpServers": {
"starter": {
"command": "mcp-server-starter"
}
}
}A copy of this snippet lives at examples/claude_desktop_config.json. Restart your client and the echo and add tools should appear.
Two demo tools to verify the wiring:
echo(text: str) -> str — returns "echo: {text}"
add(a: int, b: int) -> int — returns the sum
Both live in src/mcp_server_starter/server.py (under 30 lines).
Open server.py and decorate any function with @mcp.tool(). The signature, type hints, and docstring become the tool's schema automatically:
@mcp.tool()
def reverse(text: str) -> str:
"""Return the input string reversed."""
return text[::-1]Reinstall (pipx reinstall mcp-server-starter) and restart your MCP client. The new tool is discoverable.
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 — see 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. Dates show when Glama detected each change.
v0.1.0addechoThe 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/roderickch01/mcp-server-starter'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
