Menu
The model's tools
The tools exposed to the model are exactly the tasks of the workflow engine. A task's input and output schema is a tool schema: the conversion is mechanical. A task contributed by a plugin becomes callable by the assistant without a single extra line of code.
API
| Call | Returns |
|---|---|
| K.tools.schemas() | The tasks converted to JSON Schema, ready to be offered to the model. |
| K.tools.tache(name) | The task matching a tool name, or null. |
| K.tools.appeler(name, args, ctx) | A promise. It never throws: errors come back inside the result. |
// Error returned TO THE MODEL, not thrown
{ "erreur": "Outil inconnu : core.suprimer" }
An unknown tool, or a call that fails, produces an erreur object passed to the model. The error is returned to the model rather than thrown: it can correct its call on the next turn, where an exception would break the session with no message for the user.
The notice field
The model reads a tool's description at the moment it decides whether to call it, not the system prompt as a whole. A usage instruction placed in the system prompt is frequently ignored; the same instruction inside notice is read at decision time.
notice: "Rend n, moyenne, 2SD, min et max PAR GROUPE, calculés sur la totalité "
+ "des lignes. Ne calcule jamais une statistique toi-même : utilise cette tâche."
Moving the instruction from the system prompt into notice markedly increased the tool-call rate in testing. When the instruction stays in the prompt, the model sometimes answers that it cannot perform an operation for which a tool exists.
No numeric example inside a notice, nor in a parameter label, nor in a system instruction. The model copies them word for word onto unrelated questions: an example value left in a notice comes back in an answer to a user who never typed it. Describe the parameter, never illustrate it.
What the model receives from a result
A tool's result is summarised before being passed on. The model receives the shape; the user sees the substance.
| Recipient | Content |
|---|---|
| The model | Row count, column names and types, statistics, twelve example rows. |
| The user | The full table on screen, sortable and exportable. |
The saving is roughly a factor of nine on tokens consumed. Without it, a single tool call on a slightly wide query would push the model out of its 32k window, and the beginning of the conversation would vanish without warning.
The matching instruction is explicit: the model does not copy the table back out, it comments on it and refers the user to the values already in front of them.
core.graphique
The plotting tool is the most used, and the most closely specified.
| Parameter | Values |
|---|---|
| type | bar, line, scatter, histogram |
| couleur | Continuous gradient on a numeric variable, for instance depth_m, using the OCEAN scale |
| erreurs | Uncertainty columns detected automatically |
| axes | Titles and units taken from the element's metadata |
Duplicate samples are aggregated automatically: one bar per sample, not one bar per analysis, with the 2SD of replicates as the error bar.
Exporting figures
Any figure produced by the assistant or by a workflow exports into the formats a journal expects.
| Format | Detail |
|---|---|
| PNG | 300 dpi, re-rendered rather than upscaled, white background, at journal column widths (90 mm and 180 mm). |
| SVG | A separate render. The fact that this is a second render, not a conversion, is stated explicitly. |
| CSV | UTF-8 BOM and semicolon separator, so it opens directly in Excel on a French-locale machine. |
| LaTeX | Formatted table, ready to drop into a manuscript. |
Document search
The assistant consults the sources declared in the Knowledge panel through a tool call, visible in the thread like any other. It reads nothing outside the enabled sources, and a source with a wrong path shows up as a zero counter rather than as an evasive answer from the model.
Tool documentation, which the model already knows in part, contributes less than the laboratory's wiki and internal procedures. Those are not public and appear in no training corpus.
Inspecting workflows
The assistant can read the automation without touching it. Four read-only tasks let it answer questions about workflows and their runs: core.workflow_liste, core.workflow_detail, core.workflow_passages and core.workflow_simuler. It can say why a workflow failed overnight, or what a workflow would do; it cannot arm, run, or modify one.
In conversation mode the set of tools offered to the model is trimmed. LIMS, alerts and workflow-inspection tools are removed there, because too large a payload overwhelms a smaller model and it stops calling anything at all. The full set is available in agent mode, where the task is explicit.
Adding a tool from a plugin
No AI-specific API is needed. Declaring a task is enough: it appears in the workflow engine and in the model's tool list at the same moment.
K.workflows.declarerTache({
id: 'phreeqc.saturation',
source: 'phreeqc',
title: { fr: 'PHREEQC : indices de saturation',
en: 'PHREEQC: saturation indices' },
notice: "Rend les indices de saturation des minéraux pour une solution. "
+ "Utilise cette tâche plutôt que d'estimer une précipitation.",
entrees: [
{ nom: 'solution', type: 'string', requis: true,
libelle: { fr: 'Solution', en: 'Solution' } },
{ nom: 'mineraux', type: 'array', requis: false, defaut: [],
libelle: { fr: 'Minéraux', en: 'Minerals' } }
],
sorties: [
{ nom: 'si', type: 'object' }
],
executer: function (args, ctx) { /* ... */ }
});
A task declared by a plugin is immediately callable by the model. The tool list is therefore the list of installed tasks: auditing what the assistant can do amounts to auditing the active plugins, in the Kernel inspector, filtered on task.
What no tool does
- No kernel task deletes data.
- No tool exposes fetch, the disk, or direct database access.
- The model computes no statistic: they all go through core.resume or core.analyses.