Tool registry

Tools are what the agent acts with. On each turn, the intent classifier picks a subset, and the tool loop lets the model call them until it can answer. This page lists the built-in registry and the tools with behaviour worth knowing. Customizing tools covers removing, replacing and adding them.

The ToolEntry shape

DEFAULT_TOOLS is a flat record of named tools. Each ToolEntry defines what a tool does and how the agent uses 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, options?) => Promise<any>; // never throws — returns { error } instead
6

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

15
    // Loop control
16
    alwaysActive?: boolean;        // Offered every step, whatever the classifier picked
17
    endsTurnOnCall?: boolean;      // Calling it ends the turn
18

19
    // Per-turn scope — see Scope-aware data tools
20
    scopeSchema?: ZodType;         // Shape of `toolScopes[<name>]` the classifier emits
21
    scopePrompt?: string;          // Explains the scope shape to the classifier
22
}

If the entry must be rebuilt per turn, a tool can also be a ToolEntryBuilder, a function from ToolBuildOptions to ToolEntry. Add a scopable custom tool shows one.

Cancellation

execute’s third argument carries the AI SDK’s abortSignal for the call, which fires when the turn is cancelled:

1
type ToolExecuteOptions = { signal?: AbortSignal };

Forward it to every service call your tool makes, so a cancelled turn also cancels the HTTP request. An aborted call rejects with SDKAbortError. Because execute must never throw, catch it and return an error shape:

1
import { SDKAbortError, discoverPlaces } from '@tomtom-org/maps-sdk/services';
2

3
execute: async ({ query }, state, options) => {
4
    try {
5
        const results = await discoverPlaces({ query, signal: options?.signal });
6
        return { count: results.features.length };
7
    } catch (error) {
8
        if (error instanceof SDKAbortError) return { error: 'Cancelled.' };
9
        return { error: `Search failed: ${error instanceof Error ? error.message : String(error)}` };
10
    }
11
},

Do not forward it into work that outlives the turn, such as a monitor’s recurring tick. That work runs after the signal has aborted. A monitor treats a rejected tick as fatal and clears its interval, so a leaked signal stops the monitor.

What’s in the registry

analyseData and processData take JavaScript as a parameter instead of a fixed argument list, as Code generation explains. The Agent Toolkit Plugin API Reference has every tool’s input and output schema.

The help tool

When a user asks “what can you do?” or “show me routing examples”, the model calls help (summary or detail, filtered by tag or query) to surface tool descriptions, example prompts and related tools.

In your own code, getDefaultToolPrompts() returns every tool’s examplePrompts as a Record<ToolName, readonly string[]>. They make starter suggestions for your chat UI that stay in sync with the registry.

Tools that read state vs. fetch data

Some tools fetch fresh data from TomTom services, and others read state. recallState reads and never fetches:

• No arguments - A snapshot of the session, with the places, routes and ranges loaded, entry modes, map style, POIs and traffic.
• { kind } - The index of one kind: places, routes, ranges, geometries, byod, incidents or trafficAreaAnalytics.
• { kind, id } - One entry, summarised.

When a user asks “what were those places?” an hour into a session, the model calls recallState instead of guessing.

Asking the user with clarifyIntent

clarifyIntent asks the user to choose among a few options before the agent acts. It is alwaysActive, so the model can ask mid-task. By default, the model also writes the questions as prose, for UIs without a form. If your UI renders the tool call’s questions as a form, build the tool with rendersForm: true:

1
import { createClarifyIntentTool, createMapAgent } from '@tomtom-org/maps-sdk-plugin-agent-toolkit';
2

3
createMapAgent(map, {
4
    model,
5
    tools: { clarifyIntent: createClarifyIntentTool({ rendersForm: true }) },
6
});

• The turn then ends on the call, with no prose. Render the call’s intro and questions (each with id, question, options and multiSelect), and send the user’s choices as the next message.
• createClarifyIntentTool also overrides description, classificationPrompt, examples, examplePrompts and alwaysActive.

What getCurrentLocation sends

getCurrentLocation asks for the user’s position through the browser’s permission prompt, and returns it to the model. The model provider you configured receives the position with the rest of the conversation. The prompt names only your site, not the model, so tell users in your UI that the position goes to the assistant.

By default, the tool sends only what a “near me” query needs:

To send the exact position, replace the default with createGetCurrentLocationTool:

1
import { createGetCurrentLocationTool, createMapAgent } from '@tomtom-org/maps-sdk-plugin-agent-toolkit';
2

3
createMapAgent(map, {
4
    model,
5
    tools: { getCurrentLocation: createGetCurrentLocationTool({ fullPrecision: true }) },
6
});

To never ask for the position, remove the tool. “Near me” queries then fall back to the map view:

1
createMapAgent(map, { model, tools: { getCurrentLocation: false } });

getTrafficIncidents where schema

getTrafficIncidents takes its area as where: { mode: 'within', … }, with the same multi-region fields as discoverPlaces: viewport, boundingBox, queries, placeIds, geometries, range, route. They resolve to bounding boxes, combined into one of at most 10,000 km². Without where, the tool uses the viewport.

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
});

• A named area wins over viewport: true when the model sends both. Strict-mode providers such as Azure and OpenAI fill every field.
• By default, the tool monitors (monitor) the incidents shown on the map every 60 s (monitorIntervalMs). It fetches only present incidents, unless timeValidityFilter says otherwise.

Related

• Customizing tools — remove, replace or add tools.
• Bring your own data — your GeoJSON as agent layers.
• 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 and tool loop.
• Securing your agent — the caps on tool arguments, and what bounds a turn.