CopaLibre MCP
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
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
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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_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_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_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_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_backupA | Creates a compressed backup packet of the database (pg_dump via the |
| 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_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 |
| 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
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 15 tools
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.
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.
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.
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.