Skip to main content
Integrations give Roomote more context inside a task: tickets, docs, monitoring, analytics, data systems, customer history, deployment state, and shared memory. This section does not list provider categories that have their own setup paths: communications providers, source-control providers, inference providers, and sandbox providers. Configure those from the provider-specific docs instead. Deployment operators can prevent every integration in this curated catalog from being configured or used by setting R_CURATED_INTEGRATIONS_DISABLED=true and restarting Roomote. Existing connections remain stored but inactive, so unsetting the value restores them. This policy does not affect the separate provider categories above or MCP servers defined on an environment.

​
Connection patterns

You will usually see one of these setup models:
  • Admin connection once: an admin connects the integration for the deployment from the Integrations page
  • Enable first, then teammates link accounts: an admin enables the integration, then each teammate links their own account from Personal Settings when they need it
  • Workspace plus user identity: the deployment connects the integration, then individual users link their identity so Roomote can associate actions correctly
You can also ask Roomote to connect any integration in this catalog from a session. Roomote starts the provider’s OAuth flow when the integration supports OAuth, opens the existing secure configuration form when an admin-managed key or certificate is required, and enables keyless integrations directly. The same admin, ownership, and deployment availability rules apply as on the Integrations page. Credentials are never collected in chat. Most catalog integrations connect once for the whole deployment, so connecting one makes it available to everyone; a few connect for one person instead. If you ask Roomote to connect a provider just for yourself, it goes by which kind that provider is. A per-person integration it simply connects for you. A deployment-wide one it does not connect quietly: it tells you the integration would be shared with everyone, and offers the routes that can stay private instead, the provider’s own remote MCP server added under Personal Settings or a personal integration key. It connects the shared integration only if you say that is fine. Roomote can list the full built-in catalog and current connection status without starting setup. A connection starts only after you ask to connect a provider. If you explicitly request a remote MCP server or direct API access instead, Roomote keeps that choice separate from the built-in integration path. A denied or pending authorization, unavailable integration, or permission failure is not silently bypassed with another connection method.

​
Manage available tools

Some connected integrations expose a Manage tools action on the Integrations page. Admins use it to choose how Roomote can use each of the integration’s tools. These per-tool choices are available without an Experimental opt-in:
  • Always allow: the tool runs without asking. This is also what a tool you have not made a choice about does.
  • Always ask: every call pauses until the session owner allows it once, allows it for the rest of that session, or denies it. A task asks the owner of its session the same way, and a task nobody can answer for, such as one an automation started, cannot run the tool.
  • Disable: the tool is hidden from Roomote and refused if called directly.
Tools are grouped into read-only and write/delete tools when the integration describes them, and each group can be set in one click. Choices apply to the whole deployment from the next session turn. In a session, the owner can also ask to be asked about any tool for the rest of that session from the tool’s call in the transcript. When an approval is pending, it can be decided from the session; Slack, Discord, and Telegram also show approval buttons in the conversation. Microsoft Teams keeps the approval action in the linked web session. Members manage the same choices for their own private MCP servers from Personal Settings; those apply to their own sessions only. Some integrations can only list tools after the first user links their account from Personal Settings.

​
Supported integrations

​
HTTP APIs without an MCP server

Deployment operators can configure HTTP integrations for approved HTTPS APIs. Sessions and sandbox agents use the same actor access rules, while Roomote keeps credentials server-side and attaches them to authorized requests. This opt-in feature does not change sandbox networking.

​
Custom MCP servers

Beyond the built-in catalog, you can connect your own MCP servers at two scopes:
  • Deployment-wide, on the Integrations page (see Custom MCP servers): remote servers (with header or OAuth authentication, credentials held server-side) and local stdio servers, available to agents in every task.
  • Per-environment, in the YAML view of the environment editor. See Environments. An environment entry with the same name as a deployment-wide server takes precedence in that environment.
Use deployment or user-linked integrations when the tool is broadly useful across teams. Use an environment-level MCP server when the tool only makes sense for one workspace, repository set, or self-hosted service. To use Roomote itself from an external OAuth-capable MCP client, connect the Roomote MCP. It can inspect Roomote and connected chat context, search and read tasks, list launch environments, launch or cancel tasks, and send follow-up messages. Its browser-issued credential does not grant general API or admin access.

​
A practical order

For most teams, this order works well:
  1. the required providers: Comms, Source Control, Inference, and Sandboxes
  2. one task-tracking integration, such as Linear, Jira, or Asana, if your team already works there
  3. one monitoring or deployment integration, such as Sentry, Grafana, Railway, Better Stack, or Vercel, when investigations need it
  4. one knowledge-base integration, such as Notion, to get tasks done directly from specs and runbooks
  5. one data integration, such as Snowflake, Supabase, or Neon, when tasks need database or warehouse context
  6. Supermemory when you want durable team context to carry across tasks and sessions
After each connection, run a small task that uses the new context. For example, ask Roomote to summarize a linked issue, inspect a monitoring alert, or explain which environment a support thread belongs to.