Python MCP Server
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., "@Python MCP Serveradd 15 and 27 for me"
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.
Python MCP Server
This is a simple demonstration of a fastmcp server and client.
Setup and Installation (with uv)
This project uses uv for environment and dependency management.
Create the virtual environment:
uv venvActivate the virtual environment:
source .venv/bin/activateInstall the dependencies:
uv pip sync pyproject.toml
Related MCP server: Fast MCP Local
Usage (with uv)
Make sure your virtual environment is activated before running these commands.
Run the MCP server:
uv run python server.pyThe server will start on
localhost:8000.
Usage for gemini
Configue Gemini CLI Add the following configuration on ~/.gemini/settings.json
{ "security": { "auth": { "selectedType": "oauth-personal" } }, "mcpServers": { "serverName": { "command": "/home/<USER>/.local/bin/uv", "args": [ "--directory", "/home/<USER>/code/python-mcp-server", "run", "server.py" ] } } }And yes, the home directory can't be summarized to just "~"
Th server does not need to be running simply run Gemini CLI:
geminiFrom there, you will be able to know if the MCP has been adopted by running the command /mcp list. You should see the tools listed there, similar to this:
ℹConfigured MCP servers: 🟢 serverName - Ready (2 tools) Tools: - addNumbers - greet 💡 Tips: • Use /mcp desc to show server and tool descriptions • Use /mcp schema to show tool parameter schemas • Use /mcp nodesc to hide descriptions • Use /mcp auth <server-name> to authenticate with OAuth-enabled servers • Press Ctrl+T to toggle tool descriptions on/offIn this example you will be able to ask Gemini to greet you or add numbers, as long as you provide enough context to fill in the arguments. If you do not provide arguments, Gemini will ask for more information.
Once all the arguments are provided, Gemini will ask for confirmation before the MCP is hit, and only then will it execute the logic.
Available Tools
2 toolsaddNumbersD
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
greetD
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- First observed
addNumbers - First observed
greet
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: addNumbers performs a mathematical operation, while greet handles a social interaction. There is no overlap or ambiguity between them, making misselection unlikely.
The naming is inconsistent: addNumbers uses camelCase, while greet uses lowercase. There is no predictable pattern across the set, though both names are readable individually.
With only 2 tools, the server feels thin and under-scoped for a general-purpose Python MCP server. This minimal set suggests limited functionality that may not cover typical Python-related tasks.
The tool surface is severely incomplete for a Python server domain. It lacks basic operations like code execution, file handling, or library management, leaving obvious gaps that will cause agent failures in practical scenarios.
Maintenance
Related MCP Connectors
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP server for GLM chat completions using Zhipu AI models via AceDataCloud
Related MCP Servers
- AlicenseDqualityDmaintenanceA simple demonstration MCP server that provides a greeting functionality when integrated with Gemini CLI.1MIT
- AlicenseNot gradedqualityDmaintenanceA minimal FastMCP server implementation that provides basic mathematical and greeting tools. Enables users to perform simple operations like adding numbers and greeting people by name through a lightweight MCP interface.MIT
- FlicenseNot gradedqualityDmaintenanceA demonstration MCP server built with FastAPI that provides basic mathematical operations and greeting services. Integrates with Gemini CLI to showcase MCP protocol implementation with simple REST endpoints.-
- FlicenseNot gradedqualityDmaintenanceA minimal demonstration MCP server that provides basic mathematical addition and greeting functionality, serving as a template for building and deploying FastMCP servers.-