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

The section shows only what the agent has: three groups — Sub-agents, Skills and Tools — each with a count, the enabled entries, and an Add … button. A tool row keeps its configure and info buttons; the switch or the remove button takes it off the agent. A group without entries shows what the button would add.

​

Enabling a tool

Click Add tools (or Add sub-agents, Add skills). The picker lists the instance’s catalogue: search by name, description or category, narrow tools by category with the chips, tick what you want, and confirm with Add N. Entries the agent already has are shown ticked and cannot be added twice. When exactly one added tool needs configuration, its configuration sheet opens right away; otherwise the rows carry a “needs configuration” badge until you fill them in.

​

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, including attaching documents from the session files to file fields. 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 are never exposed in the tool schema: uuid (reference fields), calculated fields, fields marked editable: false, and hidden fields. Reserved internal parameter names are also excluded.
5. Files only from the session — a file field takes the name of a file from the conversation’s session files. The platform checks the field’s allowed types, copies the object into the user’s own upload storage (the same shape the upload dialog produces), and stores that key; the knowledge base’s processor and embeddings then run as they do for an upload from the UI. The agent cannot attach a file by URL or by path.

​

Skill author

The Skill author is a built-in tool in the default category. Enabling it lets the agent turn a procedure the user just completed into a skill in the instance’s library, or publish a new version of a skill the user may write. The agent gets four tools: skill_list and skill_read (what exists), skill_create and skill_update. Its configuration has three switches: Create, Update, and Skip approval. A system-prompt block comes with the tool. It tells the agent to offer a skill only after complex, multi-step work that is likely to recur — typically work that produced files, documents, code or a structured analysis, or a multi-step retrieval the user runs regularly — and never for a single question against a knowledge base or a one-off correction, which belongs in memory. Creating or updating a skill shows a card in the chat, like a memory proposal: the user can change the name and the description, sees the files the agent proposes, chooses who may use the skill (private, public, or a scope of users, roles or teams), and — when they may edit the current agent — ticks Enable it on this agent. Nothing is written before they confirm. After a successful create or update the card offers Reload skills, which re-installs the agent’s skills into the live sandbox so the new version is usable in the same conversation; otherwise it loads with the next turn.

​

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