AI Toolkits

  • Updated on Oct 1, 2026
  • Published on Apr 23, 2026
  • 4 minute(s) read
Prev Next

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).

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"). 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.

© 2026 Visma