DocumentationSet up with your agent

Set up with your agent

Let your coding agent do the setup legwork. Keep the decisions about configuration and downloads with you.

The prompt checks for an existing installation and uses the current release-aware commands: a pinned scoped npx setup, with a source fallback when needed. It asks the agent to explain the selected client and file before changing them.

One good handoff.

“Help me set up Roster. Start local, preserve my configuration, and let me choose what changes.”

Help me set up Roster, the local MCP tool-and-skill router, not a model router.

Read https://github.com/ManagementMO/roster and its current installation/status documentation. This website describes revision 587c8ae. First identify any existing Roster installation by its package and path, using --help (there is no --version flag). Do not assume a command named roster belongs to this project.

Check npm availability for @npmmo/roster@0.0.4. If it is available, prefer the pinned scoped npx flow: npx --yes @npmmo/roster@0.0.4 init --no-dense. On Windows use npx.cmd --yes @npmmo/roster@0.0.4 init --no-dense. Keep the same pinned npx or npx.cmd prefix for follow-up commands; a one-off npx run does not install a global roster command. Offer a global installation only if I prefer it, rather than relying on an unrelated executable already on PATH. If registry access is unavailable, report the actual lookup failure rather than assuming pre-release status, and offer the documented source build with Node 22.17 or newer within Node 22.x, or Node 24.2 or newer, and pnpm 11.9.0. Keep using node packages/cli/dist/bin.js from that checkout. Never use the unrelated unscoped npm package.

Ask which client and scope I want before changing configuration. Automated sync/eject writers support claude-code, cursor, codex, and openclaw only. Discovery is broader. Roster currently routes command-backed stdio MCP servers, not URL-only servers. Explain which existing file sync will select and what it will change. Do not touch unrelated clients or broaden the authorized scope.

Explain that init --no-dense discovers configurations, imports server definitions (including env) into private local state, and prints a receipt; it does not rewrite client configurations. Run it only with my authorization. Keep credentials, raw client configuration, and receipt paths out of chat and logs. Inspect locally and summarize without secret values.

Start with lexical retrieval. If a previous setup or source checkout already has the embedding runtime, set only embeddings to off in the existing ~/.roster/roster.json before starting a client, preserving all other fields. Explain optional dense enable, the approximately 385 MB runtime plus a first-use model download, and get separate permission before enabling or downloading either. Dense status executes a local backend probe without fetching model weights. READY confirms a usable native or WASM backend, not model readiness or permission to use embeddings. Version 0.0.4 also resolves the newly installed or repaired runtime in a fresh process so stale package lookups cannot determine the installation result. The local WASM worker covers the verified Alpine/musl and Intel macOS cases where native bindings cannot load. Missing or unusable runtimes keep routing lexical; do not claim that every architecture has been verified.

Review the receipt and existing backups, then scope sync to the chosen --client. Sync backs up originals before replacing the MCP server map with a Roster launcher. The client normally launches serve over stdio; I do not need a separate hosted service. Transparent mode is the default. Explain five mode before enabling it: draft returns up to five candidates, then the agent chooses call; skills return instructions/resources, not automatic script execution. Respect the client's approval requirements. The generic call tool can invoke mutating backends, so do not label it read-only or disable global safeguards to avoid a prompt.

Explain eject before proceeding. Dedicated configs restore byte-for-byte if unchanged since sync. Supported live-state files restore the original servers at key level while preserving later user changes. Do not use forced restoration or trust overrides. Do not enable telemetry. Preserve the checkout while source-based launchers refer to it. Verify the selected setup without running unrelated backend actions or claiming the whole task is solved. Report what changed and the matching scoped eject command.

Read the full prompt

Help me set up Roster, the local MCP tool-and-skill router, not a model router.

Read https://github.com/ManagementMO/roster and its current installation/status documentation. This website describes revision 587c8ae. First identify any existing Roster installation by its package and path, using --help (there is no --version flag). Do not assume a command named roster belongs to this project.

