Skip to main content
Glama
Charlesthebird

mymcpservercli

by Charlesthebird
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

mymcpservercli

mymcpservercli 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: my-mcp-server

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 mymcpservercli: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 mymcpservercli: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.3/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 potential modifications. However, it lacks details on side effects, error handling, rate limits, or authentication needs, which are important for a tool with no annotation coverage.

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 appropriately sized and front-loaded, with the core purpose stated first, followed by brief sections for arguments and returns. Every sentence earns its place, and there is no wasted verbiage, making it efficient and easy to parse.

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 simplicity (one parameter, no siblings, no annotations) 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 likely covers return values, reducing the need for detailed return explanations in the description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, but the description compensates by explaining the single parameter: 'message: The message to echo.' This adds clear meaning beyond the bare schema. Since there's only one parameter and it's well-described, the score is high, though not perfect due to the lack of details on format or constraints.

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.' It specifies the verb ('echo') and 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, which prevents a perfect 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 or in what context it should be applied. It simply states what the tool does without any usage instructions, prerequisites, or exclusions, leaving the agent with minimal operational context.

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. Dates show when Glama detected each change.

  1. 1 tool updatev0.1.0
    • First observedecho
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap with other tools, making disambiguation perfect.

Naming Consistency5/5

A single tool inherently has consistent naming, as there are no other tools to compare against for patterns or conventions.

Tool Count2/5

One tool is too few for most server purposes, as it severely limits functionality and scope, making the server feel trivial or incomplete.

Completeness1/5

The server lacks a clear domain, and with only an echo tool, there are significant gaps in coverage, making it severely incomplete for any meaningful workflow.

Maintenance

ActivityInactive
ResponsivenessNo issues

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

  • BuildMcpServer

    riteshbangal
    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

  • my-mcp-server

    kcbabo
    F
    license
    B
    quality
    D
    maintenance
    A Model Context Protocol server built with FastMCP that enables dynamic tool loading and configuration from individual Python files. It provides a flexible framework for automatically discovering, testing, and running tools via Stdio or HTTP transport modes.
    1
    -

  • my-mcp-server2

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

  • MCP Server Template

    Frankietime
    F
    license
    Not graded
    quality
    D
    maintenance
    A production-ready Python scaffold for building Model Context Protocol (MCP) servers using FastMCP. It provides a structured framework for developers and AI agents to rapidly develop, test, and manage custom tools and workflows.
    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/Charlesthebird/mymcpservercli'

If you have feedback or need assistance with the MCP directory API, please join our Discord server