🚀 Chatvolt MCP Server: High-Level Overview
This document offers a high - level overview of the Chatvolt Model Context Protocol (MCP) server. It's a TypeScript - based application crafted to expand the capabilities of AI agents. It equips them with a set of tools to interact with the Chatvolt platform.
✨ Features
Project Goal
The project's main objective is to serve as a bridge between an AI model and the Chatvolt API. It exposes a collection of tools that an AI agent can invoke to carry out actions such as managing agents, querying datastores, and handling CRM scenarios. This enables the automation of complex workflows and provides a natural - language interface to the Chatvolt platform.
Key Technologies
- Node.js: The runtime environment for the server.
- TypeScript: The primary programming language, offering static typing and modern JavaScript features.
- @modelcontextprotocol/sdk: The core SDK for building MCP servers, which simplifies the process of defining tools, resources, and handling requests from an AI model.
Main Components
The heart of the application is the MCP server, which is responsible for:
- Initializing the Server: Configuring the server with its name, version, and capabilities.
- Handling Requests: Implementing handlers for various MCP request types, including
ListTools
, CallTool
, ListResources
, and GetPrompt
.
- Tool Dispatching: Receiving
CallTool
requests and routing them to the appropriate tool handler.
Tools are the actions that an AI agent can perform. They are defined in the src/tools/
directory and are broadly classified into:
- Agent Management: Tools for creating, updating, deleting, and listing Chatvolt agents.
- CRM Management: Tools for managing CRM scenarios and steps.
- Datastore Management: Tools for interacting with datastores and datasources.
3. Resources and Prompts
The server provides additional context to the AI model through resources and prompts:
TOOL_DESCRIPTIONS.md
: A markdown file that offers detailed descriptions of all available tools and their parameters.
MODELS.md
: A list of the AI models that can be used with the agents.
SYSTEM_PROMPTS.md
: Contains system - level instructions that guide the AI agent.
📦 Installation
Client Configuration
This MCP server is launched via a command from the client. To connect, you need to configure your client to launch the chatvolt - mcp
command and pass the necessary environment variables.
Here is an example of how you might configure your client's mcpServers
setting:
{
"mcpServers": {
"chatvolt - mcp": {
"command": "npx",
"args": [
"chatvolt - mcp"
],
"env": {
"CHATVOLT_API_KEY": "{your_token}"
}
}
}
}
⚠️ Important Note
You must replace "{your_token}"
with your actual Chatvolt API key.
📚 Documentation
Chatvolt MCP Server: Detailed Architecture
This document provides a detailed technical architecture of the Chatvolt Model Context Protocol (MCP) server. It elaborates on the high - level overview, covering the request lifecycle, directory structure, and the process of defining and registering tools.
1. Request Lifecycle: CallTool
The CallTool
request is the primary means by which an AI agent executes an action. The lifecycle of this request is as follows:
sequenceDiagram
participant AI Agent
participant MCP Server
participant Tool Handler
participant Chatvolt API
AI Agent->>+MCP Server: Sends CallToolRequest (e.g., 'delete_agent', {id: '123'})
MCP Server->>MCP Server: Receives request in CallTool handler
Note over MCP Server: Finds handler for 'delete_agent' in `toolHandlers` map
MCP Server->>+Tool Handler: Invokes handleDeleteAgent(request)
Tool Handler->>Tool Handler: Validates arguments (e.g., checks for 'id')
Tool Handler->>+Chatvolt API: Calls `deleteAgent('123')`
Chatvolt API-->>-Tool Handler: Returns result (e.g., {success: true})
Tool Handler-->>-MCP Server: Returns formatted content
MCP Server-->>-AI Agent: Sends response with tool output
Flow Description:
- Request Reception: The MCP server receives a
CallToolRequest
. This request is handled by the generic CallToolRequestSchema
handler defined in src/server.ts
.
- Handler Dispatching: The server looks up the specific tool handler from the
toolHandlers
object, which maps tool names (e.g., "delete_agent"
) to their corresponding handler functions (e.g., handleDeleteAgent
). This object is imported from the central src/tools/
index file.
- Tool Execution: The matched handler function is executed. For example,
handleDeleteAgent
in src/tools/deleteAgent.ts
is called.
- Business Logic: The tool handler extracts the necessary arguments from the request, validates them, and then calls the relevant function from the
src/services/
layer (e.g., deleteAgent(id)
).
- API Interaction: The service function is responsible for making the actual API call to the Chatvolt platform.
- Response Formatting: The tool handler receives the data back from the service, stringifies it (in this case, as a JSON), and wraps it in the format expected by the MCP SDK.
- Response Transmission: The server sends the final, formatted content back to the AI agent that initiated the call.
2. Directory Structure
The project is organized to separate concerns, making it modular and maintainable.
src/
: This is the root directory for all application source code.
src/tools/
: This directory contains the implementation for each tool the server exposes.
- Structure: Each tool typically has its own file (e.g.,
deleteAgent.ts
).
- Contents: Each file exports two main constructs:
- A
Tool
definition object (e.g., deleteAgentTool
) that contains the tool's name
, description
, and inputSchema
as required by the MCP SDK.
- A handler function (e.g.,
handleDeleteAgent
) that contains the logic for executing the tool.
- Aggregation: A central
index.js
file within this directory is responsible for importing all individual tools and handlers and exporting them as two aggregate objects: tools
(an array of all tool definitions) and toolHandlers
(a map of tool names to their handlers).
src/services/
: This directory is intended to house the business logic and API client code that interacts with external services, primarily the Chatvolt API.
- Purpose: It acts as a bridge between the tool handlers and the underlying platform. This separation ensures that tool handlers are only responsible for request/response handling and argument validation, while the services layer manages the specifics of API communication.
- Example: The
deleteAgent
function, imported from ../services/chatvolt.js
, would contain the fetch
call and logic required to send a DELETE
request to the Chatvolt /agents/:id
endpoint.
3. Tool Definition and Registration
Tools are the core components that define the server's capabilities. Their definition and registration follow a clear pattern:
- Tool Definition: Each tool is defined as a constant object of type
Tool
from the @modelcontextprotocol/sdk/types.js
library. This object includes:
name
: A unique, machine - readable name for the tool (e.g., "delete_agent"
).
description
: A human - readable description of what the tool does and its parameters. While a resource file like TOOL_DESCRIPTIONS.md
exists to provide detailed documentation to the AI model, the description
property within the tool definition itself serves as a concise summary.
inputSchema
: A JSON Schema object that formally defines the arguments the tool accepts, including their types and whether they are required.
- Tool Registration: The server discovers and registers tools through the following process:
- The
tools
array and toolHandlers
map are imported from src/tools/index.js
into src/server.ts
.
- The
ListToolsRequestSchema
handler in src/server.ts
uses the imported tools
array to respond to requests for the list of available tools.
- The
CallToolRequestSchema
handler uses the toolHandlers
map to find and execute the correct function based on the name
parameter in the incoming request.
This architecture creates a decoupled system where new tools can be easily added by creating a new file in the src/tools/
directory and updating the central index.js
file, without modifying the core server logic in src/server.ts
.
System Prompts Documentation
This document explains the role and content of system prompts used to guide the AI agent's behavior when interacting with the Chatvolt MCP (Model Context Protocol). These prompts are defined in the SYSTEM_PROMPTS.md
file and provide a foundational set of instructions for the AI.
Purpose of System Prompts
System prompts are high - level instructions that define the AI's persona, objectives, and operational constraints. They ensure the AI acts in a predictable and effective manner by establishing a clear framework for how it should interpret user requests, utilize its tools, and structure its responses.
Key Instructions and Scenarios
The SYSTEM_PROMPTS.md
file outlines three primary scenarios, each with a corresponding system prompt to guide the AI's behavior.
1. Simple Tool Operation
- Purpose: To handle straightforward user requests that can be fulfilled by a single tool call.
- AI Persona: An expert AI assistant for the Chatvolt platform.
- Core Instructions:
- Identify the user's intent.
- Select the single, most appropriate tool (e.g.,
list_agents
).
- Execute the tool with the correct parameters.
- Report the outcome to the user.
2. Complex, Multi - Step Workflow
- Purpose: To manage complex tasks that require a sequence of tool calls to achieve a larger goal.
- AI Persona: A senior AI automation engineer responsible for orchestrating workflows.
- Core Instructions:
- Deconstruct: Break down the user's request into smaller, sequential steps.
- Plan: Create a step - by - step plan, identifying the right tool for each step.
- Execute: Call the tools sequentially, waiting for each one to complete successfully before proceeding to the next. The output of one tool can be used as input for another.
- Synthesize: Provide a final summary of all actions taken and the result.
3. Self - Discovery and Learning
- Purpose: To enable the AI to be resourceful and learn about its own capabilities before executing a task.
- AI Persona: A highly autonomous and proactive AI agent.
- Core Instructions:
- Self - Discovery First: Before attempting a complex task, the AI must first call the
getDocumentation
tool to retrieve information about all its available tools.
- Analyze: Review the documentation to understand its capabilities.
- Plan: Formulate a plan based on the newly acquired knowledge of its tools.
- Execute: Carry out the plan and report the outcome.
💻 Usage Examples
API and Tool Reference
This document provides a detailed reference for the available tools that can be used to interact with the server.
create_agent
Creates a new Chatvolt agent.
Property |
Details |
Parameter |
Type, Description |
name |
string, required. The name of the agent. This is a human - readable identifier for the agent. |
description |
string, required. A detailed description of the agent's purpose and capabilities. |
modelName |
string, required. The specific AI model the agent will use (e.g., 'gpt - 4', 'claude_3_sonnet'). |
systemPrompt |
string, required. The initial instructions or context given to the agent to define its personality, role, and behavior. |
temperature |
number, optional. Controls the randomness of the model's output. A value closer to 0 makes the output more deterministic, while a value closer to 1 makes it more creative. |
tools |
array, optional. A list of tools that the agent can use to perform actions. |
update_agent
Partially updates an existing agent based on the ID. Allows updating one or more fields of a specific agent. Only the fields provided in the request body will be updated.
Property |
Details |
Parameter |
Type, Description |
id |
string, required. ID of the agent to be updated. |
name |
string, optional. New name for the agent. |
description |
string, optional. New description for the agent. |
modelName |
string, optional. New LLM model to be used by the agent. |
temperature |
number, optional. New model temperature (min 0.0, max 1.0). |
systemPrompt |
string, optional. New system prompt for the agent. |
visibility |
string, optional. New visibility for the agent (e.g., 'public', 'private'). |
handle |
string, optional. New unique identifier (slug) for the agent. |
interfaceConfig |
object, optional. New chat interface settings for this agent. |
configUrlExternal |
object, optional. New external URL configurations. |
configUrlInfosSystemExternal |
object, optional. New external URL configurations of the system. |
delete_agent
Deletes a specified agent.
Property |
Details |
Parameter |
Type, Description |
id |
string, required. The unique identifier of the agent to be deleted. |
list_agents
Retrieves a list of all available agents. This tool takes no parameters.
get_agent
Retrieves detailed information about a single agent.
Property |
Details |
Parameter |
Type, Description |
id |
string, required. The unique identifier of the agent to retrieve. |
agent_query
Sends a query or message to an agent for processing.
Property |
Details |
Parameter |
Type, Description |
id |
string, required. The unique identifier of the agent that will receive the query. |
query |
string, required. The text of the question or command to be sent to the agent. |
conversationId |
string, optional. The identifier for an existing conversation. If provided, the query will be part of that conversation's history. |
enable_disable_agent_integration
Enables or disables a specific integration for an agent.
Property |
Details |
Parameter |
Type, Description |
id |
string, required. The unique identifier of the agent. |
type |
string, required. The type of integration to modify (e.g., 'whatsapp', 'telegram'). |
enabled |
boolean, required. Set to true to enable the integration or false to disable it. |
create_crm_scenario
Creates a new scenario within the CRM.
Property |
Details |
Parameter |
Type, Description |
name |
string, required. The name of the new CRM scenario. |
description |
string, optional. A description of the scenario's purpose. |
update_crm_scenario
Updates an existing CRM scenario.
Property |
Details |
Parameter |
Type, Description |
id |
string, required. The unique identifier of the scenario to update. |
name |
string, required. The new name for the scenario. |
description |
string, optional. The new description for the scenario. |
delete_crm_scenario
Deletes a CRM scenario.
Property |
Details |
Parameter |
Type, Description |
id |
string, required. The unique identifier of the scenario to delete. |
list_crm_scenarios
Lists all CRM scenarios.
Property |
Details |
Parameter |
Type, Description |
agentId |
string, optional. If provided, filters the list to show only scenarios associated with this agent ID. |
create_crm_step
Creates a new step within a CRM scenario.
Property |
Details |
Parameter |
Type, Description |
scenarioId |
string, required. The unique identifier of the scenario to which this step will be added. |
name |
string, required. The name of the new step. |
update_crm_step
Updates an existing step in a CRM scenario.
Property |
Details |
Parameter |
Type, Description |
id |
string, required. The unique identifier of the step to update. |
name |
string, required. The new name for the step. |
delete_crm_step
Deletes a step from a CRM scenario.
Property |
Details |
Parameter |
Type, Description |
id |
string, required. The unique identifier of the step to delete. |
list_crm_steps
Lists all steps for a given CRM scenario.
Property |
Details |
Parameter |
Type, Description |
scenarioId |
string, required. The unique identifier of the scenario whose steps are to be listed. |
create_datastore
Creates a new datastore.
Property |
Details |
Parameter |
Type, Description |
type |
string, required. The type of datastore to create (e.g., 'qdrant'). |
name |
string, optional. A name for the datastore. |
description |
string, optional. A description of the datastore's content or purpose. |
get_datastore
Retrieves information about a specific datastore.
Property |
Details |
Parameter |
Type, Description |
id |
string, required. The unique identifier of the datastore to retrieve. |
search |
string, optional. A search term to find specific data within the datastore. |
list_datastores
Retrieves a list of all datastores. This tool takes no parameters.
create_datasource
Creates a new data source within a datastore.
Property |
Details |
Parameter |
Type, Description |
datastoreId |
string, required. The unique identifier of the datastore where the data source will be created. |
name |
string, required. The name of the data source, often used as a filename. |
text |
string, required. The actual text content of the data source. |