Click on "Deploy 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 Template reverse the string '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.
A minimal MCP (Model Context Protocol) server template managed with uv, exposing a string-reversal tool and basic two-integer arithmetic tools (add, subtract, multiply, divide).
uv for dependency management
TOML + Pydantic based config
reverse_string tool
add / subtract / multiply / divide tools
Centralized logging (loguru)
Custom exception handling
Standalone stdio client for manual testing
Related MCP server: DDG MCP1234
The directory structure of the project looks like this:
āāā LICENSE
āāā Makefile
āāā README.md
āāā client.py
āāā main.py
āāā configs
ā āāā config.toml
āāā outputs
āāā pyproject.toml
āāā src
āāā __init__.py
āāā app.py
āāā server
ā āāā __init__.py
ā āāā server.py
āāā utils
āāā __init__.py
āāā config.py
āāā exceptions.py
āāā logger.py
āāā models.pyuv syncuv run python main.py
# or
make runThe server communicates over stdio and is meant to be launched by an MCP client (see Step 3), not run standalone in a terminal.
uv run python client.py
# or
make clientThis spawns main.py as a subprocess over stdio, lists the available tools, then prompts you to try reverse_string and the arithmetic tools.
uv run mcp dev main.py:mcpOpens a browser UI to browse and call the registered tools interactively. main.py exposes a lazily-built mcp attribute for this purpose (see __getattr__ at the bottom of the file) ā normal runs via make run / make client don't trigger it.
Add 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 full burden. It only states the basic operation without addressing edge cases (e.g., overflow), return value, or any side effects. The output schema exists but the description adds no behavioral context.
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 extremely concise at 4 words, with no wasted language. It is front-loaded and efficient for its 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?
For a simple addition tool with an output schema, the description is sufficient. It clearly conveys the core functionality without needing additional context. The tool is low complexity.
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% (no descriptions in the schema) and the description adds no meaning beyond the schema. It says 'two integers' but does not explain the roles of parameters 'a' and 'b' or their order, though addition is commutative.
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 'Add two integers' clearly states the verb (add) and the resource (two integers). It distinguishes from sibling tools like divide, multiply, subtract, and reverse_string by specifying the addition operation.
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 like subtract or multiply. The description provides no context about when addition is appropriate or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Divide the first integer by the second
| 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 provided, so the description must disclose behavior. It does not specify integer division semantics (floor, truncation, etc.) or error handling for division by zero.
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 that is front-loaded with the core action. It is appropriately sized for a simple arithmetic tool.
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?
Given the tool's simplicity and the presence of an output schema, the description is minimally adequate but lacks behavioral details like integer division specification and error handling.
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 only says 'first integer' and 'second integer', adding no extra meaning beyond the parameter names. No constraints like non-zero for b are mentioned.
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 specifies the verb 'divide' and the resource 'the first integer by the second'. It is concise and distinguishes the tool from siblings like add, multiply, and subtract.
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 vs alternatives. For example, it does not mention that division by zero is invalid or that integer division may truncate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multiply 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?
Without annotations, the description provides no details beyond the basic operation, omitting edge cases or error handling.
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 remarkably concise and front-loaded, though it could include a brief behavioral note without losing efficiency.
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?
Given the tool's simplicity and presence of an output schema, the description is adequate but not exhaustive.
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?
The description adds no meaning beyond the schema; parameter names 'a' and 'b' are clear but no additional context is given.
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 'Multiply two integers' clearly states the action and resource, distinguishing it from sibling tools like 'add' and 'divide'.
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 instead of siblings, but the purpose is implied for multiplication scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reverse a given string
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'Reverse a given string.' It does not disclose any edge cases, performance characteristics, or side effects. For a simple transformation, this is adequate but minimal.
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, clear sentence with no unnecessary words. It is front-loaded and efficient.
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?
Given the tool's simplicity, the description provides enough information. An output schema exists to clarify return values, so the description does not need to cover that.
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 coverage is 0%, and the description adds no parameter details beyond the schema. However, the single parameter 'text' is self-explanatory given the tool's purpose.
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 states the exact operation: reversing a string. It is a specific verb and resource. Sibling tools are all math operations, so it clearly distinguishes itself.
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. However, the sibling tools are all arithmetic, making the usage context implicitly clear for string reversal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Subtract the second integer from the first
| 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 correctly specifies the order of subtraction (second from first) but does not mention any behavioral traits like error handling, integer overflow, or return type, though the output schema likely covers the return type. The description is adequate for a simple pure function.
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 one sentence with no superfluous words. It is front-loaded and directly conveys the necessary information without waste.
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?
Given the tool's simplicity and the presence of an output schema (as indicated by context signals), the description provides sufficient context for an agent to understand the operation. It could optionally mention that it returns an integer, but that is already covered by the output schema.
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?
The input schema has 0% description coverage, leaving parameters 'a' and 'b' without textual context. The description compensates by clarifying that 'a' is the first integer and 'b' is the second, establishing the order of subtraction. This adds meaningful semantic context beyond the schema.
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 operation: subtract the second integer from the first. The verb 'subtract' and the resource (two integers) are explicit, and it naturally distinguishes the tool from siblings like 'add', 'multiply', and 'divide'.
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 when-to-use or when-not-to-use guidance is provided. However, the tool is a basic arithmetic operation, so its usage context is implied. It does not mention alternatives or scenarios where other tools would be better, but the simplicity reduces the need for extensive guidelines.
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.0adddividemultiplyreverse_stringsubtractScored across 5 tools
Each tool has a clear, distinct purpose: four basic arithmetic operations on integers and one string reversal. There is no overlap in functionality.
All tool names are verbs or verb_noun in lowercase with underscores where needed, following a consistent pattern (e.g., add, divide, reverse_string).
With 5 tools, the count is well within the ideal range (3-15) and each tool serves a distinct function.
The arithmetic operations are basic but missing common ones like modulo or power. The single string operation feels isolated and incomplete without other string utilities.
MCP server for progressive tool usage at any scale (see https://klavis.ai)