install a plugin, connect an app, and what a connector brokers

A plugin is a package you install into DGC: skills, an MCP server, or both. An app is a third-party service one of those servers reaches — GitHub, Notion, Linear, Sentry, Supabase, Stripe. MCP is the wire underneath: every tool a plugin adds arrives as mcp__<server>__<tool>, and MCP servers covers the protocol, the remote bridge and the execution boundaries.

Nothing is installed until you install it, and nothing reaches a service until you sign in to it. Two first-party packages — default templates and plugin management — ship inside DGC, so installing those fetches nothing.

The editor owns the browsing surface. Settings ▸ Plugins has three lanes:

• Plugins — what is installed, with its state: Installed, Setup required, or Connected.
• Apps — the individual services those packages reach, each naming the plugin behind it.
• MCPs — the servers themselves, the same catalog as /mcp.

Browse directory opens the curated catalog. Every entry names its licence and, separately, what DGC actually verified — which is often less than "it works": a package whose structure was checked but whose authenticated tools were never exercised says exactly that. Manage marketplaces adds another catalog, and the filter separates DGC curated from Personal and from anything you added.

The terminal does the same work without a browser:

dgc plugin list
dgc plugin search notion
dgc plugin install notion
dgc plugin sign-in notion
dgc plugin installed
dgc plugin uninstall notion
dgc plugin marketplace list
dgc plugin marketplace add SOURCE

A plugin's files are copied into ~/.dgc/plugins at install. Its skills land in DGC's discovery root and show up in /skills after a reload. They are not part of the DGC source tree and stay under their own upstream licence, which is why an entry whose terms need your agreement asks for it before anything is copied — --accept-license ID in the terminal.

Nothing in a package runs on install, and a file arrives without its executable bit. A package's hooks, agents, commands, language servers and output styles are not imported at all, and the install review names each one it is ignoring. A script that survives runs later only through the normal approval you give any command. The package is bounded: at most 40 skills, 64 KiB per SKILL.md, and 8 MiB per file with 64 MiB and 4,000 files across the whole package.

DGC reads the .claude-plugin/plugin.json and .codex-plugin/plugin.json layouts, so a package written for Claude Code or Codex installs here — but only the skills and the MCP servers inside it come across.

Some catalog entries are withdrawn rather than offered, and you will not see them in the directory at all. Figma's remote server requires a client it has approved and DGC is not one of them; Google Workspace needs a project you register yourself. An offer DGC cannot honour is worse than no offer, so it is taken out rather than left to fail at the sign-in. One you already installed, or one that arrives from a marketplace you added yourself, does show — with the reason on its card.

Installing is not connecting. Connect starts whatever sign-in the plugin declares — a browser handoff, or a token you name, such as GITHUB_PAT_TOKEN for GitHub. A plugin can sit installed for as long as you like with its server disconnected, and the model is told exactly that rather than left to infer it: installed, MCP configured but not connected in this session.

Five entries are connectors rather than single services: Composio, Zapier, Arcade and Make, plus n8n for workflows on your own instance. You authorize your accounts inside that service, and its one MCP server then reaches all of them. Composio's card says where: connect and manage your apps in Composio For You → Connect Apps, then come back and ask DGC to use them. App permissions, account selection and revocation stay there. Uninstalling the connector here revokes nothing upstream.

A pasted connector token is kept in the editor's secret storage under DGC's own MCP bearer variable and bound to the exact URL it was given for, never written to the config file. A URL carrying credentials, a query or a fragment is refused outright.

Two consequences, and DGC now states both rather than leaving you to discover them:

• The work happens in their cloud. A connector holds the app's credentials and runs the app request on its own servers — including when your model is running locally on this machine. Their terms govern that part, not DGC's.
• A connected connector may reach a service that has no plugin of its own here. The roster the model reads used to report per-plugin connectivity and nothing else. It read Figma: MCP not connected as Figma is unreachable — with a connected Composio one line below holding the very Figma account it needed — wrote that premise into its own sub-agent's brief, and offered to work from screenshots sent by hand. A connected connector now says that it brokers the accounts you authorized in its own service, and the model is told to search it with mcp_search before telling you a service needs credentials, or a screenshot it cannot obtain. A connector whose server is down advertises none of this.

A rate-limited call from one of these servers now says it was rate-limited. It used to arrive as the same opaque payload as a missing credential, which is the other half of why a busy service read as a locked one.

Uninstall removes the package, its skills, and the servers DGC created for it. A server you edited by hand, or one another plugin also uses, is kept and named in the result — DGC created neither and will not delete either. Plugins and connectors share one flat namespace, so a name belongs to exactly one of them; two things can no longer both claim it and leave skill folders behind that nothing owns and nothing can remove.

A plugin's skills are instructions. They grant nothing: no permission, no account, no tool. Its tools are ordinary MCP tools, and every call passes through permission requests, lifecycle hooks, cancellation, redaction and output bounds like any other; plan mode does not execute them. Reference text a server returns cannot activate a skill or hand itself a tool.

What does deserve care is the server process. Treat a configured server command as a trusted executable: it starts unsandboxed in your workspace, and DGC cannot mediate that process's own filesystem or network activity through tool permissions. See MCP servers.