22. AI Tools

• 22.1 LLM
• 22.2 MCP Server
• 22.3 MCP Client
• 22.4 Agents
• 22.5 Kitt Assistant
• 22.6 Examples

22.1 LLM

The LLM section of the settings allows you to register the Large Language Models (LLMs) that vtenext can use for AI agents and other AI-powered features. Here, you can define the model's connection details, assign it a name for identification, and configure parameters that influence the model's response behavior.

vtenext does not include a built-in AI model within the CRM. To configure an LLM, you must have either a remote model accessible through OpenAI-compatible APIs or a locally installed model that is reachable by the system. In other words, this configuration is used to connect vtenext to an external or local AI service—the model itself is not built into the CRM.

The List View

The list displays all previously saved configurations. For each entry, you can view:

• Active or inactive status
  
• Configuration name
  
• Service URL
  
• Model used

From the list, you can create a new configuration, edit an existing entry, delete it, or quickly enable and disable it.

Creating a new LLM

1. Open the LLM section.
   
2. Click Add.
   
3. Fill in the required fields.
   
4. If necessary, run a configuration test.
   
5. Save.

Active	makes the model available for use
Name	descriptive name of the model displayed in vtenext. Required field
URL	API endpoint to which vtenext sends requests to the model (for example, https://api.openai.com/v1/chat/completions). Required field
Model	identifier of the model to be used (for example, gpt-5.2). Required field
Base URL	the base address of the service hosting the model. In practice, it tells AI agents and the Python orchestrator where the model service is located. It becomes particularly important when using a local model or an internal service within the infrastructure, for example an endpoint such as http://127.0.0.1:11434
Provider	indicates to vtenext and the Python orchestrator what type of service is behind the model, such as OpenAI or Ollama
API Key	authentication key provided by the provider, required to authorize API requests
Temperature	controls the level of randomness in generated responses. Lower values (for example, 0.2) produce more consistent, predictable, and repeatable responses; higher values (for example, 0.8 or above) encourage more varied and creative responses
Maximum Tokens	defines the maximum total number of tokens that the model can use to process the request, including both the messages sent and the generated response (if supported by the provider)
Maximum Completion Tokens	limits the maximum number of tokens that the model can use exclusively for the generated response
Developer Message	instructions addressed to the model with the developer role, used to define behavioral rules or application constraints
System Message	general instructions that define the model’s behavior during the conversation
User Message	test message sent to the model to verify its operation. Required field

How the test works

The TEST button sends an actual request to the model using the configured parameters and displays:

• Operation result
  
• Response code
  
• Returned headers
  
• Full response body

Call Result: RESULT tab

Call Result: HEADERS tab

Call Result: RESPONSE tab

The test is used to verify the configuration, but it does not replace saving the configuration.

The test sends an actual request to the remote or local model. If the model cannot be reached via API, the test cannot be performed.

Practical examples

Example 1: OpenAI-compatible model

Use this configuration when the model is available as a remote service through an external API. Set the name, URL, model, and API Key, then send a simple test message.

Example 2: Local model

If the model runs locally or on an internal infrastructure, also fill in the Base URL and Provider fields. In this case as well, the model must already be installed, active, and reachable over the network.

22.2 MCP Server

The MCP Servers section allows you to publish, through vtenext, an MCP endpoint that makes CRM tools and operations available to compatible external clients. In practice, this section is used to define which MCP server to expose and which tools to publish through it.

In summary: an MCP server is not an AI model and does not replace an AI agent. It is an access point that securely exposes CRM functions, allowing compatible MCP clients to invoke them from external applications.

When to use it

• To expose CRM tools to external MCP-compatible clients.
• To precisely select which operations should be made available.
• To create a stable internal endpoint for use in AI integrations.
• To generate, if required, an MCP client connected to the same server.
  

The List View

The list displays all previously configured MCP servers.

Active	indicates whether the server is enabled and publicly available
Endpoint	identifier of the published server
Description	descriptive text for the server
Published Tools	number of tools made available through the server
MCP	associated MCP client, if any, including its synchronization status

From the list, you can create a new server, edit an existing one, delete it, or copy its full URL.

Creating a New MCP Server

1. Open the MCP Servers section.
2. Click Add.
3. Check the Base URL displayed by the system and verify that it is accessible from outside the network.
4. Enter the Endpoint name.
5. Add a Description, if needed.
6. Choose whether to also create the associated MCP client.
7. Select the tools to publish.
8. Save the configuration.
   

Configuration Parameters

Active	makes the server available for use
Base URL	initial part of the server address ($site_URL), displayed as read-only. It is automatically generated by the system
Endpoint	final identifier of the server. It is the part that completes the public URL of the MCP server. It must be unique and may contain letters, numbers, underscores, and hyphens
Description	used to explain the purpose of the server to administrators or users responsible for maintaining it
Create MCP Client	automatically creates an MCP client pointing to this server. The connection is kept synchronized and, if the server is deleted, the associated client is also removed

Published Tools Selection

After the main fields, the screen displays the section dedicated to the published tools.

The available tools can come from multiple areas of the system, for example:

• Base Tools
• SDK Tools (see MCP Server for further details)
• Processes

You can select them by group or quickly search for them using the search field. Some basic tools are automatically maintained by the system, even if they are not manually selected, to ensure the correct operation of the integration.

Practical examples

Example 1: MCP server for internal CRM tools

You can create a server dedicated to a limited set of tools, for example only those required by an internal assistant or a controlled integration.

Example 2: MCP server with connected client

If you want the server to be immediately usable from the client side as well, you can enable the Create MCP Client option. In this way, vtenext automatically prepares the client that connects to that server.

Example 3: Selective tool publishing

If you do not want to expose all available functions, you can publish only the tools that are actually required. This approach helps keep the integration more organized and controlled.

22.3 MCP Client

The MCP Clients section is used to connect vtenext to an external or internal MCP server, allowing it to retrieve and use the available tools within processes and agents. In practice, this section is where you configure how to reach the MCP server, how to authenticate, and how to keep the list of available tools up to date.

In summary: the MCP client does not publish functions externally. It performs the opposite operation: it connects to an MCP server, retrieves its tools, and makes them available within vtenext.

When to use it

• To connect vtenext to an already available MCP server.
• To use the tools exposed by an MCP server within processes and agents (see AI Actions).
• To keep the list of available tools synchronized over time.
• To quickly connect an MCP server created in the MCP Servers section.

The List View

The list displays all previously configured MCP clients.

Active	indicates whether the client is enabled
Name	internal name used to identify the connection
URL	address of the MCP server to which the client connects
Last Synchronization	shows when the tools were last synchronized, or indicates that the client has never been synchronized

From the list, you can create a new client, edit it, or delete it. If the client is connected to an internal MCP Server, you can also directly open that server from the list.

Creating a New MCP Client

1. Open the MCP Clients section.
2. Click Add.
3. Enter an easily recognizable Name.
4. Enter the URL of the MCP server.
5. Choose the Authentication type.
6. Fill in the required credentials, if applicable.
7. Decide whether to enable Periodic Synchronization.
8. Enable Notifications if you want to be notified when tools change.
9. Save the configuration.
   

Important: when saving, vtenext actually attempts to connect to the MCP server. If the connection fails, the configuration is not accepted.

Configuration Parameters

Active	enables or disables the client
Name	descriptive name of the connection
URL	full address of the MCP server to connect to
Authentication	defines how the client authenticates with the MCP server
Username and Password	displayed when Basic Authentication is selected
API Key	displayed when Bearer or X-API-Key authentication is selected
Synchronize	allows a cron job to periodically check the available tools and update them when new ones are detected
Notification	sends a notification when synchronization detects changes in the server's tools

How authentication works

The selected authentication method changes the fields displayed in the configuration form.

No Authentication	no additional credentials are required
Basic	you must enter a username and password
Bearer	you must enter a token or API key
X-API-Key	you must enter the API key in the dedicated field
VTE (Access Key)	vtenext automatically uses the dedicated MCP access key of the user performing the call. No credentials need to be entered manually

When to use VTE (Access Key): this option is particularly useful when the client points to an MCP Server exposed by vtenext, because it allows the system to manage authentication automatically.

Connection Verification and Tool Mapping

Call Result: RESULT

Call Result: HEADERS

Call Result: RESPONSE

• The test button checks whether the MCP server responds correctly.
• If the result is successful, vtenext can retrieve the list of available tools.
• From the verification window, you can update the available tools section using the Map Available Tools command.

This verification is especially useful when configuring a new server or when you want to check that authentication is working correctly before the final save.

Available Tools

After saving, or after mapping from the verification window, vtenext displays the list of tools retrieved from the MCP server.

For each tool, you can view:

• tool name
• description
• input parameters
• required and optional fields
• structure of the returned output

This information is stored locally, so the tools can then be invoked within agents and processes without having to reinterpret the remote server structure each time.

Periodic Synchronization

If you enable Synchronize, a scheduled process can periodically check whether new or modified tools are available on the MCP server.

• If changes are detected, the local tool configuration is updated.
• If no differences are found, the date of the last synchronization is updated anyway.
• If you have also enabled Notification, you will receive an alert when the set of tools changes.

Warning: when tools change on the MCP server, it may be necessary to check any processes or agents that use them, especially if parameters or outputs have changed.

Practical examples

Example 1: Connecting to an external MCP server

You can configure an MCP client that points to an external server published by another system. In this case, enter the URL, the required authentication method, and then verify the available tools.

Example 2: Connecting to a vtenext MCP Server

If you have already created an MCP Server in the relevant section, you can connect the client to the same endpoint and use VTE (Access Key) authentication to simplify the configuration.

Example 3: Controlled tool updates

If the tools on the remote server may change over time, it is recommended to enable periodic synchronization and, if necessary, notifications as well, so that processes and agents remain aligned.

Web Search MCP - Exa

vtenext also provides a preconfigured MCP client called Web Search MCP - Exa. This entry is created automatically but remains disabled until you decide to use it.

Exa is a web search service designed for AI agents. It allows real-time web searches, retrieval of content from specific web pages, and provides models with more up-to-date information compared to the knowledge already embedded within the model.

How to activate it

1. Open the Web Search MCP - Exa entry in the MCP Clients list.
2. Leave the preconfigured URL unchanged, as it points to Exa’s public MCP server.
3. Set or complete the X-API-Key authentication with the API key from your Exa account.
4. Enable the client.
5. Save and verify the available tools.
   

In this case, the authentication method expected by vtenext is X-API-Key, which is already selected in the initial client configuration.

Available Tools with Exa

The MCP server exposes the following tools:

• web_search_exa: performs web searches and returns content already prepared for use by the agent.
• web_fetch_exa: retrieves the full content of a web page starting from a known URL.

When it can be useful: Exa is particularly suitable when you want to provide agents and processes with access to up-to-date web searches, online page analysis, or the rapid collection of external information.

For further details about the service and the features of the Exa MCP server, refer to the official website: https://exa.ai/mcp.

22.4 Agents

The Agents section allows you to configure AI agents that combine an LLM model, one or more MCP tools, and, if required, CRM documents to use as a knowledge base. In practice, this is where you define how the agent reasons, which tools it can use, and which content it can access to perform a task.

In summary: an agent is not just an AI model. It is a complete configuration that combines an LLM, operational tools, and document sources, allowing it to perform tasks in a more controlled and context-aware way within vtenext.

Prerequisite: Agent Orchestrator

To use agents, the Agent Orchestrator service must be installed and reachable. In the Agents list view, there is a dedicated section where you can specify the Orchestrator Endpoint, which is the base URL of the service.

Important: if the orchestrator endpoint is not configured correctly, agents cannot be executed.

When to use it

• To configure AI agents to be used in the assistant or within processes.
• To associate a specific LLM with an agent.
• To provide the agent with access to selected MCP tools.
• To enable RAG capabilities by selecting CRM documents as knowledge sources.
• To apply control rules before and after response generation (guardrails).
  

The List View

The list displays all previously configured agents.

• Active: indicates whether the agent is enabled.
  
• Name: name of the agent.
  
• Description: text explaining the purpose of the agent.
  
• LLM: shows the associated model.
  
• Documents: indicates whether the agent has access to RAG documents.

From the list, you can create a new agent, edit it, or delete it.

Creating a New Agent

1. Open the Agents section.
2. Click Add.
3. Enable or disable the agent according to your needs.
4. Enter the Name and Description.
5. Select the LLM to use.
6. Decide whether to keep the LLM system prompt or override it for this specific agent.
7. Select the tools the agent will be able to use.
8. If necessary, enable the RAG capability and select the documents.
9. Configure any guardrails.
10. Save the configuration.
    

Main Fields

• Active: enables or disables the agent.
  
• Name: internal name used to identify the agent.
  
• Description: brief internal description summarizing the agent’s purpose.
  
• LLM: language model used by the agent.
  
• LLM System Prompt: displays the system prompt currently configured for the selected model.
  
• Override System Prompt: when enabled, the agent uses a specific system prompt instead of the LLM’s default one.
  
• System Prompt: agent-specific instructions, visible only when choosing to override the model’s prompt.

When to use system prompt override: it is useful when you want to keep the same LLM but significantly change the behavior, tone, or responsibilities of a specific agent.

Available Tools for the Agent

The tools are displayed by groups, based on the active MCP clients and the available internal tools.

• Kitt Tools: includes basic internal tools such as calculator and user_manual.

   

• MCP Clients: for each active MCP client, you can select the synchronized and available tools.

For each group, you can select all tools or quickly deselect them. A search function is also available to filter tools by name or description.

Warning: the agent can only use the tools selected in this section. If an MCP client is not configured or has no synchronized tools, it will not appear as an available source.

RAG Capability and Documents

If you want the agent to also work with CRM content, you can enable the RAG capability.

• RAG Capability: enables the use of documents as knowledge sources.

   

• Select: opens the document selector to add CRM files.

• Document Table: displays the title, file, owner, and document folder of the documents already associated.

When to use RAG: it is useful when the agent needs to answer questions or perform tasks based on documentation, files, or company content stored in the CRM, rather than relying only on generic instructions.

Guardrail

The Agents section also allows you to define checks before and after response generation.

• Static Pre-Guardrail: blocks inputs containing prohibited words or expressions.

• LLM Pre-Guardrail: uses an LLM to evaluate the input before processing.

• Pre-Guardrail Prompt: defines the instructions used by the control mechanism to evaluate the input.

• Static Post-Guardrail: blocks outputs containing prohibited content.

• LLM Post-Guardrail: uses an LLM to evaluate the response before returning it.

• Post-Guardrail Prompt: defines the instructions for the final validation step.

Static rules can include plain text or regular expressions, one per line.

Warning: LLM-based guardrails can increase token consumption and response times, as they add additional verification steps.

Practical examples

Example 1: Agent with operational tools

You can create an agent that uses an LLM and selected MCP tools to query data, perform permitted actions, or access external services such as web search.

Example 2: Document-based agent

You can create an agent focused on internal documents by enabling RAG and selecting only the files relevant to a specific department or process.

Example 3: Agent with enhanced controls

22.5 Kitt Assistant

The Assistant section allows you to define how the vtenext Kitt Assistant should generate its responses. In practice, this is where you choose which response engine to use: a direct LLM, a preconfigured agent, or a custom REST Web Service.

In summary: the assistant is the access point through which the user interacts. Depending on the configuration, it can respond directly using a model, use advanced tools through an agent, or delegate the response to an external service.

Prerequisites

• To use an LLM, you must first configure at least one model in the LLM section.
• To use an Agent, you must first configure at least one agent in the Agents section.
• To use a REST Web Service, you must first configure the service in the relevant section.
• For the assistant to work correctly, the background task worker must be enabled.
  

Creating or Editing the Assistant

1. Open the Assistant section.
2. Enable or disable the configuration.
3. Select the Assistant Type.
4. Fill in the field displayed based on the selected type.
5. Save the configuration.
   

Type: Agent

If you select Agent, the assistant will use one of the agents already configured in vtenext.

• Select an agent from the available list.
• The assistant inherits the capabilities of the selected agent.
• This includes, if configured in the agent, MCP tools, RAG documents, specific prompts, and guardrails.
  

When to use an agent: it is the right choice when you want the assistant to do more than provide a simple text response, for example by using tools, consulting documents, or applying more advanced controls.

Type: LLM

• Select the LLM model to use.
• You can view the currently configured LLM system prompt.
• You can enable the Override system prompt option to use a custom prompt specifically for the assistant.
  

This mode is simpler than using an agent because it does not involve MCP tools or RAG documents.

Overriding the System Prompt

When the assistant is configured in LLM mode, you can decide whether to keep the model’s system prompt or replace it.

• LLM System Prompt: displays the standard prompt already configured for the selected model.

• Override System Prompt: if enabled, the assistant uses the text specified in the assistant configuration.

• System Prompt: field where you define dedicated instructions for the assistant.

When it is useful: overriding the system prompt is useful when you want to keep the same model but change the assistant’s tone, purpose, or behavior compared to other configurations that use the same LLM.

Type: REST Web Service

If you select REST Web Service, the assistant delegates the response generation to an external REST service that has already been configured.

• Select a custom REST Web Service from the list.
• The user's message must be passed in the raw request body using the $content placeholder.
• The expected response must be mapped to the returned message field.
  

Limitation: in this mode, streaming and conversational memory are not supported.

This option is useful when you want to connect the assistant to an existing external system or to a custom AI service that is not managed directly as an LLM or agent within vtenext.

Practical examples

Example 1: LLM-only assistant

You can configure a lightweight assistant that uses an LLM directly to answer general questions, without additional tools or documents.

Example 2: Agent-based assistant

You can use an agent when you want the assistant to have access to web search, company documents, or CRM operational tools.

Example 3: Assistant with an external service

You can connect a custom REST Web Service if your workflow relies on an external response engine or business logic already developed outside of vtenext.

22.6 Examples

Below are some example requests to demonstrate the assistant’s capabilities.

---

Creating an Account

I can create any record managed by the CRM, such as an account in this case. Any tools used by the assistant are displayed, and for write operations, approval is requested before proceeding.

   

The account is created by triggering any configured processes. In this example, the active process performs web scraping to enrich the information in the company record.

---

Ticket Response Rewording

In this example, I need to reply to a ticket where the customer reported login issues. I can create a draft response by typing it directly into the Add Comment field.
By clicking on that field, the content is added to Kitt’s context and the Process Text quick action becomes available.

   

The response will include an Apply button, which allows you to replace the text in the field used as context with the processed text. You can then proceed to send the message.

---

From Ticket to FAQ

Using the ticket from the previous example, I ask the assistant to write a solution based on the comments and then create an FAQ.

   

---

Sending an Email

If the assistant uses an agent, all active tools can be used directly within the chat. For example, you can configure a process tool for sending emails and then ask the assistant to send an email.

The process will be configured as shown, and once activated, make sure that the tool is enabled in the agent.