Skip to main content
Glama
sebastianzapatar

MCP Python Examples

MCP Python Examples

Este proyecto tiene tres paquetes de servidor/cliente MCP en Python:

  • basico/mini_mcp.py: ejemplo mínimo para entender la estructura

  • basico/main.py: ejemplo de clima usando Open-Meteo, sin seguridad

  • seguro/ y github_login/: la misma tool de clima, pero protegida con OAuth 2.1 (Scalekit) — client credentials (M2M) y login real de usuario con GitHub

También incluye index.html, una presentación explicando uv, pipx y MCP con weather-mcp como ejemplo real (arquitectura, seguridad, y cómo exponerlo en la nube). Ábrelo directo en el navegador.

Qué se versiona en este repo

Solo el código y los archivos de configuración de uv, sin artefactos generados:

Se versiona

No se versiona (ver .gitignore)

basico/, seguro/, github_login/ (código)

.venv/, __pycache__/

pyproject.toml, .python-version

*.egg-info, build/, dist/

index.html, README.md, .gitignore, .env.template

.uv-cache/, .claude/, .DS_Store, .env, usuarios_registrados.json

Related MCP server: nanomcp

Ejemplo mínimo

El archivo basico/mini_mcp.py es el más simple del proyecto.

Hace solo esto:

  • crea un servidor MCP

  • registra una sola tool

  • devuelve un saludo

La tool se llama saludar y recibe:

{
  "nombre": "Juan Camilo"
}

Respuesta esperada:

{
  "result": "Hola, Juan Camilo"
}

Cómo correrlo

Puedes correr el MCP mínimo de cualquiera de estas dos formas:

uv run python basico/mini_mcp.py

o:

uv run mini-mcp

No recibe argumentos por consola. Los parámetros se envían cuando un cliente MCP invoca la tool saludar.

Cómo probarlo localmente

Modo desarrollo con inspector MCP:

uv run mcp dev basico/mini_mcp.py

Prueba directa como función Python:

uv run python -c "from basico.mini_mcp import saludar; print(saludar('Juan Camilo'))"

Configurar en clientes MCP

La opción más estable en este proyecto es registrar este comando:

/Users/sebastianzapata/.local/bin/uv run --project /Users/sebastianzapata/mcp mini-mcp

Después de editar la configuración de cualquier cliente, reinicia la aplicación.

Codex

Archivo:

~/.codex/config.toml

Bloque:

[mcp_servers.mini-mcp]
command = "/Users/sebastianzapata/.local/bin/uv"
args = ["run", "--project", "/Users/sebastianzapata/mcp", "mini-mcp"]

También puedes agregarlo con CLI:

codex mcp add mini-mcp -- /Users/sebastianzapata/.local/bin/uv run --project /Users/sebastianzapata/mcp mini-mcp

Claude Desktop

Archivo:

~/Library/Application Support/Claude/claude_desktop_config.json

Dentro de mcpServers:

{
  "mini-mcp": {
    "command": "/Users/sebastianzapata/.local/bin/uv",
    "args": [
      "run",
      "--frozen",
      "--with",
      "mcp[cli]",
      "--with-editable",
      "/Users/sebastianzapata/mcp",
      "mcp",
      "run",
      "/Users/sebastianzapata/mcp/basico/mini_mcp.py"
    ]
  }
}

También puedes instalarlo con:

uv run mcp install /Users/sebastianzapata/mcp/basico/mini_mcp.py --name mini-mcp --with-editable /Users/sebastianzapata/mcp

Para ensayarlo en Claude, abre un chat nuevo y pide:

Usa la herramienta saludar del MCP mini-mcp con {"nombre":"Juan Camilo"}

Antigravity

Archivo:

~/Library/Application Support/Antigravity/User/settings.json

Dentro de mcpServers:

{
  "mini-mcp": {
    "command": "/Users/sebastianzapata/.local/bin/uv",
    "args": [
      "run",
      "--project",
      "/Users/sebastianzapata/mcp",
      "mini-mcp"
    ]
  }
}

Ejemplo de clima

El archivo basico/main.py es un ejemplo más completo.

Expone la tool get_weather, recibe:

{
  "latitude": 4.711,
  "longitude": -74.0721,
  "elevation": 2640
}

Consulta la API de Open-Meteo y devuelve el clima actual.

Ejecutarlo:

uv run python basico/main.py

o:

uv run weather-mcp

Modo desarrollo:

uv run mcp dev basico/main.py

Notas:

Registrado en Claude Code

claude mcp add weather-mcp -- /Users/sebastianzapata/.local/bin/uv run --project /Users/sebastianzapata/mcp weather-mcp

Registrado en Codex

En ~/.codex/config.toml:

[mcp_servers.weather-mcp]
command = "/Users/sebastianzapata/.local/bin/uv"
args = ["run", "--project", "/Users/sebastianzapata/mcp", "weather-mcp"]

Login de usuario con GitHub (Scalekit)

seguro/secure_mcp.py valida tokens, pero hasta ahora solo los generaban scripts (client credentials / M2M): ningún humano iniciaba sesión de verdad. github_login/app.py añade ese flujo: una persona se autentica con su cuenta de GitHub a través de Scalekit, queda registrada, y el token que recibe sirve exactamente igual para llamar al MCP seguro.

