Skip to main content
Glama
kcbabo

my-mcp-server

by kcbabo

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.yaml

  • Fail-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 tests

Quick Start

Option 1: Local Development (with Python/uv)

  1. Install Dependencies:

    uv sync
  2. Run 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 8080
  3. Using uv Scripts:

    # Development mode (HTTP on port 3000)
    uv run dev
    
    # HTTP mode
    uv run dev-http
    
    # Stdio mode
    uv run start
  4. Add 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)

  1. Build Docker Image:

    arctl mcp build --verbose
  2. Run in Container:

    docker run -i my-mcp-server:latest
  3. Add 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 8080

Creating 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: 10

Testing

Run the generated tests to verify your tools load correctly:

uv run pytest tests/

Development

Adding Dependencies

Update pyproject.toml and run:

uv sync

Code 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:latest

Available Tools

1 tool
echoB

Echo a message back to the client.

Args: message: The message to echo

Returns: The echoed message with any configured prefix

ParametersJSON Schema
NameRequiredDescriptionDefault
messageYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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

B3.2/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count2/5

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.

Completeness1/5

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

ActivityInactive
ResponsivenessSyncing

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

Related MCP Servers

  • F
    license
    Not graded
    quality
    D
    maintenance
    A 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.
  • A
    license
    A
    quality
    D
    maintenance
    A lightweight framework for building and running Model Context Protocol (MCP) servers using FastMCP, providing tools for development, debugging, and server management.
    4
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    A 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.
  • F
    license
    B
    quality
    D
    maintenance
    A 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

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