Skip to main content

MCP server for orchestration, lane management, worker daemons, and turn metrics.

Project description

WorkBay Orchestrator MCP

Component of the workbay stack. You usually install workbay, not this package directly.

MCP server for orchestration, lane management, worker daemons, review dispatch, and ACE metrics.

Installation

From PyPI (recommended)

pip install mcp-workbay-orchestrator
# or, as an isolated tool:
uv tool install mcp-workbay-orchestrator
# or, ad-hoc without installing:
uvx mcp-workbay-orchestrator --help

mcp-workbay-orchestrator declares mcp-workbay-handoff>=0.5.0,<0.6.0 as a required dependency; pip resolves it from PyPI automatically. workbay-codex-bridge remains optional unless you want the local bridge backend.

From the monorepo source tree (development)

From this package root inside workbay:

cd packages/mcp-workbay-orchestrator
python -m pip install -e ".[dev]"

When developing both MCP servers in lockstep, install the sibling handoff package as an editable first so the orchestrator picks it up:

pip install -e ../mcp-workbay-handoff
pip install -e ".[dev]"

Development

Run package-local commands from the package root:

make lint-orchestrator
make fix-lint-orchestrator
make format-orchestrator
make mypy-orchestrator
make test-orchestrator
make check-orchestrator

The package Makefile keeps workbay-codex-bridge as an optional sibling source path for local bridge-backend development, but it expects mcp-workbay-handoff to be installed as a normal package dependency.

Direct commands also work:

PYTHONPATH=src python -m ruff check src tests
PYTHONPATH=src python -m mypy src
PYTHONPATH=src python -m pytest tests -q

Token-Efficient Usage

For bounded reads and compact caller patterns, follow the shared guide in packages/mcp-workbay-handoff/docs/guides/token-efficient-usage.md. The orchestrator package reuses that guidance instead of maintaining a separate copy of the same parameter semantics.

Runtime Notes

This package orchestrates work against a target workspace. The workspace you point it at still needs the expected task state and orchestration inputs, such as:

  • .task-state/
  • lane manifests
  • task plans or other orchestration docs the lane logic references

Those assets belong to the workspace being orchestrated, not to the package checkout itself.

Backends

The orchestration layer supports multiple execution backends, including:

  • codex-cli
  • codex-subagent
  • claude-code
  • local-model-openai

Some backends are optional and require host-specific tooling to be installed separately.

Availability vs. the optional bridge

The static backend table always lists every declared backend. That a backend is listed does not mean it will run in the current process. The codex-subagent backend needs the optional workbay-codex-bridge host module, which is not a base dependency and is not installed by the bootstrap presync (the launcher runs uv run --no-sync). If the orchestrator server launches from a venv that lacks the bridge, resolve_bridge("codex-subagent") raises ImportError at dispatch even though the backend is listed.

To surface this without a live turn, call the MCP tool list_available_backends with its default settings, or call the CLI with probing on:

mcp-workbay-orchestrator list-backends --probe

Each probed backend carries an availability_state:

  • available — in-process adapter, or a CLI binary found on PATH.
  • reachable — a bridge module imports and exposes a runner; liveness is not verified (a real turn may still time out at dispatch).
  • declared_not_installed — the backend is declared but its optional host module (e.g. workbay-codex-bridge) is not importable in this runtime.
  • unavailable — a CLI backend whose binary is not on PATH, or a bridge module that imports but does not expose the required runner.
  • unknown — no probe is implemented for that backend kind.

Install the bridge on demand to move codex-subagent from declared_not_installed to reachable:

uv sync --extra bridge   # resolves workbay-codex-bridge from the sibling source

Source Checkout Usage

For local source execution without installation:

PYTHONPATH=src python -m workbay_orchestrator_mcp --help

If you are testing against a sibling workbay-codex-bridge checkout instead of an installed bridge dependency, extend PYTHONPATH with that sibling src directory as needed.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

mcp_workbay_orchestrator-0.2.0.tar.gz (197.1 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

mcp_workbay_orchestrator-0.2.0-py3-none-any.whl (229.4 kB view details)

Uploaded Python 3

File details

Details for the file mcp_workbay_orchestrator-0.2.0.tar.gz.

File metadata

  • Download URL: mcp_workbay_orchestrator-0.2.0.tar.gz
  • Upload date:
  • Size: 197.1 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/6.2.0 CPython/3.12.13

File hashes

Hashes for mcp_workbay_orchestrator-0.2.0.tar.gz
Algorithm Hash digest
SHA256 1cd5fa2f1167c24dcd38c9c3a7d1e23af0ac83b7c4019b3371a3b4d3067e08d6
MD5 d214839d902f15196835fdf5ff5ce90b
BLAKE2b-256 9501df54b6f8e36b7546aa634b9a39ac68d132008ec653fad7cd66ac647819b6

See more details on using hashes here.

File details

Details for the file mcp_workbay_orchestrator-0.2.0-py3-none-any.whl.

File metadata

File hashes

Hashes for mcp_workbay_orchestrator-0.2.0-py3-none-any.whl
Algorithm Hash digest
SHA256 2d67c649b27e875f65e8f6ecaaf45bb7154bd6abf6e7abe46809fbb6d617ba14
MD5 5d6379dfd30615a0d5eef6b56ea511ba
BLAKE2b-256 7edecf831e23dcd032250606db462fdf15c92a82e16d98a7a460e6efb4a6858a

See more details on using hashes here.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page