Skip to main content
Glama
Dalejan

Volleyball MCP Server

by Dalejan

MCP VoleyBall

Servidor MCP (Model Context Protocol) que proporciona acceso a datos de voleibol mediante consultas SQL. El proyecto incluye un proceso ETL para obtener datos de la API de VolleyballWorld y almacenarlos en una base de datos SQLite.

Descripción

Este proyecto permite consultar datos de partidos, equipos y torneos de voleibol a través de un servidor MCP. Los datos se obtienen desde la API de VolleyballWorld mediante un scraper, se convierten a formato SQLite y se exponen mediante un servidor MCP que permite ejecutar queries SQL.

Related MCP server: Karenina MCP

Requisitos

  • Python 3.11 o superior

  • uv (gestor de paquetes) - Instalar uv

Instalación

  1. Clonar el repositorio:

git clone <url-del-repositorio>
cd MCP-VoleyBall
  1. Instalar dependencias:

uv sync

Uso

1. Proceso ETL (Extracción y carga de datos)

Primero necesitas obtener los datos de la API y convertirlos a base de datos SQLite:

  1. Extraer datos de un torneo:

cd ETL
python scrapper.py

Por defecto, el scraper obtiene datos del torneo 1520 del año 2025. Puedes modificar los parámetros en scrapper.py según necesites.

  1. Convertir JSON a SQLite:

python database_converter.py

Esto creará/actualizará el archivo volleyball_data.db en el directorio ETL/ con todos los datos estructurados.

2. Servidor MCP

Una vez que tengas la base de datos creada, puedes ejecutar el servidor MCP:

python main.py

Para desarrollo y pruebas del servidor MCP:

mcp dev main.py

O usando npx:

npx @modelcontextprotocol/inspector uv run main.py

El servidor MCP expone una herramienta execute_query que permite ejecutar queries SELECT en la base de datos de voleibol.

3. Visualización con Datasette

Para visualizar y explorar los datos de manera interactiva usando Datasette, ejecuta:

cd ETL
datasette serve volleyball_data.db

Esto iniciará un servidor web local (por defecto en http://127.0.0.1:8001) donde podrás explorar las tablas, ejecutar queries SQL y visualizar los datos de manera interactiva.

Configuración del MCP Server en Claude Desktop

Para usar este servidor MCP con Claude Desktop, agrega la siguiente configuración en tu archivo de configuración MCP (normalmente ~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "voleyball-server": {
      "command": "/ruta/.venv/bin/python",
      "args": [
        "/ruta/main.py"
      ],
      "cwd": "/ruta/MCP-VoleyBall" 
    }
  }
}

Asegúrate de usar la ruta absoluta al archivo main.py.

Estructura del Proyecto

MCP-VoleyBall/
├── main.py                 # Servidor MCP
├── db_connection.py        # Conexión a la base de datos
├── ETL/
│   ├── scrapper.py         # Extracción de datos de la API
│   ├── database_converter.py  # Conversión JSON a SQLite
│   └── volleyball_data.db  # Base de datos (se genera con el ETL)
└── pyproject.toml          # Dependencias del proyecto

Ejemplo de Queries

Una vez configurado el servidor MCP, puedes hacer consultas como:

'Que equipo gano mas partidos en el ano 2025'

Available Tools

1 tool
execute_queryB
Ejecuta una query SQL en la base de datos de voleibol.

Args:
    query: La query SQL a ejecutar.

Returns:
    Una lista de tuplas con los resultados de la query.
ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool executes SQL queries and returns results as a list of tuples, which covers basic behavior. However, it fails to disclose critical traits like whether it's read-only or destructive, authentication requirements, error handling, or rate limits. This is a significant gap for a database query tool.

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 concise and well-structured, using clear sections for Args and Returns. Each sentence serves a purpose: stating the tool's function, describing the parameter, and explaining the return value. There is no unnecessary information, making it efficient for an agent to parse.

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

Completeness3/5

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

Given the tool's complexity (executing SQL queries) and lack of annotations or output schema, the description is minimally adequate. It covers the basic purpose, parameter, and return format, but misses important contextual details like safety warnings, error conditions, or database-specific constraints. Without an output schema, more detail on return values would be beneficial.

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 description adds meaningful context for the single parameter 'query' by specifying it as 'La query SQL a ejecutar' (The SQL query to execute), which clarifies its purpose beyond the schema's basic type information. Since schema description coverage is 0%, the description compensates adequately, though it could provide more details on query format or restrictions. With only one parameter, the baseline is high.

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: 'Ejecuta una query SQL en la base de datos de voleibol' (Executes an SQL query in the volleyball database). It specifies the verb (execute) and resource (SQL query on volleyball database), making the function unambiguous. However, without sibling tools, there's no opportunity to distinguish from alternatives, preventing a perfect score.

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. It lacks information about prerequisites, such as required permissions or database connection details, and does not mention any constraints or best practices for SQL queries. This leaves the agent without context for appropriate usage.

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 updatev1.0.0
    • First observedexecute_query

TDQS

B3.2/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The tool's purpose is clearly defined and 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 'execute_query' follows a clear verb_noun pattern.

Tool Count2/5

One tool is too few for a server named 'Volleyball MCP Server', which suggests a domain that would typically require multiple operations (e.g., querying players, matches, statistics). A single SQL execution tool feels thin and under-scoped for this apparent purpose.

Completeness1/5

The tool surface is severely incomplete for a volleyball domain. It only provides raw SQL execution, lacking any domain-specific operations like retrieving player stats, match results, or team information, which would be expected for such a server.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    D
    maintenance
    Enables natural language querying of Karenina benchmark verification results stored in SQLite databases, allowing AI assistants to explore and analyze model performance data without writing SQL manually.
    -
  • F
    license
    Not graded
    quality
    D
    maintenance
    Enables natural-language querying of historical NBA game data from a read-only SQLite database.
    -
  • F
    license
    Not graded
    quality
    D
    maintenance
    Enables querying K League official data (rankings, matches, players) via SQL using natural language, with a pre-built SQLite database.
    -