Set up and configure a tool

Setting up a new tool

Create from a template (recommended)

1. Go to Settings → Integrations
2. Click “Add integration” at the top right → “From template”
3. Choose a template

If you already reach an integration from this template, because you set it up yourself or because it is shared with you, the card opens that integration with “Open” instead of creating a new copy. If you still need a second one, for example for another environment, create it with “Add another”.

The setup wizard then takes you through the setup step by step:

1. Guide: what you need to prepare with the provider. Afterwards you find it at any time on the integration’s “Guide” tab.
2. Settings, only if the template has any: for example a database’s server and port, how the target is reached, or your company’s app for Slack.
3. Connect account: you sign in with the provider or enter your key, exactly as with “Connect” in the overview. 9brains checks the account right away and tells you whether it works and, if not, why. Admins and the owner choose here whether the account belongs to them or to the company. “Connect later” finishes the setup without an account.

At the end you land on the new integration’s “Access” tab. That is where you decide who else may use it. “Cancel” or leaving in the middle of the setup removes the half-finished integration again.

Set up an MCP server manually

For MCP servers that are not available as a template:

1. Click “Add integration” → “Manual MCP server”. The same setup wizard opens as for a template
2. Server: give it a name, enter the server URL and choose how the server is reached (public or through the On-Premise Connector). With “Next”, 9brains checks the address and shows the result below the field. Only now is the integration created. If the server does not answer as expected, check the address; if it is just unreachable right now, go on with “Continue anyway”
3. Sign-in, only where needed: if the server requires a token, you set which header it goes in. If it signs people in with OAuth, you set up the app everybody signs in through here, see OAuth for your own MCP servers
4. Connect account: as for a template above

If the server needs no sign-in, the setup is finished after the first step. 9brains detects the available capabilities when it checks the address or at the first sign-in. You define parameters of your own afterwards on the “General” tab.

Your own skills

You no longer build custom automations via tool management but directly in the chat: in the Skills area in the sidebar. There you create skills in conversation, connect them to external services when needed and share them with your team. All details under Skills.

Configure a tool

Under Settings → Integrations, the gear icon on a row opens the integration’s editor. Only the integration’s owner and administrators see the gear icon. The configuration is split across several tabs: General, Access, Guide (when the template brings one), Capabilities (MCP servers only) and Audit. Whoever may not edit the integration lands on the Access tab right away and finds their own account there.

Tab: General

• Integration active: turns the integration on or off. Integrations that are switched off are not available to the AI. An MCP server can only be switched on once a check has found its capabilities; what is still missing shows right below the switch.
• Name: display name of the integration (max. 100 characters)
• Description: brief explanation of what the integration is for (max. 500 characters)
• Notes for the AI: here you tell the AI when and how to use this integration (max. 8,000 characters). Example: “Only use this integration when someone explicitly asks for Databricks data.”
• Server settings (MCP servers only): server URL, reachability and parameters, see below
• Merge (administrators only): take other integrations of the same system into this one, see Merging integrations.
• Delete integration: at the bottom of the page in the danger zone. The confirmation names who loses the integration. All accounts of the integration are deleted with it, other people’s included. If other people’s accounts are connected to it, only the owner and administrators can delete it. Deletion cannot be undone.

Changes are saved automatically, a save button is not needed.

Server settings (MCP servers)

For MCP servers the connection settings sit on the “General” tab, below name and description.

For template-based tools:

• The parameter fields are predefined by the template
• Enter the required values (e.g. server URL)
• Secret values (e.g. API keys, passwords) are stored as an account: enter them once, after that they can no longer be viewed, only replaced or deleted
• What to enter is explained step by step on the “Guide” tab

For manually created MCP servers:

• Server URL: the address of the MCP server (required field)
• Healthcheck URL: optional endpoint for availability checks
• Sign-in with a token: if your server expects a fixed token, switch on “The server requires a token”. Below it you set the header it travels in: header name (default Authorization) and prefix (default Bearer; leave it empty if the server expects the bare token). You do not enter the token itself here: everyone the integration is shared with stores their own token as an account on the “Access” tab. For one token that applies to everybody, create it there as a company account.
• Define parameters: add your own parameters (text, number, or yes/no). For each parameter you can decide how it is passed to the server (as an argument, HTTP header or query parameter).

