Ollama Register Tools activity in Jitterbit Studio
Introduction
An Ollama Register Tools activity, using its Ollama connection, registers tools with the specified Ollama model and is intended to be used as a source to provide data in an operation. Tool definitions can be sourced from the MCP Client connector's List Tools activity or provided directly through the request transformation as custom tool definitions.
When the operation runs, Jitterbit stores the registered tool definitions in memory on the private agent, associated with the chat ID. Any operation chained to run after this one that uses the same chat ID automatically has access to those tools when it calls the model. You do not need to pass the tool definitions explicitly to the subsequent Prompt operation. If a tool with the same name is already registered for the chat ID, the new definition replaces it. The stored tools and conversation history are cleared when the agent restarts.
Important
To use the Register Tools activity, you must use a private agent.
Create an Ollama Register Tools activity
An instance of an Ollama Register Tools activity is created from an Ollama connection using its Register Tools activity type.
To create an instance of an activity, drag the activity type to the design canvas or copy the activity type and paste it on the design canvas. For details, see Creating an activity instance in Component reuse.
An existing Ollama Register Tools activity can be edited from these locations:
- The design canvas (see Component actions menu in Design canvas).
- The project pane's Components tab (see Component actions menu in Project pane Components tab).
Configure an Ollama Register Tools activity
Follow these steps to configure an Ollama Register Tools activity:
-
Step 1: Enter a name and specify settings
Provide a name for the activity, select a model, and specify a prompt and optional settings. -
Step 2: Review the data schemas
Any request or response schemas are displayed.
Step 1: Enter a name and specify settings
In this step, provide a name for the activity, select a model, and specify a prompt and optional settings. Each user interface element of this step is described below.
Tip
Fields with a variable icon support using global variables, project variables, and Jitterbit variables. Begin either by typing an open square bracket [ into the field or by clicking the variable icon to display a menu listing existing variables to choose from.
-
Endpoint menu: If you have multiple endpoints of the same connector type configured, a menu at the top of the screen displays the current endpoint name. Click the menu to switch to a different endpoint. For more information, see Change the assigned endpoint in Configuration screens.
- Edit endpoint: Appears when you hover over the current endpoint name. Click to edit the currently selected endpoint's connection configuration.
-
Name: Enter a name to identify the activity. The name must be unique for each Ollama Register Tools activity and must not contain forward slashes
/or colons:. -
Chat ID: Enter a chat ID to retrieve context from a previous conversation. If empty and not provided in the request transformation, a new chat ID is generated and provided in the activity response.
-
Choose option: Specify the model selection method, either List all models or Enter model identifier.
-
List all models: Select this option to choose from a list of models retrieved from the Ollama endpoint:
-
Select a model: This section displays models available in the Ollama endpoint. Only models that support tool calling are listed. DeepSeek models are excluded from the list.
-
Selected model: After a model is selected, it is listed here.
-
Search: Enter any column's value into the search box to filter the list of models. The search is not case-sensitive. If models are already displayed within the table, the table results are filtered in real time with each keystroke. To reload models from the endpoint when searching, enter search criteria and then refresh, as described below.
-
Refresh: Click the refresh icon or the word Refresh to reload models from the Ollama endpoint. This may be useful if models have been pulled to a self-hosted Ollama server. This action refreshes all metadata used to build the table of models displayed in the configuration.
-
Selecting a model: Within the table, click anywhere on a row to select a model. Only one model can be selected. The information available for each model is fetched from the Ollama endpoint:
-
Display Name: The name of the model.
-
ID: The ID of the model used in API requests, including its tag (for example,
llama3.2:latest). -
Modified: The date and time the model was last modified.
-
Tip
If the table does not populate with available models, the Ollama connection may not be successful. Ensure you are connected by reopening the connection and retesting the credentials. For a self-hosted Ollama server, also confirm that at least one model has been pulled to the server.
Alternatively, the model can be specified in the Model ID field or provided in the request transformation. If a model is specified in multiple places, this order of precedence is followed:
- A model provided in the request transformation overrides all fields below.
- A model specified in the Model ID field overrides the remaining field below, even if List all models is selected.
- A model selected in the Select a model list has the least precedence.
-
-
-
Enter model identifier: Select this option to manually enter the ID of a model:
- Model ID: Enter the model ID (for example,
llama3.2). For Ollama Cloud, use a model name listed in Ollama's cloud models. For a self-hosted server, the model must already be pulled to the server.
- Model ID: Enter the model ID (for example,
-
Prompt: Optionally, enter a prompt to send to the model after the tools are registered. If a prompt is provided, the model can respond with tool calls, which are returned in the
toolCallsfield of the activity response. -
Optional settings: Click to expand additional optional settings:
-
Enable thinking (reasoning models): Select to enable thinking, which allows a reasoning model to reason through a problem before generating a response. The model's reasoning is returned in the
thinkingfield of the response. This option is disabled by default. When this option is cleared, thinking is turned off, including for models that otherwise reason by default.Note
Thinking is supported only by reasoning models. Refer to the Ollama thinking documentation to confirm whether the selected model supports thinking.
-
Keep model loaded: Select how long the model stays loaded in memory after the request completes (see How do I keep a model loaded in memory or make it unload immediately?). Keeping a model loaded avoids load time on subsequent requests but continues to use memory on the Ollama server:
- 5 minutes: (Default.) Keeps the model loaded for 5 minutes.
- 30 minutes: Keeps the model loaded for 30 minutes.
- 1 hour: Keeps the model loaded for 1 hour.
- Keep loaded indefinitely: Keeps the model loaded until the Ollama server is restarted or the model is unloaded.
- Unload after each call: Unloads the model immediately after the response is returned.
-
Randomness and diversity:
- Temperature: Enter a temperature parameter. Higher values produce more varied responses, and lower values produce more deterministic responses. This parameter's value can range between
0and2, for example:0.8. - Top P: Enter a Top P parameter for nucleus sampling, which restricts token selection to the smallest set of tokens whose cumulative probability reaches this value. This parameter's value can range between
0and1, for example:0.9. - Top K: Enter a Top K parameter, which restricts token selection to the specified number of highest-probability tokens, for example:
40. - Seed: Enter a seed parameter. Using the same seed value with the same prompt reproduces the same output. Leave this field empty for nondeterministic output.
When a field in this group is empty, the model's default value is used.
- Temperature: Enter a temperature parameter. Higher values produce more varied responses, and lower values produce more deterministic responses. This parameter's value can range between
-
Context and length:
- Context Window: Enter the size of the context window in tokens, which limits the combined length of the prompt, the conversation history, and the generated output. The default is
4096. The maximum value depends on the selected model and the memory available on the Ollama server (see How can I specify the context window size?). - Max Output Tokens: Enter the maximum number of tokens to generate in the response. The default is
2000. Enter-1to generate without a limit.
- Context Window: Enter the size of the context window in tokens, which limits the combined length of the prompt, the conversation history, and the generated output. The default is
-
Continue on error: Select to return a response with error details instead of failing the activity when an error occurs. The error is written to the operation log and returned in the
errorsarray of the activity response.
-
-
Save & Exit: If enabled, click to save the configuration for this step and close the activity configuration.
-
Next: Click to temporarily store the configuration for this step and continue to the next step. The configuration will not be saved until you click the Finished button on the last step.
-
Discard changes: After making changes, click to close the configuration without saving changes made to any step. A message asks you to confirm that you want to discard changes.
Step 2: Review the data schemas
Any request or response schemas are displayed. Each user interface element of this step is described below.
-
Data schema: These data schemas are inherited by adjacent transformations and are displayed again during transformation mapping.
Note
Data supplied in a transformation takes precedence over the activity configuration.
In the request schema, each item in the
toolsarray defines one tool with aname, adescription, and anargumentsarray. Each argument has aname, atype, adescription, and anisRequiredflag. Thenameanddescriptionfields are required for both a tool and its arguments.The Ollama connector uses the Ollama API. Refer to the chat endpoint documentation for information on the schema nodes and fields.
-
Refresh: Click the refresh icon or the word Refresh to regenerate schemas from the Ollama endpoint. This action also regenerates a schema in other locations throughout the project where the same schema is referenced, such as in an adjacent transformation.
-
Back: Click to temporarily store the configuration for this step and return to the previous step.
-
Finished: Click to save the configuration for all steps and close the activity configuration.
-
Discard changes: After making changes, click to close the configuration without saving changes made to any step. A message asks you to confirm that you want to discard changes.
Next steps
After configuring an Ollama Register Tools activity, complete the configuration of the operation by adding and configuring other activities, transformations, or scripts as operation steps. You can also configure the operation settings, which include the ability to chain operations together that are in the same or different workflows.
To complete a tool-calling workflow, chain a Prompt operation to run after this one. Because Jitterbit stores the tool definitions in memory on the private agent, the Prompt operation receives them automatically with no additional mapping required. To link the Prompt operation to this conversation, configure it with the same chat ID, or capture the chatId from the Register Tools response and pass it to the Prompt activity in the request transformation.
Menu actions for an activity are accessible from the project pane and the design canvas. For details, see Activity actions menu in Connector basics.
Ollama Register Tools activities can be used as a source with these operation patterns:
- Transformation pattern
- Two-target archive pattern (as the first source only)
- Two-target HTTP archive pattern (as the first source only)
- Two-transformation pattern (as the first or second source)
To use the activity with scripting functions, write the data to a temporary location and then use that temporary location in the scripting function.
When ready, deploy and run the operation and validate behavior by checking the operation logs.