Check npm availability for @npmmo/roster@0.0.4. If it is available, prefer the pinned scoped npx flow: npx --yes @npmmo/roster@0.0.4 init --no-dense. On Windows use npx.cmd --yes @npmmo/roster@0.0.4 init --no-dense. Keep the same pinned npx or npx.cmd prefix for follow-up commands; a one-off npx run does not install a global roster command. Offer a global installation only if I prefer it, rather than relying on an unrelated executable already on PATH. If registry access is unavailable, report the actual lookup failure rather than assuming pre-release status, and offer the documented source build with Node 22.17 or newer within Node 22.x, or Node 24.2 or newer, and pnpm 11.9.0. Keep using node packages/cli/dist/bin.js from that checkout. Never use the unrelated unscoped npm package.

Ask which client and scope I want before changing configuration. Automated sync/eject writers support claude-code, cursor, codex, and openclaw only. Discovery is broader. Roster currently routes command-backed stdio MCP servers, not URL-only servers. Explain which existing file sync will select and what it will change. Do not touch unrelated clients or broaden the authorized scope.

Explain that init --no-dense discovers configurations, imports server definitions (including env) into private local state, and prints a receipt; it does not rewrite client configurations. Run it only with my authorization. Keep credentials, raw client configuration, and receipt paths out of chat and logs. Inspect locally and summarize without secret values.

Start with lexical retrieval. If a previous setup or source checkout already has the embedding runtime, set only embeddings to off in the existing ~/.roster/roster.json before starting a client, preserving all other fields. Explain optional dense enable, the approximately 385 MB runtime plus a first-use model download, and get separate permission before enabling or downloading either. Dense status executes a local backend probe without fetching model weights. READY confirms a usable native or WASM backend, not model readiness or permission to use embeddings. Version 0.0.4 also resolves the newly installed or repaired runtime in a fresh process so stale package lookups cannot determine the installation result. The local WASM worker covers the verified Alpine/musl and Intel macOS cases where native bindings cannot load. Missing or unusable runtimes keep routing lexical; do not claim that every architecture has been verified.

Review the receipt and existing backups, then scope sync to the chosen --client. Sync backs up originals before replacing the MCP server map with a Roster launcher. The client normally launches serve over stdio; I do not need a separate hosted service. Transparent mode is the default. Explain five mode before enabling it: draft returns up to five candidates, then the agent chooses call; skills return instructions/resources, not automatic script execution. Respect the client's approval requirements. The generic call tool can invoke mutating backends, so do not label it read-only or disable global safeguards to avoid a prompt.

Explain eject before proceeding. Dedicated configs restore byte-for-byte if unchanged since sync. Supported live-state files restore the original servers at key level while preserving later user changes. Do not use forced restoration or trust overrides. Do not enable telemetry. Preserve the checkout while source-based launchers refer to it. Verify the selected setup without running unrelated backend actions or claiming the whole task is solved. Report what changed and the matching scoped eject command.

Checks release availability. Asks before config changes.

What you should expect

Your agent should first identify the installation and ask which client you want to connect. Automated writers support Claude Code, Cursor, Codex, and OpenClaw. It should not treat broader discovery as permission to change other clients.

The normal sequence is:

Inspect the official release state and choose a valid installation path.
Explain what init reads and imports, then run it within your authorized scope.
Review a sanitized summary of the receipt and any parse errors.
Keep the first run lexical, including explicitly disabling embeddings in a source checkout.
Explain and run a client-scoped sync, then let the client launch the router.
Report the matching scoped eject command and restoration behavior.

This prompt is instructions for your agent, not an installer running in the browser. Copying it does not inspect your machine, launch a backend, or grant new permissions.

Keep sensitive material local

An imported server’s env block may contain credentials. Config backups contain original bytes. A receipt can reveal local paths. Ask the agent to inspect those locally and report only the non-sensitive facts needed for setup.

There is no reason to paste a raw client config or key into this website. The interactive homepage is entirely illustrative.

Decisions that remain yours

Five mode changes what the agent sees and should be a deliberate choice. Dense retrieval adds a runtime and model download. Forced restoration can overwrite newer changes. Review overrides can admit withheld skills. None of these is a silent setup default.

Telemetry defaults off, and the current implementation has no upload endpoint. Leave it off during setup.

Next: Read the first-run guide yourself or compare the two routing modes.