eventor-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| EVENTOR_API_KEY | Yes | Eventor API key used for list_events and list_organisations. Obtain from Eventor -> Klubben -> Klubbinnstillinger (club admin only). | |
| EVENTOR_BASE_URL | No | Base URL for the Eventor API. Defaults to the Norwegian instance (eventor.orientering.no); set to the Swedish instance (eventor.orientering.se) as needed. | |
| EVENTOR_PASSWORD | Yes | Your personal Eventor login password, used together with EVENTOR_USERNAME. | |
| EVENTOR_USERNAME | Yes | Your personal Eventor login username, used for get_event_classes, get_event_entries, get_entry_changes, get_competitors, import_startlist, and import_resultlist. |
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 | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_eventsA | List events (competitions/activities) from Eventor within a date range. Args: from_date: Start date, format YYYY-MM-DD. to_date: End date, format YYYY-MM-DD. organisation_ids: Optional comma-separated Eventor organisation id(s) to filter by (a club or district). Omit for all events in range. Requires EVENTOR_API_KEY (a club API key from Eventor -> Klubben -> Klubbinnstillinger). |
| list_organisationsA | List all organisations (clubs, districts, federations) known to Eventor. Requires EVENTOR_API_KEY. |
| get_event_classesA | Get the competition classes defined for a specific event. Requires EVENTOR_USERNAME and EVENTOR_PASSWORD (a personal Eventor login) -- this endpoint does not accept the club API key. |
| get_event_entriesB | Get all entries for a specific event: competitor name, class, club and control card number. Requires EVENTOR_USERNAME and EVENTOR_PASSWORD. |
| get_entry_changesB | Get entry/modification timestamps for a specific event (who entered or changed their entry, and when), without full competitor details. Requires EVENTOR_USERNAME and EVENTOR_PASSWORD. |
| get_competitorsB | Get all registered competitors for one or more clubs. Args: organisation_ids: Comma-separated Eventor organisation id(s). Requires EVENTOR_USERNAME and EVENTOR_PASSWORD. |
| import_startlistA | Upload a start list to Eventor. THIS WRITES DATA: it changes what is published in Eventor. Only call this after the user has explicitly confirmed they want to publish this exact start list -- treat it like any other irreversible "publish" action, not a routine read. Args: iof_xml: A complete IOF XML 3.0 StartList document as a string. Requires EVENTOR_USERNAME and EVENTOR_PASSWORD. |
| import_resultlistA | Upload a result list to Eventor. THIS WRITES DATA: it publishes results. Only call this after the user has explicitly confirmed they want to publish these exact results. Args: iof_xml: A complete IOF XML 3.0 ResultList document as a string. Requires EVENTOR_USERNAME and EVENTOR_PASSWORD. |
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 8 tools
Most tools target distinct resources (events, organisations, classes, imports), and the descriptions clarify scope. However, get_event_entries, get_competitors, and get_entry_changes all concern 'who is participating' and differ mainly by scope (event vs club vs timestamps), which could cause occasional misselection.
All eight tools follow a clean snake_case verb_noun pattern using get_, list_, and import_ prefixes consistently. The convention is predictable and easy to reason about.
Eight tools is well-scoped for an orienteering event data server, with a sensible split between read operations and two publish/import writes. Each tool clearly earns its place.
The surface covers the core lifecycle: listing events/organisations, reading classes, entries, competitors, and publishing start/result lists. Minor gaps exist, such as no single-event detail fetch and no update/delete of entries, but agents can work around these.