vsmoddb-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VSMODDB_BASE_URL | No | Override for testing against a mock ModDB server. | https://mods.vintagestory.at |
| VSMODDB_SESSION_FILE | No | Session file location. This file holds the vs_websessionkey cookie (written by the login helper, or created manually as {"cookie": "vs_websessionkey=<value>"}). Treat it like a password. | ~/.config/vsmoddb-mcp/session.json |
| VSMODDB_MAX_UPLOAD_MB | No | Upload size guard (ModDB's default limit). | 40 |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| moddb_statusA | Validate the configured Vintage Story ModDB session, refresh the action token, and report the logged-in account. Run this first when other tools complain about an invalid session. |
| list_my_modsA | List the mods the logged-in account contributes to (the 'Your mod contributions' section of mods.vintagestory.at/home). Use the returned names/paths with get_mod, upload_release, update_mod, etc. |
| get_modA | Fetch a mod's public ModDB metadata: ids, tags, links, stats and the release list (with release ids and compatible game versions). Accepts mod name, numeric id, or URL alias. |
| update_modA | Update a mod's ModDB page: description, summary, name, URL alias, links, side, and tags. Only the provided fields are changed; everything else (including team members, images, status) is preserved. 'description' REPLACES the whole description, so provide the full new text in Markdown. 'tags' replaces the full tag list; use add_tags/remove_tags for incremental changes. |
| list_tagsA | List the site-wide tag vocabulary every mod can carry (id, name, color). Check this before add_mod_tags: only these names exist on ModDB, and anything else has to be created deliberately. |
| add_mod_tagsA | Add tags to a mod. Existing tags are applied through the mod edit form (the path the site's own UI uses), and only names from list_tags are accepted unless create_missing: true is passed. Tags are site-wide: brand-new ones can only be created through ModDB's user-tags API, which the site currently disables (HTTP 503). |
| upload_releaseA | Upload and publish a new release (zip in, one release out). For game mods the identifier/version are auto-detected from the zip's modinfo.json, and game_versions must be provided. The uploaded file cannot be replaced afterwards, so verify the build first. Requires confirm: true. |
| update_releaseA | Update an existing release's changelog, compatible game versions, or (non-game mods only) version. The uploaded file itself can never be replaced. Provide at least one of changelog / game_versions / version. |
| retract_releaseA | Retract (mark as broken/withdrawn) a release with a reason. The release stays visible with a retraction notice and can no longer be edited. Requires confirm: true. |
| list_commentsA | List comments on a mod's ModDB page, newest first. Accepts a mod name, numeric id, or URL alias. Returns comment ids for reply_to_comment, edit_comment and delete_comment. |
| reply_to_commentA | Post a reply to a comment on a mod's ModDB page. The text is Markdown (converted to HTML). Use only user-approved wording; the ModDB rules prohibit bot-like/spammy commenting. |
| edit_commentA | Edit one of your own comments (or any comment if you are a moderator). The text is Markdown and replaces the current content entirely. |
| delete_commentA | Delete one of your own comments (irreversible; requires confirm: true). |
| list_notificationsA | List the logged-in account's ModDB notifications (new comments, mentions, releases of followed mods, ...). Comment notifications are the quickest way to find comments awaiting a reply on your mods. |
| mark_notifications_readA | Mark specific notifications (ids) or all notifications (all: true) as read. |
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 resource or action: session status, mod listing/retrieval/update, tags, releases, comments, and notifications. Potential overlaps like update_mod replacing tags versus add_mod_tags for incremental changes are explicitly clarified in the descriptions. An agent can reliably select the correct tool.
All tools use snake_case, and the vast majority follow a verb_noun or verb_noun_modifier pattern (list_my_mods, update_release, mark_notifications_read). Minor deviations like moddb_status (noun-first) and reply_to_comment (prepositional) are still readable and predictable.
15 tools sits at the upper end of the ideal 3-15 range, and every tool earns its place across authentication, mod management, tags, releases, comments, and notifications. There are no redundant or trivial tools.
Core lifecycle coverage is strong: mods (list/get/update), releases (upload/update/retract), comments (list/reply/edit/delete), notifications (list/mark read), and tags (list/add). Missing create_mod and a dedicated remove_mod_tags tool, and top-level comment creation is not clearly supported, but agents can work around most of these gaps.