Tool registry

Tools are the unit of action the agent works with. Each turn, the intent classifier selects a subset, and the tool loop lets the model call them until it can answer.

This page is the reference for the built-in registry — what’s in the box, the ToolEntry shape, and a couple of tool-specific quirks worth knowing about. For the how-to topics, follow the links below:

• Customizing tools — remove, replace, or add tools.
• Bring your own data — feed customer-authored GeoJSON into the agent.
• Scope-aware data tools — the analyseData / processData per-turn scope mechanism.
• Code generation — the JavaScript-as-parameter pattern, threat model, and output contract.

The ToolEntry shape

The plugin ships a DEFAULT_TOOLS registry — a flat record of named ToolEntry objects. Each entry defines what the tool does and how the agent should use it:

1
{
2
    description: string;          // Full tool description for the model
3
    inputSchema: ZodType;         // Validated input parameters
4
    outputSchema?: ZodType;       // Structured output (improves reliability)
5
    execute: (input, state) => Promise<any>;
6

7
    // Classifier metadata
8
    classificationPrompt?: string; // One-liner: when to activate this tool
9
    tags?: string[];               // Category labels (e.g. 'route', 'traffic')
10
    examples?: string[];           // Usage examples shown in the help tool
11
    examplePrompts?: string[];     // Natural-language prompts shown in the help tool
12
    relatedTools?: string[];       // Tools often used together
13
    dependsOn?: string[];          // Tools that must run first
14

15
    // Optional: per-turn scope — see Scope-aware data tools
16
    scopeSchema?: ZodType;         // Shape of `toolScopes[<name>]` the classifier emits
17
    scopePrompt?: string;          // Hint for the classifier describing the scope shape
18
}

A tool can also be defined via a ToolEntryBuilder — a function from ToolBuildOptions to ToolEntry — when the entry needs to be rebuilt per turn (e.g. for scope-aware behavior). See Scope-aware data tools / Add a scopable custom tool .

What’s in the registry

Tools are grouped by what they do, not which API they wrap:

analyseData and processData are special — they take JavaScript as a parameter instead of a fixed argument list, and the classifier emits a per-turn scope that narrows their schema to the relevant kinds. See Code generation .

The full API reference (every tool’s signature, input/output schemas, and examples) is in the Agent Toolkit Plugin API Reference .

The help tool

The built-in help tool is available to the model at runtime. When a user asks “what can you do?” or “show me routing examples”, the model calls help to surface tool descriptions, usage examples, and example prompts filtered by tag. Users discover capabilities through natural conversation — no documentation browsing required.

help is also useful as a development surface: call getDefaultToolPrompts() from your own code to get a Record<ToolName, readonly string[]> of every tool’s examplePrompts, and surface them as starter suggestions in your chat UI. The registry stays the single source of truth.

Tools that read state vs. fetch data

A key design distinction: some tools fetch fresh data from TomTom services; others read from plugin state. The recall tools (recallPlaces, recallRoutes, recallRanges, recallByod, recallGeometries, recallState) exist because tool results are not retained in conversation history. If a user asks “what were those places?” an hour into a session, the model calls a recall tool — it does not guess or hallucinate prior results.

See State for the shape of what these tools read from.

getTrafficIncidents where schema

Traffic-incident loading uses a where schema (within mode) instead of a top-level bbox. The same multi-region inputs that discoverPlaces.where.within accepts (viewport, boundingBox, queries, placeIds, geometries, range, route) all resolve to bboxes and are unioned into one bbox for the underlying SDK call (≤ 10,000 km²). Default when where is omitted: { mode: 'within', viewport: true }.

1
// Current viewport
2
getTrafficIncidents({});
3

4
// Named area (geocoded → polygon bbox)
5
getTrafficIncidents({ where: { mode: 'within', queries: [{ query: 'Paris', queryAs: 'place' }] } });
6

7
// Buffered corridor around the latest route
8
getTrafficIncidents({ where: { mode: 'within', route: { widthMeters: 1000 } } });
9

10
// Multi-source union
11
getTrafficIncidents({
12
    where: { mode: 'within', queries: [{ query: 'Amsterdam' }], placeIds: ['G55fc4abe-...'] },
13
});

When the classifier picks getTrafficIncidents with both a meaningful multi-region field and viewport: true (which strict-mode LLM providers like Azure / OpenAI emit by default), the executor prefers the multi-region intent — the tool never silently answers with the viewport when the user named a specific area.

Related

• Customizing tools — how to remove, replace, or add tools.
• Bring your own data — using BYOD layers with the agent.
• Scope-aware data tools — analyseData / processData per-turn scope.
• Code generation — JavaScript-as-parameter tools and their threat model.
• State — what each tool reads from and writes to.
• How it works — the classifier / tool-loop flow.