Back to Browse

Publishorder MCP Server

Developer ToolsModerate6.9MCP RegistryLocal
Free

Server data from the Official MCP Registry

Monorepo publish order from the dependency graph: levels, changed-set plans, and cycle detection.

About

Monorepo publish order from the dependency graph: levels, changed-set plans, and cycle detection.

Security Report

6.9
Moderate6.9Moderate Risk

publishorder is a pure local topological-sort tool with no network calls, no shell execution, no credentials, and no dynamic code evaluation. Its only notable capability is the CLI reading a user-specified input JSON file, which matches its stated purpose, and the MCP tool needs no authentication because it performs no upstream access. No security issues were found; the remaining notes are informational. Supply chain analysis found 3 known vulnerabilities in dependencies (0 critical, 2 high severity). Package verification found 1 issue.

8 files analyzed · 7 issues found

Security scores are indicators to help you make informed decisions, not guarantees. Always review permissions before connecting any MCP server.

Permissions Required

This plugin requests these system permissions. Most are normal for its category.

File System Read

Reads files on your machine. Normal for tools that analyze or process local data.

How to Install

Add this to your MCP configuration file:

{
  "mcpServers": {
    "io-github-cloudcorprecords-publishorder": {
      "args": [
        "-y",
        "@reneturcios/publishorder"
      ],
      "command": "npx"
    }
  }
}

Documentation

View on GitHub

From the project's GitHub README.

publishorder

You are about to publish a monorepo release and the packages have to go out in the right sequence: nothing can ship before the packages it depends on. publishorder takes the package graph — every package's name and the names of the packages that must publish before it — and works out the plan:

  • Publish order — a topological order of the included packages, computed with Kahn's algorithm. Whenever more than one package is ready to go, the alphabetically smallest is picked first, so the same graph always yields exactly the same order.
  • Levels — the packages grouped by depth. Level 0 holds the packages with no included dependencies; every other package sits at one level above its deepest included dependency. Everything in a level can publish together, once the levels below it are out.
  • Changed-set plans — pass the names of the packages that changed and the plan covers exactly those packages plus everything that depends on them, directly or transitively. The remaining packages are reported as excluded, and dependencies pointing at them do not constrain the order — they are already published.
  • Cycle detection — when the included packages cannot be ordered, publishorder does not error out or guess. It reports ok: false with the exact cycle: a depth-first search over names and dependencies in ascending order returns the first cycle it finds as the list of packages forming it (a package that depends on itself reports as a one-name cycle). A cycle that lives entirely among excluded packages does not block a changed-set plan.

The graph must be closed: a dependency or a changed entry naming a package that was not supplied is a validation error, as are a missing or duplicate package name and any wrongly typed field. Errors name the offending path (for example packages[1].dependencies[0] references unknown package "core") and no partial plan is produced. The computation is pure and local: no network, no configuration, no files read beyond the input you pass in.

CLI

npx @reneturcios/publishorder plan --input args.json
npx @reneturcios/publishorder --version

args.json contains the full arguments object:

{
  "packages": [
    { "name": "core", "version": "1.4.1" },
    { "name": "lib", "dependencies": ["core"] },
    { "name": "app", "dependencies": ["lib"] }
  ],
  "changed": ["core"]
}

dependencies defaults to [] per package, version is optional and carried without affecting the order, and changed is optional overall. The plan is printed as JSON:

{
  "ok": true,
  "order": ["core", "lib", "app"],
  "levels": [["core"], ["lib"], ["app"]],
  "cycle": [],
  "included": ["app", "core", "lib"],
  "excluded": []
}

Exit codes: 0 on success, 1 on a runtime error (including an unreadable or invalid input file, or invalid input), 2 on a usage error.

MCP server

npx -y @reneturcios/publishorder mcp

MCP client config:

{
  "mcpServers": {
    "publishorder": {
      "command": "npx",
      "args": ["-y", "@reneturcios/publishorder", "mcp"]
    }
  }
}

Tools

  • plan_publish_order — Plan a monorepo publish order from the dependency graph.

    • packages (array, required, at least one) — packages as {name, dependencies?, version?} objects; name is unique across the set and each dependencies entry names another supplied package
    • changed (array of strings, optional) — when given, the plan covers these packages plus everything that transitively depends on them

    Returns {ok, order, levels, cycle, included, excluded}.

Docker

docker run -i ghcr.io/cloudcorprecords/publishorder
docker run --rm -v "$PWD:/w" ghcr.io/cloudcorprecords/publishorder plan --input /w/args.json

Development

npm install
npm run build   # tsc -> dist/
npm test        # tsx --test test/*.test.ts (pure local, no network)
npm run dev     # run the CLI from source

License

MIT — Copyright (c) 2026 Rene Turcios

Reviews

No reviews yet

Be the first to review this server!