Requisitos previos en el Dashboard de Scalekit:

  • Tener habilitada una conexión social de GitHub.

  • Colocar en Allow Callback la URL http://localhost:8787/callback (o el valor que uses en SCALEKIT_REDIRECT_URI) para que la autenticación funcione y te redireccione donde lo debe hacer.

Ejecutarlo:

cp .env.template .env   # si no lo has hecho ya; agrega tus credenciales de Scalekit
uv run github-login

Luego:

  1. Abre http://localhost:8787 en el navegador.

  2. Haz clic en "Iniciar sesión con GitHub".

  3. Tras autorizar en GitHub, Scalekit te redirige de vuelta con un token de usuario y lo registra en github_login/usuarios_registrados.json (solo local, no se sube a git — ver .gitignore).

  4. Usa ese token como cualquier otro Bearer token contra secure-mcp:

claude mcp add --transport http secure-mcp \
  https://tu-dominio.com/sse \
  --header "Authorization: Bearer <token_del_usuario>"

Los dos flujos conviven: weather_client.py e inspector_cloud.py siguen usando client credentials (un Agente autenticándose a sí mismo), mientras que github_login/app.py autentica a una persona real. secure_mcp.py no distingue entre ambos: solo valida que el token sea un JWT vigente firmado por tu entorno de Scalekit.

Seguridad

basico/main.py ya sigue estas prácticas:

  • Sin API key: Open-Meteo es pública, no hay secretos que proteger o filtrar.

  • Validación de entrada: latitude/longitude se validan contra rangos físicos antes de armar la URL.

  • TLS verificado: usa un SSLContext con el bundle de certifi, no desactiva la verificación de certificados.

  • Timeout explícito: 15s, para que una API externa lenta no cuelgue el servidor.

  • Alcance mínimo: una sola tool de solo lectura, sin acceso a filesystem ni shell.

Reglas generales para servidores MCP propios o de terceros:

  • Secretos siempre en variables de entorno, nunca hardcodeados en el código.

  • Si agregas un .env con claves, súmalo a .gitignore (ya cubre .venv y caches).

  • Cada tool debe hacer una sola cosa bien definida; evita tools genéricas tipo "ejecutar comando" o "leer cualquier archivo".

  • Revisa el código de cualquier servidor MCP de terceros antes de instalarlo — corre con tus permisos locales.

  • Fija versiones de dependencias (considera generar un uv.lock).

Publicarlo para que otros lo descarguen

GitHub: el repo ya existe en github.com/sebastianzapatar/mcp2026 (rama main). Para subir el resto de archivos:

git add basico/ seguro/ github_login/ pyproject.toml .python-version index.html README.md .gitignore .env.template
git commit -m "Add weather MCP server and presentation"
git push

PyPI (instalable con pip install weather-mcp o uvx weather-mcp, requiere cuenta en pypi.org y un token de API):

uv build
uv publish

Directorios de MCP: con el repo público en GitHub, puedes enviarlo al registro comunitario de MCP o a directorios como Smithery/Glama.

Available Tools

1 tool
saludarC

Devuelve un saludo simple.

ParametersJSON Schema
NameRequiredDescriptionDefault
nombreYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses no behavioral details beyond the basic outcome (returning a greeting), lacking any information on side effects, permissions, or constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no extraneous words. It is appropriately front-loaded and brief.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the tool is simple and an output schema exists, the description is too brief for a tool with a required parameter. It omits any guidance on how the parameter should be provided or what constitutes a valid input, reducing completeness.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not elaborate on the 'nombre' parameter or its meaning. The input schema provides only a title ('Nombre'), leaving the agent to infer usage.

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 'Devuelve un saludo simple' clearly states the action (returns) and the resource (a simple greeting), matching the tool's name and purpose. With no sibling tools, differentiation is not needed.

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?

No guidance is provided on when or when not to use this tool, nor are there any alternatives mentioned. The description is purely functional without 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.

  1. 1 tool updatev0.1.0
    • First observedsaludar

TDQS

C2.7/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion with other tools. The purpose is clear and unambiguous.

Naming Consistency5/5

With a single tool, there is no naming inconsistency to evaluate. The name 'saludar' is a simple, descriptive verb in Spanish.

Tool Count1/5

A single tool that merely returns a greeting is far too minimal for a server purporting to provide Python examples. It lacks any substantial functionality.

Completeness1/5

The server offers only one trivial action (a greeting), leaving virtually every possible operation for a Python examples server unimplemented. It is severely incomplete.

Maintenance

ActivityStale
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

  • F
    license
    A
    quality
    D
    maintenance
    A minimal MCP server demo written without the MCP Python SDK that demonstrates the complete protocol flow. It provides weather, file search, and datetime tools, and includes a CLI client that bridges MCP tools with OpenAI function calling.
    3
    -
  • F
    license
    Not graded
    quality
    C
    maintenance
    A proof-of-concept MCP server that provides weather information using the Open-Meteo API, with tools for greeting, getting weather by coordinates, and by location name.
    -