--- title: "AI Toolkits" slug: "ai-toolkits" updated: 2026-10-01T17:50:41Z published: 2026-10-01T17:50:41Z canonical: "docs.connect.visma.com/ai-toolkits" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.connect.visma.com/llms.txt > Use this file to discover all available pages before exploring further. # AI Toolkits ### What it is AI Toolkits lets you expose selected actions from any apps (HubSpot, Slack, Visma, Google Sheets, Jira, …)as governed MCP tools for AI clients. Choose which tools an AI can use, which values it can provide, which data it can see, and who can access the toolkit. ### Quick Example Imagine you want an AI assistant to post weekly sales updates to Slack. Instead of giving the AI full access to your entire Slack workspace, you can build an AI Toolkit that exposes *only* the "Post Message" action, hardcoded strictly to your `#sales-updates` channel. The AI cannot post anywhere else, read other channels, or see your API tokens. ### Core Concepts #### AI Toolkits A named, shareable bundle of apps & tools exposed at a single MCP Server URL (e.g. `https://mcp.flows.visma.com/29bb5f29-748f-3128-92fa-bfe2ef61c142`). > [!WARNING] > MCP Server Access Control > > Access is secured by your Visma Flows sign-in. When connecting it to your AI client you will be prompted to authenticate via a browser redirect before it can use this server. Each server has: - A **name** and **description** (shown to the AI client). - A **status**: `active`, `draft`, or `inactive`. Only `active` servers respond to AI clients. - **AI instructions** — server-level system guidance sent on `initialize`. - **Tags** — workspace-level labels for organization and filtering. - **Sharing scope** — `private`, `specific` team members, or the whole team. #### Tool A single capability inside a server, e.g. *"Send Slack message"* or *"Create HubSpot contact"*. Each tool is bound to: - An **app** (the integration it belongs to). - A **connection** (the credentials/account it runs as). - A set of **inputs** with per-field rules. - Optional **AI guidance** — natural-language hint appended to the tool description ("when to use this"). ### Connection A stored, reusable link to an external account (e.g. *"HubSpot —* [*sales@acme.com*](mailto:sales@acme.com)*"*). Connections live in the **Connections** section and can be reused across many servers and Flows. A connection is either `connected` or `disconnected`; disconnecting instantly disables every tool that depends on it. The AI never has access to App-connections; you securely store and manage them inside of Flows. Actions execute using the permissions of the configured Connection, not the permissions of the AI user. ### Input modes For every field on a tool, you choose how its value is determined: - **AI** - The AI client dynamically decides the value at call time. You can add an `aiHint` to steer its decision. - **Allowed values** - You define a restricted list of acceptable values (e.g., a specific list of 3 permitted Slack channels). The AI is aware of this attribute and must pick one of your pre-approved options at call time. - **Fixed** - You set a hardcoded value once (great for `channel` = `#alerts`, `account_id` = `123`, `from_email` = `noreply@…`). This field is entirely hidden from the AI - it does not see the attribute, cannot change it, and does not even know the value exists behind the scenes. ### Response sent to the AI You control not only what the AI can *do*, but what data it can *see*. Select exactly which fields from the tool response are exposed to the AI, ensuring it receives only the context it needs while keeping sensitive or unnecessary data within your systems. For each tool, you can choose between: - **Full response:** The AI receives the complete data payload returned by the tool. - **Selected fields:** You can toggle off the full response and manually check only the specific fields the AI needs to see. Any fields you leave unchecked - including any new data fields the app might add in the future - remain securely in your systems and are never sent to the AI. ### Execution Logs Every tool call is recorded: which server, which tool, which connection, the arguments the AI passed, the response, timestamp, and outcome. This is your audit trail and your debugger. ### The setup The MCP Server Builder is a 3-step wizard: 1. **Tools** — Pick apps, then pick the actions you want to expose as tools. Each picked app needs a **Connection** (pick an existing one or create a new one inline). 2. **Configure** — For each tool, decide which inputs are AI-controlled vs fixed, add per-field hints, add per-tool "when to use" guidance. 3. **Review & activate** — Set name, description, server-level AI instructions, tags, and sharing. Hit **Save and activate** → server goes live. Drafts are saved at any step. Deactivating a live server keeps it as `inactive` (not `draft`) so the configuration stays intact. ### Connecting an AI Client After activation, the server detail page shows: - The **MCP URL** (copy button). - A **Share** dialog to grant access to specific teammates or the whole team. - An **Executions** panel with the live call log. ### Why control access in Flows vs in the AI client AI clients are good at deciding **when and how to use a tool**. They should not be responsible for defining **what that tool is allowed to do**. By configuring permissions in Flows, you create a controlled boundary between the AI and your connected apps: - **Expose only the tools the AI needs.** Choose exactly which actions are available instead of giving the AI access to an entire app or API. - **Control what the AI can change.** Inputs can be AI-controlled, restricted to allowed values, or fixed entirely. A fixed value is hidden from the AI and cannot be overridden. - **Control what the AI can see.** Return only the fields the AI needs from an app response, keeping other data inside Flows. - **Keep credentials out of the AI client.** Connections and their credentials are managed in Flows. The AI uses the capabilities you expose without receiving the underlying API keys or OAuth tokens. - **Manage access centrally.** Change or revoke a capability in Flows without having to update every AI client that uses it. - **See what actually happened.** Tool calls, inputs, outputs, timestamps, and outcomes are recorded in the execution log. This means your AI client can remain flexible while the capabilities it can access stay predictable and controlled.