Skip to main content
Glama
SebaSOFT

CopaLibre MCP

Official

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
copalibre_doctorA

Checks whether this CopaLibre installation is correctly configured: required secrets, database reachability, JWKS content, object storage, and persistent-path writability. Use it before starting an installation, or to diagnose why one is failing. Runs the same checks as copalibre doctor; needs no API token — it inspects local configuration and connects directly to the database, not through apps/api.

copalibre_module_listA

Lists every installed discipline and tournament-profile module (alias, version, kind, source, attribution). Use it to see what a given installation can run before creating a tournament, or to check whether a module you expect is actually installed. Needs no API token — reads directly from the database, not through apps/api.

copalibre_upgrade_checkA

Checks, before upgrading, whether every installed module would still satisfy its declared CopaLibre-version compatibility range under a target version, and lists database migrations that would run. Use it as a pre-flight gate before switching an installation to a new CopaLibre version — it reports incompatibilities without applying any migration or altering any installed data. Needs no API token.

copalibre_module_addA

Installs a discipline or tournament-profile module — at its latest version, or one satisfying an optional semver range — from the curated module repository or another allow-listed source. Use it to add a module an installation needs before creating a tournament with it. Runs the same direct-database install copalibre module add uses; needs no API token — it installs directly into the local database and object storage, not through apps/api.

copalibre_module_removeA

Removes every installed version of a discipline or tournament-profile module by alias, refusing (and removing nothing) if any started tournament still references it. Use it to uninstall a module no longer needed. Runs the same direct-database removal copalibre module remove uses; needs no API token.

copalibre_module_verifyA

Re-validates every installed module's stored document and assets against the running CopaLibre core version, reporting PASS/FAIL per module with failure details. Use it to check installation integrity, especially after an upgrade. Runs the same direct-database checks copalibre module verify uses; needs no API token.

copalibre_statistics_rebuildA

Recomputes every folded statistic total from source match facts, for an organization or one tournament within it — idempotent, safe to re-run. Use it after a data backfill, a statistics-engine fix, or to repair drift. Runs the same direct-database recompute copalibre statistics-rebuild uses; needs no API token.

copalibre_backupA

Creates a compressed backup packet of the database (pg_dump via the database-tools Compose service) under backups/, pruning older packets beyond the retention count. Use it before a risky operation or as part of a backup routine. Runs the same steps copalibre backup uses, including its Kubernetes-mode refusal; needs no API token.

copalibre_module_scaffoldA

Generates a structurally-valid discipline or tournament-profile module package — seeded from one of CopaLibre's own already-valid catalogue documents, not a blind guess at the schema — as a tagged local Git repository ready to edit, validate, and submit. Use this first when authoring a new module: it gives real, valid example content (segments, events, statistics for a discipline; stages, points, tiebreak for a profile) to change into the real sport or format, not a blank document. Needs no API token.

copalibre_module_validate_localA

Validates a local module package directory (manifest.json + artifact.json) without fetching or installing anything — the exact same check copalibre module add/module verify apply. Use it after editing a scaffolded module, before trying to install it locally or submit it. Needs no API token.

copalibre_module_submitA

Forks copalibre-modules, copies a local module package onto a new branch, pushes it, and opens a pull request. Use it once a scaffolded module has been edited and passes copalibre_module_validate_local — this is the last step, handing the module to a human reviewer; it never merges anything itself. Needs no API token, but does need gh authenticated with permission to fork the target repository.

copalibre_descriptor_schemaA

Returns the discipline descriptor's machine-readable JSON Schema — byte-identical to what copalibre_descriptor_validate and installation both check against — together with a field-by-field explanation of what each declaration governs during a competition, not just its shape. Use this first when authoring a new discipline module, before writing any JSON. Needs no API token.

copalibre_descriptor_validateA

Validates a candidate discipline descriptor document by calling the same validator the installation path applies — shape and cross-field checks alike (a best-of series span must be odd; a resolution class and a resolution script are mutually exclusive; and more). A descriptor this tool accepts is exactly one installation will accept; it never authors a descriptor, only judges one already drafted. Use it after copalibre_descriptor_schema, iteratively, before copalibre_module_scaffold/_validate_local. Needs no API token.

copalibre_profile_schemaA

Returns the tournament profile's machine-readable JSON Schema — byte-identical to what copalibre_profile_validate and installation both check against — together with a field-by-field explanation of what each declaration governs during a competition, not just its shape. Use this first when authoring a new tournament-profile module, before writing any JSON. Needs no API token.

copalibre_profile_validateA

Validates a candidate tournament-profile document by calling the same validator the installation path applies. A profile this tool accepts is exactly one installation will accept; it never authors a profile, only judges one already drafted. Use it after copalibre_profile_schema, iteratively, before copalibre_module_scaffold/_validate_local. Needs no API token.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.2/5.0

Scored across 15 tools

Disambiguation5/5

Each tool targets a clearly distinct operation: diagnostics, listing, adding/removing/verifying modules, validating descriptors/profiles, schema retrieval, scaffolding, submitting, backup, and statistics rebuild. Overlaps like descriptor_validate vs module_validate_local or upgrade_check vs module_verify are well-separated by descriptions and names.

Naming Consistency4/5

All tools share the copalibre_ prefix and snake_case, with a mostly predictable domain_action pattern (module_list, module_add, descriptor_validate, etc.). Minor deviations like the single-word copalibre_doctor and copalibre_backup, and noun_noun schema tools, slightly reduce consistency but remain readable.

Tool Count5/5

With 15 tools, the set is well-scoped for a CLI-like administration surface covering module lifecycle, validation, diagnostics, backup, and statistics. Each tool earns its place and the count sits comfortably within the ideal 3–15 range.

Completeness4/5

The surface covers core administrative and module-authoring workflows: scaffolding, local validation, installation, removal, verification, submission, schema/validation for descriptors and profiles, upgrade pre-flight, backup, and statistics rebuild. Minor gaps exist (e.g., no explicit restore or backup-listing tool, no direct module update beyond add with version range), but agents can work around them.

Maintenance

ActivityActive
ResponsivenessWithin a week