Copy page

Handbook

Tools and MCP connectors

Tools let a bot reach beyond the model. You set them in the bot editor under Capabilities. Tools has web search and MCP connectors. Mail and calendar (Microsoft 365 or Google Workspace) has its own section.

An MCP connector is an MCP server that your organization has added once. The word "connector" alone means a provider connector for Slack or Microsoft. See Slack and Teams.

Three terms matter on this page:

• An MCP connector is an entry for one remote MCP server. Owners and Admins add it. Bots pick it.
• An OAuth app describes how people sign in at a provider.
• A connected account is one person's sign-in at a provider or an MCP server.

Web search

Turn on Web search to let the bot look things up on the web. Search queries leave GEKI, and Publish asks you to confirm this. Web search works without a workspace and without internet access in the workspace.

In Chat decides who turns it on: Always (on in every chat), On by default (each person can turn it off), or Off by default (each person can turn it on in Chat under Tools). Chats without a person to choose, such as the test in the Console, triggers, Slack, and Teams, use the default.

MCP connectors

Owners and Admins manage MCP connectors in the Console under Building blocks, MCP connectors. Choose New MCP connector and fill in:

• Name. Letters, digits, -, and _. It is unique in the organization. The bot shows it as the name of the tool.
• URL. The address of an HTTP MCP server. Check server asks the server whether it offers OAuth and tells you what GEKI can do.
• Operator and location. Who runs the server, and where. Admins see this when they attach it.
• Icon. Optional.
• Sign-in. How the connector signs in at the server. See below.

A row menu can turn a connector off, list its tools, edit it, or delete it. A connector that is off stops working from the next message in every bot. You cannot delete a connector while a bot uses it. The Console names the bots. Deleting a connector deletes the tokens people pasted for it.

Sign-in

The sign-in is a setting of the connector. It is the same in every bot, the Personal bot included.

A server that follows the MCP sign-in standard needs no OAuth app. GEKI finds the sign-in at the server and signs in as a client named after your organization or your partner, never "GEKI". If GEKI cannot register itself at the server, enter the client ID and secret that you registered there.

The last option sends a token of another provider to the server. Use it only for a server that you run yourself and trust.

With a per-person sign-in, a person without an account gets no tools from that connector. Chat asks for the account. See Accounts the bot needs.

Add a connector to a bot

In the bot editor, open Capabilities, Tools. Tick the MCP connectors the bot uses. For each one:

• Allowed tools. Choose List tools to pick from the tools the server returns. The hints come from the server and are no guarantee. Without a choice, the bot may call every tool of the server.
• Approval. Never ask, Always ask, or Per tool. With Always ask, the bot stops before every call to this server and asks you to allow it. With Per tool, you tick the tools that ask first.

If a server is unreachable, Chat shows which one could not start. The answer can still arrive without its tools.

MCP connectors work in a bot with no internet access in the workspace, because the calls go through GEKI. See Workspace.

On the Personal bot, the Owner or Admin also chooses, for each connector, whether it is always on, on by default, or off by default.

OAuth apps

An OAuth app lets people sign in at a provider, so that bots and skills can use their account. Use one for a provider that is not an MCP server, for example a CRM. Owners and Admins manage OAuth apps in the Console under Building blocks, OAuth apps.

The page shows the redirect URL of GEKI. Register it at the provider. Choose New OAuth app and fill in:

• Name.
• Type. Sign-in, where each person signs in, or Client credentials, where GEKI gets a token for the organization. The type cannot change.
• Issuer. Optional. GEKI reads the discovery document of the issuer and fills the URLs you leave empty.
• Authorize URL, Token URL, Revocation URL, and User info URL. The revocation URL lets GEKI revoke a token when someone disconnects. The user info URL gives the account name that GEKI shows.
• Client ID, Client secret, and Client authentication. The secret is write-only. Leave it empty for a public client.
• Scopes and Scope separator. The scopes the sign-in asks for.
• Extra authorize parameters. One key=value per line, such as access_type=offline.

GEKI signs in with the authorization code flow and PKCE. It refreshes tokens before a message that needs them.

A row menu can turn the app off, edit it, or delete it. For a Sign-in app, Sign in for everyone saves one account in a vault. For a Client credentials app, Get a token saves a token in a vault, and GEKI asks again when it expires. An app that is off stops all use from the next message, and nobody can start a sign-in. Deleting an app deletes its accounts.

A skill uses an OAuth app when its credential is mapped to it in the bot editor. See Skills.

Connected accounts

A connected account is one person's sign-in at an OAuth app, at an MCP connector, or at Microsoft 365 or Google Workspace. A person has one account for each. It belongs to that person. Only their own chats use it.

People manage their accounts in Chat under Settings, Connected accounts. Connect signs in at the provider. Sign in again appears when an account stopped working. Disconnect removes the account and asks the provider to revoke the token when it can. A server without OAuth has a field for a token. The token is never shown again. You can replace it.

