Plugins and connectors

Connectors: remote services over MCP

A connector links Anymo to a remote MCP server over streamable HTTP, giving runs access to that service's tools.

1. Pick from the catalog, or add by URL

   The built-in catalog includes providers like Hugging Face; add-by-URL connects any compatible remote MCP server.

2. Sign in with your system browser

   Connect opens the provider's own authorization page in your default browser; Anymo shows "Waiting for authorization" and resolves when the loopback callback lands. Anymo never sees your password, and the OAuth token is sealed at rest like a provider key.

3. Use it in chat

   Connected tools join the registry and the @ palette. The agent can call them mid-run, and because every MCP tool is treated as high risk, each call asks for your approval, in every permission mode, with only allowlisted tools callable at all.

The connector detail shows the provider mark, a connection-state sentence, and a single Connect or Disconnect button. Errors read as a status sentence with Reconnect. Disconnecting removes the sealed token.

Plugins: bundles of skills and hooks

A plugin is a directory under plugins/<name>/ in your workspace, with a manifest describing its components:

plugins/demo/
  anymo-plugin.json     # manifest: name, version, enabled, components
  skills/               # skill bundles, shown under "From plugins"
  hooks/hooks.json      # lifecycle hooks
  mcp.json              # MCP servers the plugin brings along
  agents/  monitors/  settings.json

The plugin detail page shows its source, version, author, and last update, a Skills grid of slash-command chips, and a "Try asking" list of example prompts you can run as-is. Component names are namespaced (demo:skills, demo:write_guard) so two plugins never collide, and component paths must stay inside the plugin directory; traversal is rejected.

What hooks can do

Hooks let a plugin participate in the run lifecycle: add context when a run starts, deny a risky tool call before it executes (PreToolUse), answer permission requests by rule (PermissionRequest), or flag output for review (PostToolUse). Hooks run in deterministic priority order, and their output is always redacted and size-capped before it is recorded. Hooks can tighten safety; they cannot loosen it.

The trust model

• Each loaded plugin records a trust hash over its manifest and hook file. If the plugin changes, it must be re-trusted before its hooks run again.
• Command hooks are disabled by default. When you enable them for a plugin you trust, they still run through a guarded process path: cleared environment, explicit allowlist, bounded and redacted output.
• Connector and MCP tools are always high risk and approval-gated, and a server's tool allowlist fails closed when empty.
• MCP tool annotations are treated as untrusted hints; nothing a server says about itself can lower its risk or approval level.

Local MCP servers

Beyond GUI connectors, developers can wire local stdio MCP servers in .anymo/mcp.toml, with per-server allowlists, timeouts, and output caps. The configuration format and the Rust embedding API are on MCP for developers.

Frequently asked questions

The OAuth window never appears.

Connector sign-in uses your system default browser; check one is configured. If the callback times out, retry from the Plugins view.

Where do connector tokens live?

Sealed at rest: encrypted on disk with a master secret in your OS keychain. They never appear in config files, events, or the UI, and removing the connector removes the token. See Storage and data.

Can a plugin's tools run without me noticing?

No. MCP and connector tools ask for approval on every call in every mode, plugin command hooks are off until you trust the plugin explicitly, and tool arguments are not logged by the MCP host.