Skip to main content
Glama
UberMorgott

nexusmods-mcp-server

by UberMorgott

Get Mod Changelogs (v1)

get_changelogs
Read-onlyIdempotent

Retrieve all version changelogs for a Nexus Mods mod, ordered newest last. Provide game domain and mod ID to get entries per version.

Instructions

All version changelogs of a mod (version → entries). Newest versions last.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
gameYesGame domain name as in site URLs, e.g. "skyrimspecialedition", "fallout4", "stardewvalley"
lastNoOnly the last N versions
mod_idYesMod ID (number in the mod page URL /mods/<id>)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the description properly adds the ordering trait 'newest versions last' and the response shape 'version → entries'. However, the word 'All' is somewhat misleading given the schema's `last` parameter, which defaults to 20 and says 'Only the last N versions'. No annotation contradiction exists, but this mismatch reduces clarity.

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?

The description is extremely compact, with no filler or redundant restating of schema fields. The core purpose and the most useful behavioral detail (ordering) are front-loaded in two short sentences.

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 simple read-only endpoint, this is largely complete: the schema documents all parameters, annotations cover the safety profile, and the description offers a minimal return-shape hint ('version → entries'). A small gap is that 'entries' is not further defined and the 'All' wording is not reconciled with the `last` default, but the schema compensates for that.

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

Parameters3/5

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

Schema description coverage is 100%, so the description does not need to re-explain `game`, `mod_id`, or `last`. The description adds no parameter-level detail beyond the schema, and it leaves unstated how 'All' interacts with the `last` limit.

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

Purpose4/5

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

The title 'Get Mod Changelogs' plus the description clearly identifies the resource: all version changelogs of a mod. The 'version → entries' structure and ordering make the purpose unambiguous. It does not explicitly name sibling alternatives, but the resource is distinct from related tools like get_mod_file_versions and add_changelog.

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

Usage Guidelines3/5

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

The description implies this is the tool to use when you need a mod's changelog history, and it is clearly a read operation. However, it gives no explicit when-to-use guidance, no exclusions, and does not point to alternatives such as get_mod_file_versions or add_changelog.

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