Plugins

Connect MCP servers to Atlas and install their configuration into supported agent CLIs. Configuration and a live connection are separate steps.

The bundled servers

DeckSpace bundles Node-based MCP servers for project Memory, global Memory, Board and its desktop Bridge. They run over stdio. The Bridge talks to the running app through its authenticated local API.

Keep Node available to the process that launches your CLI. A server declaration is not enough if its command or script cannot start.

Connect a plugin

1. Open Plugins and choose a server from the registry, or open the plugin folder to add its declaration.
2. Review the command, arguments and required credentials. Installing a third-party server allows that program to run on your machine.
3. Press Connect to start the server for Atlas and inspect the tools returned by its handshake.
4. To use it from terminal agents, select a workspace and press Install into your CLIs. Read each CLI's result, then restart its session.

Confirming plugin actions

Atlas asks for confirmation before calling a plugin tool. The tool's name and input schema do not guarantee what the third-party program does. Agent CLIs apply their own permission and approval settings after they load the server.

Configuration written for each CLI

The sync action detects installed CLIs and writes their supported format. It includes the bundled servers and enabled, valid plugin declarations. It reports created, merged, unchanged, manual, skipped or error for each destination.

Destinations are relative to the selected workspace unless a user-wide path is shown. If a plugin has environment values, the sync result tells you when those values were written into a project file. Keep credentials out of version control.

After configuration changes

Restart your CLI sessions. A successful write does not add a new server to an already-running session. Complete any CLI-specific workspace trust or server approval step, then inspect that CLI's live tool list.

Existing entries are preserved. Invalid configuration is left untouched and reported. Some commented JSON or YAML files need a manual edit; the result gives the reason and the snippet to add.

Installed app paths

The release bundles runnable server scripts with their dependencies. Configuration uses the installed app's resource path. DeckSpace can repair its own bundled entry when that entry points to a missing script; it preserves a working entry owned by another installed build.

If you move or remove a build, inspect the sync results again. Preview builds do not rewrite your working app's shared CLI configuration.

What a connection test proves

A successful connection proves that DeckSpace could start that server and receive its MCP response. It does not prove that another CLI loaded the same configuration or that every tool will succeed. For an end-to-end check, restart the target CLI, inspect its tool list and ask for a harmless read in the intended workspace.

For errors, check Node and the server command first, then the configuration path, credentials, workspace trust and any required approval. Keep DeckSpace running for tools that use its Board or Bridge API.

Check the exposed tool list

Connecting a server does not expose every DeckSpace room automatically. Inspect the tool list returned by that server before relying on a capability. Code Search is available in the app; use that room when your CLI's connected server does not list the search you need.

A reliable setup check

1. Select the project you intend the tools to use.
2. Connect the plugin for Atlas, or install its configuration for your CLI.
3. Read every sync result and resolve manual or error rows.
4. Restart the CLI and complete its own trust or approval prompts.
5. Verify one harmless read against the intended project before starting a larger task.