Skip to main content
Glama
PHLemp

nexus-mods-mcp

by PHLemp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Upload and publish a mod file

nexus_upload_mod_file

Uploads a local mod archive to Nexus Mods and publishes it in one call, handling session creation, byte transfer, finalization, and version appending or new file creation.

Instructions

Uploads a local archive to Nexus and publishes it, in ONE call (v3 Upload API): creates the upload session, sends the bytes to the presigned storage URL, finalises, waits for processing, then either appends a new version to an existing file (pass mod_file_id, from nexus_mod_file_targets) or creates a new file on the mod page. Multipart is used automatically above 100 MiB. Optionally posts a changelog entry. Requires NEXUS_ALLOW_WRITES=true and NEXUS_ALLOW_UPLOADS=true. Always run with dry_run=true first to confirm the plan before the real upload.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesFile name shown on the mod page (max 50 chars, letters/digits/space/_'().-)
mod_idYesNumeric mod id (visible in the page URL)
dry_runNoValidate everything and report the plan without contacting Nexus
versionYesFile version (max 50 chars, letters/digits/dot/dash)
changelogNoChangelog text to append for this version (posted after publishing)
file_pathYesAbsolute path of the archive to upload (must already exist)
descriptionNoShort description shown under the file
mod_file_idNoExisting file to add this version to (omit to create a new file)
file_categoryYesmain | optional | miscellaneous
upload_filenameNoArchive name sent to storage (defaults to the file name on disk)
game_domain_nameNoGame domain, e.g. "skyrimspecialedition". Default: "mountandblade2bannerlord"
update_mod_versionNoBump the mod page version to match this file (default false)
previous_version_idNoversion_id this release replaces (new versions only)
archive_existing_fileNoArchive the version being replaced (new versions only, default false)
show_requirements_pop_upNoShow the requirements pop-up
allow_mod_manager_downloadNoAllow mod manager downloads
primary_mod_manager_downloadNoMake it the default mod-manager download

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only declare write/non-idempotent/openWorld. The description adds the concrete internal sequence (session, byte transfer, finalise, wait for processing), the automatic multipart switch above 100 MiB, and two environment prerequisites (NEXUS_ALLOW_WRITES, NEXUS_ALLOW_UPLOADS). These are real operational constraints an agent cannot get from the annotations.

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

Conciseness4/5

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

A single dense paragraph, but it is front-loaded with the purpose and workflow before conditions. Every sentence carries information; the run-on length is the only minor cost.

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 17-parameter mutation with no output schema, the description covers prerequisites, branch selection, dry-run guidance, and processing behavior. It does not describe what success/failure looks like or how the wait-for-processing step surfaces errors, a modest gap.

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 schema already documents every parameter including the mod_file_id branch and defaults. The description adds a little framing (changelog posted after publishing, upload_filename default) but mostly restates schema content, so baseline 3 is appropriate.

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 and resource ('Uploads a local archive to Nexus and publishes it') and immediately scopes it as a single-call v3 flow. It distinguishes the two modes (append via mod_file_id or create a new file) and clearly differentiates from siblings like nexus_publish_upload and nexus_upload_status.

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?

Gives explicit conditional routing: pass mod_file_id to append a version, omit it to create a new file, and it points to nexus_mod_file_targets for obtaining that id. It also mandates running dry_run=true first. It stops short of naming the multipart/two-step sibling alternative outright, so an agent must infer the fallback from 'in ONE call'.

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

Deploy Server

Other Tools