Owners and Admins open Members, choose Connected accounts in the row menu of a person, and see the provider, the account name, and the status. They never see the content. They can disconnect an account. When a person leaves the organization, their accounts are deleted.

An account is used only when a person is behind the session. Chat, the API with a person's key, and Slack and Teams direct messages use the account of the person who writes. A trigger uses the account of the person it runs as. A channel thread in Slack or Teams, and a service account, never use a person's account.

Accounts the bot needs

When you do not have an account that the bot needs, the first reply of a chat ends with a card. Choose Connect to sign in at the provider, or enter your token in the field and choose Save. The card shows the hosts that receive it. GEKI never asks for your password. The value goes straight to your connected accounts and never into the chat. After you save it, the bot continues. The same card can ask for a secret that one of the skills of the bot needs.

A bot can ask for an account on its own when your request needs it. It can only ask for accounts the bot is set up for. In Slack and Teams the bot tells you to connect it in Chat.

Approvals and questions

When a call needs your approval, the chat stops and shows a card with a plain question, such as "Send this mail?", and Allow and Deny. For sending mail and creating a calendar event the card shows what the call does: the recipients, the subject, the start of the text, and the attachments. For other tools it lists what the bot filled in. Allow runs that call once. If the bot wants the same tool with other details, it asks again. Deny tells the bot that you refused.

A bot can also ask you questions, up to four at once. They come one after the other in one card: choose one of the answers, or several when the bot allows it, or write your own, then go on with Next. Back changes an earlier answer. Send sends all answers, and they start the next turn.

GEKI enforces the approval for MCP tools that you set to ask, and for the Microsoft 365 and Google Workspace tools below. A bot can also ask on its own. That is a courtesy of the bot, not a guarantee.

Bots that run without you do not offer tools that need approval. A bot started by a trigger, Slack, or Teams does not offer tools that need approval. A trigger on new items can still prepare drafts.

Microsoft 365 and Google Workspace

When your organization has Microsoft 365 for bots on its Microsoft connection, or Google Workspace for bots on its Google connection, a bot can use the mail, calendar, files, people, and meetings of each person who talks to it. The bot uses the account of that person and sees only what that person can reach. Files work only when the admin turned on Files for bots on the connection, and then the bot reaches every file the person can see, with no limit to chosen folders. An admin sets this up once. See Connect Microsoft and Connect Google.

In the bot editor, open Capabilities, Mail and calendar. It shows the suite your organization set up. If it set up both, choose one: a bot uses one of them. Each area is off, Read, or Read and write. These tools exist:

Mail is never deleted. Organizing mail moves it to a folder, marks it, or sets categories (in Gmail: labels). Tools that act outward or replace content ask first. Saving a new file never replaces a file, so it does not ask.

A bot can read a file as text, or put it in its workspace to work on it with a skill or code. It can attach workspace files to a mail and save them to OneDrive or Google Drive. A mailbox that someone shared with the person works in Microsoft 365 when the person has access in Exchange. Gmail has no shared mailboxes for bots. Google Docs, Sheets, and Slides are read as Word, Excel, and PowerPoint files and never overwritten. See what is different with Google.

Text from mail, files, and events was written by other people. The bot treats it as data, never as instructions. Each message has a limit on tool calls.

Publishing asks you to confirm each area. A bot with these areas reads data of people, so keep the internet access of its workspace restricted.

Start a bot when something new arrives

A trigger can look at Microsoft 365 or Google Workspace and start a bot when a mail arrives, an event starts soon, a file is new or changed, or a meeting has a transcript. It uses no model while nothing is new. The run uses the account of the person who set the trigger up, and it can only draft, never send. See Triggers. A bot that keeps a Knowledge Base current from a folder is an example: Keep a Knowledge Base current.

Vaults and credentials

A vault holds credentials that bots can use. Owners and Admins manage them in the Console under Vaults. Choose New vault, then Add credential. Secrets are write-only. The Console never shows a saved secret again.

There are two types of credential that you add:

• MCP server. A bearer token for one MCP server. Select it as the credential of an MCP connector.
• Environment variable. A secret for the workspace, such as a Git token or an API key. Give it a variable name and the hosts it may be sent to. The workspace sees a placeholder that starts with geki-secret-, never the value. GEKI puts the real value into the request headers to those hosts only, for example as a bearer token, Basic sign-in, or API key header. Git over HTTPS to an allowed host uses it as the password. A user name and a password are two variables. A website that only has a login form cannot be used with a stored secret.

A vault also holds the accounts that an admin saves with Sign in for everyone or Get a token on an OAuth app, or with Sign in on an MCP connector. An MCP connector or a skill can use them.

Attach a vault to a bot in the editor under Capabilities, Workspace, Vaults. The hosts of its environment variables are added to the allowed hosts of a bot with restricted internet access. A bot with no internet access cannot use them.

Publishing

Publish lists every MCP connector, credential, and Microsoft 365 or Google Workspace area the bot uses. A connector with a per-person sign-in appears as "Each member uses their own account". You acknowledge new or changed entries before they go live.