Servers in your own network:

If the integration talks to a database or server in your company network, 9brains first asks how the target is reachable:

• Publicly reachable: For servers that can be reached directly from the internet. You enter address and port yourself, as before.
• Through the on-premises connector: You pick one of the services created in the on-premises connector. Address and port then come from there. Next to every service you can see whether the connector currently reaches it.

Available for Microsoft SQL Server, PostgreSQL and Oracle. On all three you enter server, port, database, username and password in separate fields. Once you pick a service, the server and port fields disappear, because both come from there. Username, password and database stay, you still enter those yourself.

The same applies to an MCP server you created yourself. There the choice sits above the server URL. Once you pick a service, you still enter your MCP server’s internal address as the server URL, exactly as it reads in your network (e.g. http://mcp.intern.company.com:8080/mcp): address and port are replaced by the service, the path behind them is kept. Your MCP server does not have to be reachable from the internet for this. Since a server URL reveals no protocol, every service in your workspace is offered here.

On PostgreSQL, 9brains requires an encrypted connection by default. The form carries the tick box Verschlüsselte Verbindung verlangen for this. If the server in your own network does not speak TLS, clear it; the path through the connector is encrypted either way. On Oracle the same box is clear by default and switches the connection to TLS, where the port is usually 2484 rather than 1521.

For the databases, the list only shows services with a matching protocol. If there is none yet, a note with a link to the connector appears instead. Only an administrator can create services; anyone setting up an integration can pick one.

Changing the address, connector or sign-in:

If you change the server URL, the On-Premise Connector service or the app used to sign in with the provider, other people’s accounts on this tool are paused. Their row in “Who has access” then shows “Account awaiting confirmation” and the account is not used until its owners confirm the new address or sign in again; they see the new address when they do. If the tool moves to another server (another host or another connector service, not just another path), every sign-in with the provider is paused as well, your own included, and every company account, until they are signed in again or confirmed by an administrator. Nobody can sign in again until 9brains has checked the new address; if the sign-in there belongs to another provider, 9brains removes the current app. Before you save, 9brains tells you what will happen and how many accounts are affected. Your own keys keep working.

Checking the address:

There is no button for testing here. For an MCP server you set up yourself, 9brains checks the address as soon as a changed server URL, healthcheck URL or reachability is saved, and shows the result right below the server URL:

• Success (green checkmark): the connection works, the target system accepted us and the available capabilities have been detected. The response time is shown in milliseconds.
• Reachable but unproven (amber exclamation mark): the server answers, but the check could not establish whether the system behind it really accepts us. This applies to servers with no probe query on file.
• Failed (red X): the connection could not be established, or the target system refused access. Below it you see what the target system itself answered, complete and verbatim. Expand long messages with “Show all”, and use “Copy details” to paste them, including the error ID, into a support request.

Whether an account works, you check with “Test” on that account on the “Access” tab. It is the only test button on the page; if the test finds an MCP server’s capabilities for the first time, the integration can be switched on afterwards. MCP servers with a sign-in at the provider are the exception: there, a configured sign-in is enough, and 9brains detects the capabilities at the first sign-in, see OAuth for your own MCP servers.

Merging integrations

If the workspace has several integrations for the same system, for example because everyone used to set up Microsoft 365 for themselves, administrators merge them into one. Under Settings → Integrations the notice “Duplicate integrations” points this out. Each name in it leads to the integration best suited to merge the others into: the one shared with all members, otherwise the oldest.

1. Open the integration that should stay. On the General tab the Merge section appears as soon as there are other integrations of the same system
2. The list shows each of them with its owner and what moves with it, for example “3 accounts · 1 agent”. The ones that are switched on and have no settings of their own are preselected. If one has its own settings, for example its own notes for the AI, or is switched off, this is noted below it
3. Click “Merge” and confirm

What happens:

• Accounts move over, together with everyone they are shared with and the agents that use them. Nobody has to sign in again. Whoever already has a default account at the integration that stays keeps it as their default.
• Sharing is added, the previous owner included. Nobody loses access.
• Agents and apps that use one of the merged integrations use this one afterwards.
• Capabilities (MCP servers only): if a capability is not allowed in one of the integrations, it stays not allowed. If the integration that stays does not know a capability yet, the message after merging names it; you then set its permission on the Capabilities tab.
• Settings such as the notes for the AI come from the integration that stays. Whatever the others had set differently is dropped.
• Not mergeable are integrations with a different address, sign-in, fields or connector. Their accounts would otherwise reach another endpoint than the one they were set up for. Such integrations are listed but cannot be selected.
• The merged integrations are deleted afterwards.

Several integrations for the same system remain allowed, for example for two departments with different environments or permissions. Merging is an offer, not a must.

Tab: Access

This is where you see in one place who uses the integration and with which account. From top to bottom:

• Admin consent (Microsoft 365 only): whether admin consent has been granted, otherwise the “Grant admin consent” button.
• “Who has access”: one list in which every person and group shows exactly once. On the right of each row a badge says which account they work with, for example “Account connected” (in your own row “Own account connected”), “Via the account of Anna Maier”, “Via company account”, “No account yet”, “Account connected · last check failed” or “No longer shared, own account not used”; on a phone it moves below the name. Above it, one sentence “Visible to” says who sees the integration at all, for example “you, admins and 4 other people” or “all members”: its owner, the administrators, everybody it is shared with and everybody an account on it is shared with.
• The owner is always the first row of the list, marked “Owner”, and cannot be removed. Every integration belongs to one person. They and administrators hand the integration over to someone else in the workspace with “Change owner” on that row, as with an agent. A company cannot be chosen as owner: the owner looks after the settings and who it is shared with; you give an account to the company with “Hand over” on the account. Sharing, capabilities and accounts stay as they are when the owner changes; the new owner maintains the company accounts as well.
• Your own row shows where you stand and the one action you need: “Connect account”, or “Sign in again” after an error. Expanded, it shows your accounts on this integration and the ones shared with you. With several accounts of your own, the row shows the state of your default account.
• “Company accounts”: below the list, because they belong to no person.

Whoever may not edit the integration only sees the owner and themselves in the list.

Sharing

Under “Who has access” on the Access tab you decide who may connect an account of their own to this integration: whoever is added there may do so. That is all sharing controls: whoever has an account of this integration shared with them has access to the integration, even without sharing. A company account is used by whoever it is shared with; sharing the integration alone is not enough for that. As long as you add nobody and share no account, only its owner and the administrators see the integration. That way an administrator can set up and test a new integration in peace before anybody else gets to see it.

1. Click “Add group or person …”: the picker shows all existing groups and people right away, grouped by kind. You only need to type to narrow the list
2. Select the entry. Whoever already has the integration is greyed out and marked “Already assigned”
3. To remove someone, click the bin next to the name

The owner and administrators share an integration. Only administrators share it with all members of the workspace at once, and only they take that back.

Administrators can also assign an entry with the “Assign” tick box: the person is then expected to connect their own account and is reminded of it when signing in. That is why the tick box only shows on groups and on people who have not connected an account of their own yet. Before the assignment applies, 9brains asks and says who will be reminded; for a group with the number of members. Removing the tick again needs no confirmation. More under Assigned integrations.

The stand of each entry is the badge on the right of its row, “Assigned · no account yet” for an assignment without an account. For groups it reads below the name, for example, “3 of 5 connected”. Clicking it expands the group and shows every member with their email address and where they stand, including who works through whose account. Whoever already has a row of their own above, such as you or the owner, is not listed there again, and the number counts only the rest. Only the owner and administrators see where entries stand.

The same list also shows everybody who reaches the integration without an entry: whoever works through an account shared with them, a group an account is shared with, and whoever still has an account of their own although sharing with them has ended (“No longer shared, own account not used”). These rows have neither a bin nor a tick box; you can add them with “Add a group or person …” like anybody else.

Whoever the integration is shared with finds it under Settings → Integrations and connects their own account there if the service needs one. Sharing the integration does not pass on your own account. If colleagues should work with your account, share your account; they do not need the integration to be shared with them for that. The integration then shows up in their overview with “Via the account of …” or “Via company account”; they can only connect an account of their own there once it is shared with them.

When sharing ends, the integration disappears from that person’s overview and from the chat, unless someone shares an account of this integration with them. Their own account there is then no longer used.

Accounts on the integration

Expand your own row in “Who has access” to see your own accounts on this integration and colleagues’ accounts you work with here. Below the list, “Company accounts” shows the company’s accounts with their sharing list and the roles “Use” or “Use and pass on”. Here you test an account, replace the credentials, start over with “Sign in again” for services with a sign-in at the provider, and share, hand over or delete it. If an account does not work, the account says why and what to do, for example “Not signed in yet”, or after a failed check “Sign-in expired” with a pointer to “Sign in again”, also when the daily check found it. If none of the known reasons fits, testing the account names the exact one. You also find your own accounts under Settings → Integrations in the expanded row.

Admins expand a person in the “Who has access” list to see their accounts on this integration. They can test and revoke them there, but not change or share them; only the account’s owner can do that.

Company account: Administrators and the owner of the integration create one under “Company accounts” with “Create company account”. This creates an account that belongs to the company: a key that applies to everyone, or a sign-in at the provider, for example for a team mailbox. For a sign-in, you sign in in the provider’s window with the account everyone should use, not with your own. A new company account starts out shared with all members; right afterwards you decide who exactly gets it and in which role. Whether the integration is shared with someone does not decide this; it only says who may connect an account of their own. The company account stays when you leave the company. Administrators and the owner of the integration can replace its key, sign in again, share or delete it. More under Personal account and company account.

To set up a personal account for a colleague, you create it as your own, test it and then hand it over to them.

For MCP servers with a sign-in at the provider, this is where you sign in with your own account using “Connect account” in your row and delete it again. If you only use the tool, you do this more simply right in your row under Settings → Integrations. Your account applies to this integration only, even if a second integration has the same address. “Add another account” signs you in with a second account; the AI uses your default account, and “Use as default” makes another one the default. Like any account, you can share it with people and groups: they then work with your account as long as they have no account of their own at this integration. The integration then shows up in their overview even without sharing. If you delete it, they lose access too. Such a sign-in cannot be handed to agents yet. Setting up the sign-in with the provider, that is registering the app or entering client ID and client secret, is reserved for whoever may edit the tool; until then everyone else sees “Sign-in not set up yet”. The company’s app for templates is stored by administrators only.

Tab: Capabilities (MCP servers only)

Shown after a successful connection test. Lists all capabilities (tools) that the MCP server provides.

For each capability the integration’s owner and administrators set the permission. It belongs to the integration and applies to everyone who uses it, whichever account they use. If two groups need different permissions, create two integrations and share each with one group.

Permission	Meaning
Always allowed	The AI may use this capability at any time
Not allowed	The AI may not use this capability
Locked	Locked by 9brains, cannot be changed in the workspace

9brains does not ask for a separate confirmation on each call here: whatever is allowed, the AI may use.

Example: You want the AI to be able to read emails but not send any. Then set “read email” to Always allowed and “send email” to Not allowed.

Tab: Audit

Shows when the AI called this tool, with search and filter options. You see your own calls; administrators see the calls of all workspace members.

Connecting Microsoft 365

The Microsoft 365 integration gives the AI access to emails, calendars, OneDrive, Teams, contacts, tasks and other Microsoft services. Each user connects their own personal account.

Prerequisite: admin consent

Before anyone can sign in with Microsoft 365, an administrator of your Microsoft organisation must grant admin consent once. You do this directly in the integration: at the top of the “Access” tab (during setup right in the first step, “Instructions”) an admin of the workspace clicks “Grant admin consent” and signs in to Microsoft as a Global Administrator or Application Administrator. It then reads “Granted on … by …”, and the integration can be shared. More under Microsoft authorization for administrators.

Set up the integration

1. Go to Settings → Integrations
2. If Microsoft 365 is already in the list, click “Connect” in its row. Otherwise click “Add integration” → “From template” → “Microsoft 365”
3. A sign-in window opens: sign in with your Microsoft 365 account and allow access

Your account is active immediately. The AI can now access your emails, calendars, files and other Microsoft services. Afterwards the row reads “Connected as” with your Microsoft account. Expanded, it lets you test the account, sign in again or delete it.

Troubleshooting Microsoft 365

If the AI can no longer access emails, calendars or other Microsoft services:

1. Check your account: Go to Settings → Integrations, expand the “Microsoft 365” row and click “Test” on your account. If it reads “Not signed in”, connect again (see above).
2. Sign in again: If the test fails or the row shows “Last check failed”, click “Sign in again” and sign in with Microsoft again.
3. Check admin consent: Only if the message “Administrator approval required” appears during sign-in is the admin consent missing. An admin of your workspace grants it in the integration.

Authentication with external services

Depending on the integration, there are different sign-in methods:

Skill templates and connected skills: accounts

Credentials for skill templates and connected skills are stored as accounts: you enter them once in a secure dialog, after which they are stored encrypted and can never be displayed by anyone again, only replaced or deleted. Testing, renewal and the history are available under Settings → Integrations in the expanded row.

OAuth 2.0 (e.g. Microsoft 365, Google Workspace)

OAuth enables a secure sign-in without you having to enter your password in 9brains: you sign in directly with the provider in a popup and allow access. The sign-in is renewed automatically as long as the account exists. To revoke access, delete the account under Settings → Integrations.

OAuth for your own MCP servers

An MCP server you run yourself can use OAuth as well, no template required. Every user then signs in with their own account and sees exactly what they are allowed to see in the source system. How to do it:

1. Set up the server manually as described above. When it checks the address, 9brains reads the sign-in settings from the server itself
2. In the “Sign-in” step you register the app automatically if the server supports it. Otherwise you enter the client ID and client secret you registered with the operator of that server
3. In the “Connect account” step you sign in with the provider. After that, every user does this once for themselves in their row under Settings → Integrations, including people the tool was only shared with

You don’t need an account of your own with the provider to set it up: “Connect later” finishes the setup without signing in, and the integration is switched on. 9brains detects the capabilities as soon as the first person signs in; until then the AI offers no capabilities from this server.

If you need to change the app, for example because the client secret was renewed or the wrong app was entered, the “Access” tab has the buttons “Register again” and “Enter another app” under “Sign-in app”. If the integration gets a different app, everyone else has to sign in again afterwards; their accounts are paused until then. A new client secret for the same app leaves their accounts as they are.

For the detection to work, the server must publish its sign-in settings where the standard expects them: under /.well-known/oauth-protected-resource including the server’s path, so for a server at https://example.com/api/mcp that is https://example.com/.well-known/oauth-protected-resource/api/mcp. If 9brains finds nothing there, only API key authentication remains.

API key for MCP servers

Manually set up MCP servers that do not offer an OAuth sign-in use parameters in the tool editor:

1. Create the API key in the respective service (for a template, the “Guide” tab explains how)
2. Enter the key in the last step of the setup, or later on the “Access” tab with “Connect account” in your row
3. Check it with “Test” on the account

These keys are also stored as an account: encrypted and no longer viewable after saving. Testing and replacing happen on the tool’s “Access” tab or under Settings → Integrations.

Security & privacy

Credentials

• All credentials (API keys, sign-ins with providers) are stored encrypted
• Credentials are never shown in plain text in the interface
• Sign-ins with providers are renewed automatically as long as the account exists

Skills and code execution

• Skill code runs in a fully isolated sandbox environment
• The sandbox has no access to other user data or internal systems
• Each chat session has its own isolated working area
• After the session ends, the sandbox environment is destroyed

Connected skills (skills with external access)

• When a skill accesses external services (e.g. your CRM), the credentials from your account are only inserted automatically when a network call is made
• The code in the sandbox never sees the credentials directly, and they are only ever sent to the service they were stored for
• Even the AI itself never knows your credentials: your input bypasses it and goes straight into encrypted storage