mcpField
P
publishorder

publishorder

Local
github.com/CloudCorpRecordsDeveloper Tools0Updated 1w ago

About publishorder

publishorder is a local CLI and MCP server that plans monorepo package release sequences from dependency graphs. It supports levels, changed-package plans, and explicit cycle reporting, with deterministic ordering.

Key features

  1. 01Compute deterministic publish order
  2. 02Group packages into dependency levels
  3. 03Plan for changed packages and dependents
  4. 04Report dependency cycles
  5. 05Validate graph inputs

Use cases

  1. 01Plan release order for a monorepo
  2. 02Publish only changed packages and dependents
  3. 03Find cycles blocking a release plan

MCP support

Exposes a `plan_publish_order` MCP tool. Clients provide package dependencies and an optional changed set; the result includes order, levels, cycles, and included or excluded packages.

Configuration

Local server config is the same for every client. Copy it into your client’s MCP config file.

mcp.json · Universal config
{
"mcpServers": {
"cloudcorprecords-publishorder": {
"command": "npx",
"args": [
"-y",
"@reneturcios/publishorder"
]
}
}
}
Run commandnpx -y @reneturcios/publishorder

Local servers need a runtime on your machine (e.g. Node.js 18+). Config file locations differ by client; see your client’s docs.

Packages
npm@reneturcios/publishorder0.1.0
ocighcr.io/cloudcorprecords/publishorder:0.1.0

Tools

1

Saved tool list · updated 1w ago

ParameterTypeRequiredDescription
changedarrayNoNames of changed packages; when given, the plan covers exactly these plus everything that transitively depends on them (optional)
packagesarrayYesPackages in the monorepo (at least one)

Details

From the project 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

Comments

Markdown supported

New to MCP?

From what the protocol is to installing your first server, these answers cover most first questions.

An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.