What it is
AI Toolkits in Flows lets you turn any combination of business-app actions (HubSpot, Slack, Visma, Google Sheets, Jira, …) into one or multiple governed Model Context Protocol (MCP) servers that an AI agent or client (Claude, Cursor, ChatGPT, Windsurf, your own app) can call as tools.
Instead of giving an AI agent raw API keys and hoping it behaves, you assemble a curated toolkit in Flows: pick the apps, pick the exact tools (actions), lock down which fields the AI can fill, share it with the right people, and watch every call in the execution log.
What is MCP? The Model Context Protocol (MCP) is an open standard that enables AI models to safely and uniformly interact with external data sources and tools.
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, orinactive. Onlyactiveservers respond to AI clients.AI instructions — server-level system guidance sent on
initialize.Tags — workspace-level labels for organization and filtering.
Sharing scope —
private,specificteam members, or the whole team.
Tool (same as an "Action" in a Flow)
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.
Input modes
For every field on a tool, you choose:
AI — the AI client decides the value at call time. You can add an
aiHintto steer it.Fixed — you set the value once; the AI cannot change it (great for
channel = #alerts,account_id = 123,from_email = noreply@…).
Execution log
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 Flow
The MCP Server Builder is a 3-step wizard:
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).
Configure — For each tool, decide which inputs are AI-controlled vs fixed, add per-field hints, add per-tool "when to use" guidance.
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.
Permissions are assembled in Flows, not in the agent. The AI never sees an API key, never holds an OAuth token, and can never reach beyond the tools you exposed.
Why control access in Flows vs in the AI client
Security & Guardrails
Credential isolation: Real API keys and OAuth tokens never touch the agent, model provider, or prompt. If an agent is compromised, jailbroken, or its logs leak, your upstream credentials remain completely safe.
Principle of least privilege, enforced: Expose only the specific tools and fields an agent actually needs (e.g., "create invoice" but not "delete customer") instead of handing over a broad, all-powerful API token.
Per-field guardrails: Hardcoding fixed values (e.g.,
channel = #alertsoraccount_id = 123) at the flow level prevents prompt injections or model hallucinations from redirecting sensitive actions to the wrong recipient.
Centralized Operations & Scalability
Centralized governance: Permissions live in one auditable place instead of being scattered across scattered agent configs. Change a scope once, and every agent using that flow inherits the update instantly.
Separation of duties: Non-technical operations or admin teams can curate safe, compliant capabilities in Flows, leaving developers and PMs free to build the agent logic without worrying about security implementation.
Revocation without redeployment: Disable a connection or a single tool in Flows and every downstream agent loses that capability immediately - no need to rotate keys, redeploy code, or rewrite system prompts.
Multi-agent reuse: One well-scoped flow can power many different systems (a support bot, an internal copilot, or automated scripts) with consistent behavior, eliminating the risk of misconfiguration across projects.
Vendor & model portability: Because your permissions and logs are decoupled from the agent, you can swap the underlying LLM (from OpenAI to Anthropic) or client UI without re-auditing your entire security stack.
Visibility, Compliance & Debugging
Auditability & compliance: Execution logs provide a tamper-evident, structured record of exactly what the agent did, which arguments it passed, and the outcome - essential for SOC2, GDPR, HIPAA, and incident forensics.
Debuggability: If an agent misbehaves ("Why did it email the wrong customer?"), you can view the exact tool call, inputs, and outputs in Flows instead of trying to reconstruct the error from messy model traces.
Usage visibility & cost control: Logs surface which tools are actually being used and how often, making it easy to spot runaway loops, broken integrations, or abusive patterns before they turn into a major bill.
Safer iteration: Tighten or loosen permissions, add AI-guided hints, or swap target accounts in real time and observe the impact in the logs without risking a regression in your production prompts.