romm-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ROMM_BASE_URL | Yes | The base URL of the RomM server. Must be an absolute http:// or https:// URL. | |
| ROMM_API_TOKEN_FILE | Yes | Path to a file containing the RomM Client API Token (rmm_...). Token values are never accepted as tool arguments. | |
| ROMM_TIMEOUT_SECONDS | Yes | Timeout in seconds for RomM API requests. Must be greater than 0 and at most 300. |
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 |
|---|---|
| healthA | Verify authenticated RomM API access and return non-sensitive connectivity identity only. |
| list_platformsA | List compact RomM platform summaries visible to the token. |
| get_platformA | Get a compact RomM platform summary by internal ID. |
| list_romsA | Search/list ROMs with bounded pagination and a compact provider-internal-free response. |
| get_romA | Get one bounded ROM view without provider internals, filesystem details, hashes or credential URLs. |
| update_rom_metadataB | Update bounded text metadata only; asset fetch/write and provider-ID mutation are excluded. |
| update_rom_user_propertiesA | Update personal ROM status/rating/completion properties for the token owner. |
| list_rom_notesA | List up to 100 bounded notes attached to a ROM. |
| create_rom_noteC | Create a RomM note with explicit supported fields. |
| update_rom_noteC | Update only the explicit fields supported by RomM notes. |
| delete_rom_noteA | Delete one RomM note after explicit confirmation. This does not delete ROM files. |
| list_collectionsA | List compact normal RomM collections. |
| get_collectionB | Get one compact normal RomM collection. |
| create_collectionA | Create a normal RomM collection without uploading artwork. |
| update_collectionB | Update collection metadata/membership without artwork changes. |
| delete_collectionA | Delete a collection after explicit confirmation; ROM files are never deleted. |
| add_roms_to_collectionA | Add ROM IDs to an existing collection. |
| remove_roms_from_collectionA | Remove ROM IDs from a collection without deleting ROMs. |
| list_smart_collectionsB | List compact RomM smart collections with only the explicit supported filter schema. |
| get_smart_collectionC | Get one bounded RomM smart collection. |
| create_smart_collectionB | Create a smart collection from explicit RomM filter criteria. |
| update_smart_collectionD | Update a smart collection. |
| delete_smart_collectionA | Delete a smart collection definition after explicit confirmation; this does not delete ROM files. |
| list_usersA | List minimal user identity needed for follow-up calls; email, roles, OAuth scopes and UI/device settings are excluded. |
| get_userA | Get minimal RomM user identity; authorization and UI/device details are excluded. |
| list_play_sessionsA | List bounded play-session summaries for the token owner without device/sync internals. |
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 26 tools
Each tool targets a distinct resource/action pair: normal collections and smart collections are clearly separated, ROM metadata updates are distinct from user-property updates, and list/get operations are consistently paired. No two tools appear to do the same thing, and the collection membership tools are clearly differentiated from collection deletion.
The vast majority of tools follow a consistent snake_case verb_noun pattern such as list_roms, create_rom_note, and update_smart_collection. The main deviation is 'health', which is a noun rather than a verb_noun name, and the add/remove membership tools use a slightly different prepositional pattern, though they are internally consistent with each other.
26 tools is just above the heavy range, but the count is defensible because the surface spans platforms, ROMs, notes, normal collections, smart collections, users, and play sessions. Still, the separate normal/smart collection CRUD groups and the split between ROM metadata and user properties make the tool set feel borderline over-scoped.
Normal collections, smart collections, and notes have full lifecycle coverage, while ROMs support listing, fetching, metadata updates, and user-property updates. The main gap is intentional: there is no ROM file create/delete/upload functionality, and play sessions are list-only, but these exclusions are consistent with the safety bounds described in the tool definitions.