Tools and skills

​

Tools vs. skills

IMP distinguishes two kinds of agent capability:

• Tools are server-side integrations — API calls, search functions, code runners, and data connectors — installed and managed by administrators. Each tool has a type, a category, and optionally a set of parameters that must be bound before the agent can use it.
• Skills are reusable prompt-level capabilities: pre-written reasoning patterns, formatting rules, or multi-step response strategies. Skills are toggled on per agent and do not require parameter configuration.

​

The Tools & skills section

In the workbench, open the Tools & skills section. The toolbar has:

• Search — filter by name or description (“Search tools by name or description…”).
• Category filter — narrow to a single category (default “All categories”). Only categories present on this deployment appear.
• Clear filters (×) — resets search and category together.
• Expand all / Collapse all — open or close every category accordion.
• Result count — “{n} tool(s) found” when a filter is active, “{n} tool(s) available” when showing all.

Tools are grouped by category in an accordion. Each tool row shows the tool name, description, and an enable toggle.

​

Enabling a tool

Toggle the switch on a tool row to enable it for this agent. For tools with required parameters, IMP automatically opens the Configuration sheet the moment you enable the tool so you can fill in the bindings immediately — the tool stays enabled even if you close the sheet before configuring, but it won’t work until all required parameters have values.

​

Per-tool configuration

Many tools expose one or more parameters that must be bound to a value before the agent can call them. Parameter types include:

• string — a plain text value.
• number — a numeric value.
• boolean — true or false. The configuration sheet renders a toggle; the stored value is the string "true" or "false", parsed to a native boolean at runtime.
• json — a structured object. When the stored value is already an object it passes through as-is; when it is a string, it is JSON-parsed at runtime. Use this for complex configuration like the KB editor’s knowledge_bases map.
• variable reference — a dropdown that lets you pick a named variable from the organization’s Variables store instead of hard-coding a value. Using variable references keeps secrets out of the agent form and allows administrators to rotate values in one place.

To configure a tool: You can reopen the configuration sheet at any time by clicking the Configure button (gear icon) on an already-enabled tool row.

​

Knowledge base editor

The Knowledge base editor is a built-in tool in the default category. Enabling it lets the agent create and update items in selected knowledge bases during chat. When you enable the tool, IMP opens a custom configuration sheet instead of the standard parameter form. The sheet lists every knowledge context in the deployment; check a context to grant the agent write access to it. For each checked context, two switches appear:

• Create — the agent may add new items to this context.
• Update — the agent may modify existing items in this context.

A context with both switches off grants no access even though it appears checked. Only contexts you explicitly include and permit are writable. At the bottom of the sheet, the Skip approval toggle controls whether the agent prompts the user for confirmation before writing. When off (the default), the user sees an approval prompt for every create or update call; when on, writes proceed immediately.

​

KB editor safety model

The KB editor enforces multiple independent gates before any write reaches the database:

1. Explicit per-context opt-in — a context is writable only if the agent’s configuration sheet explicitly enables it with at least one of Create or Update.
2. Row-level write access — for update calls, the platform checks whether the active user has write access to that specific item (matching the item’s rights_mode — public, private, users, roles, or teams). Items the user cannot write are silently reported as not found to avoid probing.
3. Guest refusal — write tools require an authenticated user. Anonymous guest sessions receive a hard refusal; no DB call is made.
4. Schema exclusions — the following field types are never exposed in the tool schema: file, uuid (reference fields), calculated fields, fields marked editable: false, and hidden fields. Reserved internal parameter names are also excluded.

​

Sub-agents as tools

When sub-agent orchestration is enabled on this deployment, other agents appear in the Tools & skills section under the Agents category. Enabling an agent-as-tool means the current agent can call the sub-agent during a conversation — for example, routing specialized questions to a domain expert agent. A toggle at the top of the Agents category controls whether the current agent’s own tools and sub-agents are shown in the list (“Show this agent’s tools & sub-agents”). Self-referential loops are excluded automatically.

​

Skills

Below the tools accordion, the Skills section lists available skills. Each skill row shows the skill name and description with a toggle. Skills have no parameters — enabling one activates it for all conversations this agent handles. See Skills in the Building section for how to define custom skills.

​

Next steps