my-mcp-server
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., "@my-mcp-serverget the weather for London"
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.
my-mcp-server
my-mcp-server is a Model Context Protocol (MCP) server built with FastMCP featuring dynamic tool loading.
Features
Dynamic Tool Loading: Tools are automatically discovered and loaded from
src/tools/One Tool Per File: Each tool is a single file with a function matching the filename
FastMCP Integration: Leverages FastMCP for robust MCP protocol handling
Configuration Management: Tool-specific configuration via
mcp.yamlFail-Fast: Server won't start if any tool fails to load
Auto-Generated Tests: Automatic test generation for tool validation
Related MCP server: BuildMcpServer
Project Structure
src/
├── tools/ # Tool implementations (one file per tool)
│ ├── echo.py # Example echo tool
│ └── __init__.py # Auto-generated tool registry
├── core/ # Dynamic loading framework
│ ├── server.py # Dynamic MCP server
│ └── utils.py # Shared utilities
└── main.py # Entry point
mcp.yaml # Configuration file
tests/ # Generated testsQuick Start
Option 1: Local Development (with Python/uv)
Install Dependencies:
uv syncRun the Server:
# Stdio mode (default MCP transport) uv run python src/main.py # HTTP mode with WebSocket MCP endpoint uv run python src/main.py --http # HTTP mode with custom host/port uv run python src/main.py --http --host 0.0.0.0 --port 8080Using uv Scripts:
# Development mode (HTTP on port 3000) uv run dev # HTTP mode uv run dev-http # Stdio mode uv run startAdd New Tools:
# Create a new tool (no tool types needed!) arctl mcp add-tool weather # The tool file will be created at src/tools/weather.py # Edit it to implement your tool logic
Option 2: Docker-Only Development (no local Python/uv required)
Build Docker Image:
arctl mcp build --verboseRun in Container:
docker run -i my-mcp-server:latestAdd New Tools:
# Create a new tool arctl mcp add-tool weather # Edit the tool file, then rebuild arctl mcp build
HTTP Transport Mode
The server supports running in HTTP mode for development and integration purposes.
Starting in HTTP Mode
# Command line flag
python src/main.py --http
# Environment variable
MCP_TRANSPORT_MODE=http python src/main.py
# Custom host and port
python src/main.py --http --host localhost --port 8080Creating Tools
Basic Tool Structure
Each tool is a Python file in src/tools/ containing a function decorated with @mcp.tool():
# src/tools/weather.py
from core.server import mcp
from core.utils import get_tool_config, get_env_var
@mcp.tool()
def weather(location: str) -> str:
"""Get weather information for a location."""
# Get tool configuration
config = get_tool_config("weather")
api_key = get_env_var(config.get("api_key_env", "WEATHER_API_KEY"))
base_url = config.get("base_url", "https://api.openweathermap.org/data/2.5")
# TODO: Implement weather API call
return f"Weather for {location}: Sunny, 72°F"Tool Examples
The generated tool template includes commented examples for common patterns:
# HTTP API calls
# async with httpx.AsyncClient() as client:
# response = await client.get(f"{base_url}/weather?q={location}&appid={api_key}")
# return response.json()
# Database operations
# async with asyncpg.connect(connection_string) as conn:
# result = await conn.fetchrow("SELECT * FROM weather WHERE location = $1", location)
# return dict(result)
# File processing
# with open(file_path, 'r') as f:
# content = f.read()
# return {"content": content, "size": len(content)}Configuration
Configure tools in mcp.yaml:
tools:
weather:
api_key_env: "WEATHER_API_KEY"
base_url: "https://api.openweathermap.org/data/2.5"
timeout: 30
database:
connection_string_env: "DATABASE_URL"
max_connections: 10Testing
Run the generated tests to verify your tools load correctly:
uv run pytest tests/Development
Adding Dependencies
Update pyproject.toml and run:
uv syncCode Quality
uv run black .
uv run ruff check .
uv run mypy .Deployment
Docker
# Build image (handles lockfile automatically)
arctl mcp build
# Run container
docker run -i my-mcp-server:latestAvailable Tools
1 toolechoB
Echo a message back to the client.
Args: message: The message to echo
Returns: The echoed message with any configured prefix
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the echoed message may include 'any configured prefix,' which adds some context about output behavior. However, it lacks details on error handling, rate limits, authentication needs, or other behavioral traits, leaving significant gaps.
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 well-structured and concise, with clear sections for purpose, arguments, and returns. Every sentence earns its place, and it's front-loaded with the main functionality, making it efficient and easy to parse without any wasted words.
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 low complexity (one parameter) and the presence of an output schema, the description is reasonably complete. It explains the purpose, parameter, and return behavior, though it could benefit from more behavioral context. The output schema reduces the need to detail return values, so it's mostly adequate.
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 includes an 'Args' section that explains the 'message' parameter as 'The message to echo,' adding meaning beyond the input schema, which has 0% description coverage. However, it doesn't provide details on format constraints, length limits, or examples, so it only partially compensates for the schema's lack of descriptions.
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's purpose: 'Echo a message back to the client.' This specifies the verb ('echo') and the resource ('message'), making it easy to understand what the tool does. However, since there are no sibling tools, it doesn't need to differentiate from alternatives, so it doesn't reach the highest score of 5.
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?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or context for its application. It simply states what it does without any usage instructions or exclusions, which is minimal but not entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
With only one tool, there is no possibility of confusion or overlap between tools. The 'echo' tool has a clear, singular purpose that is distinct by default.
A single tool inherently has perfect naming consistency, as there are no other tools to compare it against. The name 'echo' is straightforward and follows a simple verb pattern.
One tool is generally too few for a meaningful MCP server, as it offers minimal functionality and likely does not cover a useful domain comprehensively. This feels thin and under-scoped for most practical purposes.
The server is severely incomplete, as a single 'echo' tool does not define a clear domain or provide any meaningful coverage. There are obvious gaps, as no operations beyond echoing a message are available, making it trivial and non-functional for agents.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceA scalable, auto-discovering Model Context Protocol server that dynamically loads tools from the tools directory, enabling LLMs to access various capabilities through a standardized interface.
- AlicenseAqualityDmaintenanceA lightweight framework for building and running Model Context Protocol (MCP) servers using FastMCP, providing tools for development, debugging, and server management.4MIT
- FlicenseNot gradedqualityDmaintenanceA Model Context Protocol server built with FastMCP that features dynamic tool loading and modular management via a dedicated tool directory. It supports both stdio and HTTP transport modes, enabling efficient development and deployment of custom MCP tools.
- FlicenseBqualityDmaintenanceA Model Context Protocol server framework featuring dynamic tool loading and automatic tool discovery from a dedicated directory. It leverages FastMCP to provide a robust environment for building, configuring, and testing individual Python-based tools.1
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kcbabo/my-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server