Skip to main content
Glama

Update ModDB mod description/metadata

update_mod

Update a mod's Vintage Story ModDB page by changing selected fields like summary, description, links, side, or tags. Only supplied values are changed; all other metadata is preserved.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modYesMod identifier: alias/name, numeric id, or ModDB URL/path (e.g. 'carrycapacity', '5894', '/show/mod/54807')
nameNoNew mod name
sideNoMod side: 'client', 'server' or 'both'
tagsNoFull replacement list of tag names
summaryNoNew short summary (max 100 chars)
add_tagsNoTag names to add (applied before remove_tags)
wiki_urlNoWiki URL
url_aliasNoNew URL alias (letters only)
donate_urlNoDonation URL
descriptionNoFull new description in Markdown (replaces the current description)
remove_tagsNoTag names to remove
homepage_urlNoHomepage/forum post URL
source_code_urlNoSource code URL
description_htmlNoFull new description as raw HTML (takes precedence over 'description')
issue_tracker_urlNoIssue tracker URL
trailer_video_urlNoTrailer video URL

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=false, so the description carries most of the burden and it delivers: 'description' fully replaces existing text and 'tags' replaces the whole list, plus a guarantee that unlisted fields (team members, images, status) are preserved. Missing auth/permission or reversibility notes keeps it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, no filler, front-loaded with the scope then the mutation semantics then the replacement caveats. Each sentence earns its place by preventing a distinct class of mistake.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-parameter mutation tool with no output schema and only a minimal readOnly annotation, the description covers the destructive replace behavior that matters most. It omits error/validation behavior (e.g. url_alias letters-only) and permission requirements, leaving a small gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds genuinely non-obvious meaning by clarifying replace-vs-append semantics for 'description' and 'tags' and the Markdown format. It does not resolve the description_html precedence or the add/remove ordering beyond what the schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Update') and resource ('a mod's ModDB page') and enumerates the mutable fields (description, summary, name, URL alias, links, side, tags). The scope clearly separates it from release-oriented siblings like update_release and add_mod_tags.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the key selection condition: use field parameters for full replacement versus add_tags/remove_tags for incremental tag changes. It does not explicitly contrast against sibling tools like add_mod_tags or get_mod, so the routing guidance is strong but not complete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.