Quick links

Get Started

We've put together some helpful guides for you to get setup with our product quickly and easily.

The conserver supports these standard storages:

• ChatGPT FIles

• Elastic Search

• File

• Mongo

• Postgres

• Redis

• S3

• SFTP

Simplifying Working with Bots

Many programmable communication developers share the same experiences when they begin working on voice bots and transcriptions. They begin by capturing the conversation data with MS Word or Excel files. Often a combination of both to better represent conversations and enable the transcriptions to be processed / cleaned-up.

Later they build a JSON format that includes conversation data, transcriptions, context, etc. Soon they begin writing macros / functions to automate conversation data processing and analysis. With that comes maintaining both the JSON format and the macros / functions, and a realization they do not have the time to build everything themselves. vCon solves this common problem and enables macros / functions to be written to this common format and contributed to the open source project.

When companies merge or are acquired, they consolide suppliers to gain economies of scale. However, migrating data from an acquired company's UCaaS / CCaaS onto the acquiring company’s platform can be problematic.

Often the acquired company’s customer data and historical conversations are lost, or an expensive data migration project is undertaken. Businesses discover their customer conversation data is not really their data.

With vCon such a migration becomes an export / import of the historical conversations.

This could also be applied to a personal use case where an individual wants to download all their communications from a social network.

As a general rule, the law in the UK considers verbal contracts to be as legally binding as written ones, and therefore they do hold up in court. But this is an exception compared to the rest of the world. Generally, for established business relationships it makes doing business for small projects easy. Often just an email that summarizes the offer, a consideration, and acceptance is enough, the project gets delivered, and everyone is happy.

However, when legal gets wind of such dealings the $5k project that was supposed to be delivered next week doesn’t happen as the ‘standard’ T&Cs require contractor insurance with $X million+ liability coverage that takes more than a week to arrange. Plus all the time and effort in word-smithing far exceeds the project size.

Using a vCon on the call, chat, or email thread to discuss and agree the project, and using an app such as Meeting Minder - Contract Edition, a verbal or text agreement can easily be converted into a written one, with lightweight T&Cs begrudgingly accepted by legal for small projects. Now legal are not unhappy and the business can focus on operations, not document editing, with just a call creating a lightweight contract for review and signing.

Note ASR is not necessarily required in this use case. The conversation could be transcribed by a person, in some medical use cases such manual transcription continues to be required. A contract could have a value to make manual transcription economic or potentially preferred.

A carrier / telco knows both participants of a conversation were in Germany as the call was made over their network by devices physically connected to their network. Certifying the conversation was made in Germany places additional restrictions on how the data can be used to protect both parties. Personal data is constitutionally protected in Germany. This means individuals have the power to decide when and to what extent personal information is published.

To comply with the Dodd-Frank act's call recording regulations, companies must keep all communication records made through the telephone, voicemail, email, and others, and these records must be uniformly time stamped. A carrier could provide this as a service, recording all conversations made by a business’s mobile phones, and sharing with the business as a vCon. The conversation could additionally be processed by the carrier or CPaaS/UCaas/CCaaS to confirm no PII was shared in this conversation, or certify no keywords specified by the business were found. A business would only want to pay once for that service and attach the certification to the vCon.

Phone numbers can be spoofed. But within a carrier’s network they have knowledge of the device’s identity, its location, its phone number, its SIM (Subscriber Identity Module) card identity, the owner’s account, how long they have had that number or device, etc. There is no other agency that can confirm the identities of the parties on a call with such confidence. A carrier could certify the identities on a vCon.

Please note most of these use cases are voice-centric, we see voice conversations as an initial opportunity. However, vCon works for conversations across any communications media, e.g. email, video, SMS, web chat, social, chat in IP messaging like WhatsApp, etc.

Think of vCon as ‘robot food’, enabling conversation data to be presented in a common format and more easily cleaned for training of machine learning. ASR and conversation AI solutions do not meet the needs of some businesses with respect to accuracy, vCon will help our industry close the gap with respect to the hype.

The performance of ASR varies greatly depending on the application, quality of the recording, and engine/training. ASR continues to improve, some of these applications could be a stretch for a legacy call center, however, for some scenarios they are attainable today.

Virtualized Conversations, or vCons, are an emerging standard designed to transform how organizations capture, store, and analyze human communication. Developed under the guidance of the Internet Engineering Task Force (IETF), vCons serve as structured, tamper-proof digital containers—akin to PDFs for conversations—that encapsulate metadata, transcripts, participant identities, AI-driven analyses, and related attachments. By standardizing conversational data into a consistent JSON-based format, vCons facilitate interoperability across platforms, enhance data integrity, and support compliance with privacy regulations like GDPR and CCPA.

The utility of vCons spans various industries, including customer service, healthcare, finance, and automotive sectors. For instance, in contact centers, vCons enable seamless integration between communication systems and analytical tools, reducing reliance on proprietary formats and simplifying data exchange. They also support advanced applications such as sentiment analysis, fraud detection, and personalized customer interactions by providing a unified framework for storing and processing conversational data.

Beyond operational efficiencies, vCons play a pivotal role in enhancing data governance and ethical AI deployment. By offering granular control over data access and retention, they empower organizations to uphold user rights and ensure transparency in automated decision-making processes. As conversational AI continues to evolve, the adoption of vCons is poised to become integral to responsible data management and the development of intelligent, user-centric communication systems.

For more information, you can explore the following resources:

vCons are "PDFs" for Conversations

A vCon describes a conversation that involves a "natural" person. As a simple example, a vCon could be created from the last conversation you had with a customer service agent. Just like PDFs allow you to create and share any written document; vCons allow you to create and share any human conversation. A vCon identifies the people in the call, recordings and transcripts, analysis and supporting attachments, like documents and logs. Implemented in easy to manage JSON, vCons are both encryptable and tamper proof.

The conserver is a data platform designed to extract conversations from business phone systems, transform them into actionable insights, and send that data into common business tools such as spreadsheets, Salesforce and no code toolsets. An open core product, the conserver enables data engineering teams to supply a reliable source of information for AI, ML and operational software in cloud, premise and hybrid contexts. The core for many of the business cases enabled by the conserver is the smart capture, redaction and lifecycle management of recorded customer conversations and customer journeys, recently accelerated by FTC and GDPR regulations and by increasing investments into AI and ML.

From a system perspective, shown above, the Conserver attaches to information systems like Web Chat and call center queues, and extracts information from them after conversations are ended. This information is then cleaned and transformed into actionable data. For instance, a distributed call center might extract conversations from a group of sales agents, convert them into text, then filter those conversations looking for times when customers objected to a sale. These objections are then pushed into database tables and Google Sheets as a data self-service option for any business team. The conserver supports multiple data pipelines, each one extracting data from a number of systems, performing transformations such as translations, transcriptions and redactions, and then pushing the prepared data into applications to be used.

In contrast to other data platforms, the Conserver is dedicated to managing the particular complexities of real time conversational sources. For instance, the amount of bandwidth and storage required to manage an hour long audio recording is an order of magnitude larger than managing a typical business object like a PDF. However, even this is just a start. Video is a few orders of magnitude greater than that, and the data creation for service providers such as Zoom and Skype are magnitudes of order still greater. From a legal perspective, regulatory compliance for customer data protections are particular for recorded conversations, and require support for tracking data’s use by automations, and for tracking deletion from a “Right to be Forgotten” request.

Conversations are First Class Citizens

We have that enables anyone to store and exchange calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information. And so anyone can store and exchange electronic business cards, name and address information, phone numbers, e-mail addresses, URLs (Universal Resource Locator), logos, photographs, and audio clips.

An innovation ecosystem of specialists in conversation intelligence will flourish solving specific business pain points across operations, compliance, privacy, security, ethics, etc. Being able to access customer data often trapped within communication platforms. Think of vCon as ‘robot food’, enabling conversation data to be presented in a common format and more easily cleaned for training of machine learning. ASR and conversation AI solutions do not meet the needs of some businesses with respect to accuracy; vCon will help our industry close the gap with respect to the hype.

Official Documents

Read the

Track our

The problems created by not maintaining PII compliance is more than negative publicity. The fines have been massive, for example the FTC (Federal Trade Commission) fined Facebook $5 billion in 2012, Equifax was fined at least $575 million in 2017 and 2019, and British Airways was fined $230 million in 2018. There’s a long list of regulations including: GDPR, HIPAA, CCPA, PCI DSS.

It’s not just the big brands that get caught, a PII audit can happen to any business. They are not scheduled, and can be triggered by a complaint that can come from an unhappy ex-customer or even a competitor. There are fines and possible incarceration for not reporting PII breaches as well.

PII can be a person's name, in combination with any of the following information:

• Mother's maiden name

• Driver's license number

• Bank account information

• Credit card information

• Relatives' names

• Home Postal address

• Personal E-mail address

• Home or cellular telephone number

• Personal characteristics / biometric data

• Social Security Number (SSN)

• Date or place of birth

• An individual's title

• Work telephone number

• Official work location/address

• Work email address

• Asset information, such as a car’s Vehicle Identification Number (VIN) or title number. Even MAC (Machine Address Code) or IMSI (International Mobile Subscriber Identity)

• Even a vCon record given voice finger-printing

• Other information that would make the individual's personal identity easily traceable

Across all the conversations a business has, both internally and externally, which are often recorded for training purposes or by company policy, there is a significant repository of customer data missed by most PII tools because they tend to focus on text based files.

Existing PII tools search the company’s storage for files containing customer data, e.g. usernames and password. vCon makes conversation data more easily available to the existing PII audit tools, so your business is better protected. Note, some PII audits are now warning of the emerging need of including audiovisual data for PII Compliance.

Through the open standard vCon the existing PII Compliance tools can be extended to files containing audio visual conversations that are often overlooked. A business is not trapped into multiple specialized PII audits across its different communication silos.

Many of us have seen the data, 58% of customers say that customer service is a very important factor that affects their choice of a brand, source Microsoft’s State of Global Customer Service Report.

Call recording has been in place for decades, yet why have contact centers remained the same for decades? “Please listen carefully as our menus have changed.” No they have not, the menu has been the same for the past two decades! Why hasn’t call recording led to a virtuous circle of improvement?

Here are some of the claims made by call recording vendors:

• Call center managers can review the calls to get a better understanding of how agents handle customer conversations.

• Learn whether support representatives are following the protocols.

• Figure out specific customer support aspects that can be improved.

• With call recordings, call center managers can save time as they do not have to listen to each call in real time.

• Identify the gaps in terms of training and best practices whether they are followed or not.

• Learn first-hand customer feedback or issues and train your team to handle them better.

• Listening to call recordings one on one with employees will empower managers to identify the skills that need to improve and work upon.

• Based on the recorded audios, call center managers can prepare presentations to teach about the proper way of making and taking calls.

It’s rather manual and lacks quantified data and analysis, this reflects the historical limits of ASR. The call center manager will call a meeting based on their analysis, or bring in a consulting firm that analyzed the data, and based on ‘industry best practices’ make improvement recommendations. The training to implement the improvements is given, and when the call center manager evaluates the results, not much has changed. It’s been going on for decades. Often the sample size is too small given the highly manual approach, and sometimes changes to the process have unintended consequences blurring customer feedback.

vCon enables tens of thousands, even hundreds of thousands of calls to be analyzed by a broad ecosystem of innovative companies. Changes in the process can be analyzed by A/B analysis on possible ways to diffuse customer frustration about an overage charge. The vCons for the calls can be analyzed to make sure the A/B script is being followed, sentiment analysis, and customer feedback during / post call can be combined to produce quantified results.

Often great customer service is exemplified by employees going above and beyond what is economic for the business. While some companies like Zappos simply ensure a human approach to the customer. This may not work for all brands and situations. But being able to test and quantify the results over thousands or tens of thousands of conversations gives the business, and most importantly the agents, confidence in the process change. This is an example of a complex human factor problem that will require new approaches to conversation intelligence, enabled through the ecosystem made possible through vCon.

The customer is constantly providing information to your business: on which competitors they compare you to, what features they value in your product, what problems they have with your product, how they use your product, what features they do not use, how they like to be billed, how they view the pricing, why they moved from / to a competitor, how they use your product, how they mash-up your product and others to meet their needs, how they work around gaps in your product, etc.

Every conversation (voice, email, video, SMS, web chat, IP messaging, social, etc.) across sales, support, customer care, etc. is capturing this data. Extracting this data is not that easy, it's still a work in progress. vCon enables an ecosystem of analytics and data mining companies that can extract such information across all interactions. Determining that a customer is talking about a complementary product not a competitive product is not easy. But insights continue to improve.

vCon enables all customer data to be used to generate insights from the conversations stored but not fully mined. Surveys are often performed to capture minable data, often the surveys have leading questions or the survey is filled as fast as humanly possible. This does not provide accurate information, and why most surveys seem to enforce a marketing view not necessarily a customer view. The conversations taking place with sales, support, customer care are the most accurate customer data a business has access to, and remain relatively poorly mined.

Working with contractors has its ups and downs. During meetings note taking can miss agreements on deliverables and their timing, simply not happen, or not be fully understood by all parties. Everyone leaves with a slightly different perception of the action. Missed deliverables become finger pointing exercises that do little to help the working relationship.

Most conference calls are recorded, yet are only used for those that missed the meeting and listened to at 1.5-2 X speed. A call recording is generally not used by the people who attended, because they already attended. However, the content in that call is invaluable. It’s not that we forget what was agreed on the call, it’s that we get busy, when the actions / deliverables are in black and white on our to-do list, we are reminded every day.

Imagine after the meeting a vCon is produced. The vCon is processed by a Meeting Minder - Construction Edition app, which sends a summary to all participants on the conference call that includes the actions and deliverables. The app is trained to the specific vocabulary and processes used in an industry vertical, construction.

Each action/deliverable includes a reference to the section in the conversation. For example, “Action: Plan for Floor 5 will be sent by Joe to Mary at Company X by end of day June 7th, spoken by Anne,<link to specific point in the conversation>”. There is no finger pointing, immediately after the meeting the summary was sent to everyone within the meeting minutes, and transferred onto each participant’s to-do list. If there was an error, it would have been picked up then.

Practically, ASR on a conference call is far from perfect, especially if someone calls in using a mobile phone. But the actions and summary will be checked by some of the participants to make sure everything is captured adequately.

vCon enables a range of value added services to be created around this open standard, an ecosystem of innovators taking conversation intelligence beyond transcription. No longer does the Meeting Minder app provider need to waste time and expense joining every conference call / collaboration platform’s partner ecosystem. With vCon they can implement one format and cover all communication platforms that use vCon. Instead focusing on building best in class industry vertical solutions.

The integration headache for the Meeting Minder app provider results in less competition. They will focus on the top 5 conference / collaboration platforms. The open source conferencing platforms, the regional platforms, and smaller providers are skipped. vCon helps maintain healthy competition and the reach of vCon apps to extend across all programmable communication platforms.

Introduction

Authorization

The Conserver API provides a token based authentication, controlled by the environment variable CONSERVER_API_TOKEN in the environment. When not defined or empty, it is disabled. To enable, define CONSERVER_API_TOKEN in the .env file

vCon Management

Chain Management

Chains are series of links that process a vCon. Before processing a vCon, be sure to load it.

Configuration

Dead Letter Queue

Lifecyle

Using the Conserver with your application is straightforward:

• Setup your application database as a "storage" for the conserver. As it process vCons, the vCons will send copies of the vCons into the storage, similar to a database follower.

• When you create, update and delete vCons, use the Conserver REST API. This assures that the vCons will be processed, tracked and protected like the rest.

• For real time processing, you can use the use the WebHook link to notify your application of new vCons in the database. Also, since the conserver is a client to your application's database, all of the native notifications, such as Mongo OP-Log tails, REDIS key space events or S3 events can also be used.

Application Integration, Step by Step

1. vCons are sent to the Conserver using the REST API to first create new vCons. These vCons will now be saved in the REDIS database using the vcon: keyspace. For instance, a vCon with a uuid of 018796f4-ece7-8f28-9dd8-dd37220d739c will be stored in REDIS JSON with a key of vcon:018796f4-ece7-8f28-9dd8-dd37220d739c.

2. To process this vCon using a chain, add this vCon UUID to it using the REST API. These vCons uuid will be added to the list with matching name and processed in the main event loop.

3. Once the chain has finished processing the vCon, it will put the vCon into the storages configured for that chain. In the diagram above, it will be stored in both S3 and MongoDB.

1. Then using the REST API to trigger the execution of a "chain". Inside the conserver, the v

vCon Python Library

About the Library

The vCon (Virtual Conversation) library is a powerful Python tool designed to capture, structure, and manage conversation data in a standardized format. It provides a robust set of features for creating, manipulating, and analyzing digital representations of conversations, making it particularly useful for applications in customer service, call centers, chat systems, and any scenario where structured conversation data is valuable.

Link

A link is the basic unit of processing in the conserver. A link takes a single vCon and processes it. Examples of links include:

• Redaction: removes personal information from a transcript or a recording

Conversation Set

For this year's TADHack vCon Hackathon, we've generated a set of synthetic vCons for your use:

• You can download the set at https://github.com/vcon-dev/tadhack-2025

• An S3 Bucket is here: arn:aws:s3:::tadhack-vcons

Overview

This dataset contains customer service conversation data from Aquidneck Yacht Brokers in VCON (Virtual Call Object Notation) format. The conversations span from May 18-24, 2025, and represent typical customer interactions for a yacht brokerage company. The dataset includes 42 customer service calls between Aquidneck Yacht Brokers agents and customers, covering various marine industry-specific support scenarios.

Conversation Types

1. Returns & Refunds

• Customers requesting returns for yacht equipment

• Processing refund requests

• Emotional customers (often expressing sadness about returns)

2. Shipping & Logistics

• Yacht transportation inquiries (e.g., Fort Lauderdale to Newport)

• Delivery status updates

• Shipping cost questions

3. Order Issues

• Wrong items received (e.g., yacht anchor instead of navigation system)

• Missing order investigations

• Order verification and corrections

4. Equipment Support

• GPS malfunction troubleshooting

• Navigation system issues

• Equipment compatibility questions

5. Business Services

• Yacht listing inquiries

• Brokerage service questions

• Pricing and commission discussions

6. Account Management

• Membership cancellations

• Billing inquiries

• Privacy and data concerns

• Contact information updates

7. Appointments & Scheduling

• Yacht viewing appointments

• Service scheduling

• Consultation bookings

Call Characteristics

• Average Duration: 50-60 seconds

• Call Disposition: All marked as "ANSWERED" with "VM Left" status

• Language: English

• Transcription Confidence: 99%

Data Format

Each conversation includes:

• Audio recording (MP3 format)

• Full transcript with speaker diarization

• AI-generated summary

• Participant metadata (names, roles, contact info)

Typical Interaction Flow

1. Agent greeting with company name and agent introduction

2. Customer name verification

3. Issue description by customer

4. Information gathering (order numbers, email verification)

Notable Patterns

• Customers frequently express emotions related to their issues

• Agents consistently follow verification protocols

• Marine industry-specific terminology used throughout

• Focus on high-value transactions typical of yacht brokerage

This dataset provides realistic examples of customer service interactions in the luxury marine industry, useful for training, analysis, or demonstration purposes.

Introduction

Responsible management of customer data was well understood, if not well distributed, before the AI revolution. Since the AI explosion set off by ChatGPT, the environment in which customer data must be protected is distinctly more hostile. Although difficult, you can change your name and your social security number. Changing the actual look of your face, or the actual sound of your voice, is near impossible. In a future filled with deep fakes, this is a problem demanding a solution for ethical system design, sound business operation and both commercial and civil governance.

This primer explores the vCon, a groundbreaking technology designed to revolutionize the storage, analysis, and management of conversational data, of all kinds. This paper will provide a comprehensive overview of vCon, its structure, significance, and the stakeholders who should be interested in its implementation. For an current technical definition of a vCon, please visit the at the IETF (1).

AI assistants are powerful, but they have limits. They know a lot about the world from their training, but they cannot access your live data or use your tools. The Model Context Protocol, or MCP, changes that. This post explains how MCP works and why it matters.

The Limitation of Training Data

When you talk to an AI assistant like Claude or ChatGPT, it responds based on what it learned during training. That training data is a snapshot of information from when the model was created. It is like reading a book that was published last year. The information might be good, but it does not include anything that happened after publication.

This creates several problems:

• The assistant cannot see your current data

• The assistant cannot perform actions in your systems

• The assistant cannot access real-time information

• The assistant cannot work with your specific tools and workflows

You might ask the assistant to check your customer support calls from yesterday. Without MCP, the assistant cannot do that. It does not have access to your systems. It can only work with the information in its training data.

What is Model Context Protocol?

Model Context Protocol, or MCP, is an open standard that lets AI assistants interact with external tools and data sources. Think of it as a common language that AI assistants and your systems can both understand.

MCP defines three main ways for assistants to interact with external systems:

Tools - These are actions the assistant can perform. A tool might create a new record, search a database, or update information. Tools are like functions the assistant can call.

Resources - These are read-only data sources the assistant can access. A resource might be a specific file, a database record, or a web page. Resources are like URLs the assistant can fetch.

Prompts - These are templates that guide the assistant on how to do something. A prompt might explain how to search effectively or what information to include. Prompts are like instructions or recipes.

Together, these three mechanisms give the assistant capabilities it did not have before.

A Simple Analogy

Imagine you have a smart assistant in your office. Without MCP, the assistant only knows what was in the training materials. It is like having someone who read a manual but has never actually used your office equipment.

With MCP, you give the assistant:

• Tools it can use, like your phone system, your database, and your file system

• Resources it can read, like your customer records and your company documents

• Prompts that explain how your office works, like how to file paperwork or who to contact for different issues

Now the assistant can actually do work, not just answer questions about what it read in a manual. It can look things up, perform actions, and work with your actual systems.

How MCP Extends AI Capabilities

Let us look at each part of MCP in more detail.

Tools: Actions the Assistant Can Perform

Tools are executable operations. When you ask the assistant to do something, it can choose a tool that performs that action. For example, if you ask the assistant to find customer support calls about billing, it might use a search tool provided by your conversation database.

Each tool has:

• A name that describes what it does

• A description that explains when to use it

• Input parameters that define what information it needs

• Output that describes what it returns

The assistant understands these tool definitions and can decide when to use each one. It is like giving the assistant a toolbox where each tool is labeled and has instructions.

Resources: Data the Assistant Can Read

Resources are URI-based data access points. The assistant can request a resource and get data back. For example, if you ask about a specific conversation, the assistant might fetch a resource that points to that conversation's data.

Resources are read-only. The assistant cannot change data through resources. It can only read. This makes resources safe for the assistant to explore your data without accidentally modifying anything.

Resources are discoverable. The assistant can ask what resources are available and then access them. It is like giving the assistant a catalog of all the data it can read.

Prompts: Guidance for the Assistant

Prompts are templates that help the assistant understand how to accomplish tasks. They provide context and step-by-step guidance. For example, a prompt might explain how to search for conversations by tags, or what information to include when creating a new conversation record.

Prompts are not just instructions. They can include examples, best practices, and warnings about common mistakes. They help the assistant work more effectively with your specific systems and requirements.

How the vCon MCP Server Uses MCP

The vCon MCP Server implements MCP to give AI assistants access to conversation data. It provides:

Over 27 tools for managing conversations. These include creating conversations, searching them, updating them, adding analysis, managing tags, and getting analytics.

Resources that let the assistant directly read conversation data using URI paths. For example, the assistant can request a resource like vcon://uuid/abc123 to get a specific conversation, or vcon://uuid/abc123/parties to get just the participant information.

9 prompts that guide the assistant on effective searching and retrieval. These prompts help the assistant understand when to use different search strategies and how to structure queries.

When you ask the assistant to work with conversation data, it uses these tools, resources, and prompts. The assistant does not need to know the technical details of how your database works. It just needs to know which tools to use and how to use them.

An Example Conversation

Let us see how this works in practice. You are talking to your AI assistant:

You: "Find all the customer support calls from last week where the customer was frustrated."

Assistant: The assistant sees you want to search for conversations. It looks at the available tools and sees several search options. It decides to use semantic search because you mentioned "frustrated," which is about sentiment rather than exact words. The assistant uses the search_vcons_semantic tool with parameters like the date range and a query about customer frustration.

Assistant: "I found 12 support calls from last week where customers showed frustration. Would you like me to summarize the common issues, or show you specific calls?"

You: "What were the main issues?"

Assistant: The assistant uses the search results it already has and analyzes them. It might use additional tools to get more details about specific conversations, or it might analyze the data directly from the search results.

Assistant: "The main issues were: delivery delays (5 calls), billing errors (4 calls), and product defects (3 calls). Should I get more details on any of these?"

This conversation flows naturally, but behind the scenes the assistant is using MCP tools to access your actual conversation data. It is not making things up based on training data. It is working with your real data.

Why Standards Matter

MCP is an open standard, not a proprietary system. This means:

• Any AI assistant can implement MCP support

• Any system can provide MCP tools, resources, and prompts

• You are not locked into one vendor

• The community can improve and extend the standard

This is important because it means MCP will work with future AI assistants, not just the ones available today. If a new assistant comes along that you prefer, it can still use the same MCP servers you have set up.

It also means you can build your own MCP servers for your specific needs. You are not limited to what vendors provide. You can create tools that match exactly what your business needs.

Benefits of the MCP Approach

Using MCP with AI assistants provides several benefits:

Real-time access - The assistant can work with your current data, not just historical training data.

Actionable capabilities - The assistant can perform actions, not just answer questions.

System integration - The assistant can work with your existing tools and databases.

Natural interaction - You talk to the assistant in plain language, and it figures out which tools to use.

Extensibility - You can add new tools, resources, and prompts as your needs grow.

Security - The assistant only has access to what you explicitly provide through MCP. You control what it can see and do.

How It Differs from Traditional APIs

You might wonder how MCP differs from traditional APIs. Traditional APIs require you to know specific endpoints, parameters, and response formats. You need to write code or configure integrations.

MCP works at a higher level. The assistant understands what tools are available and how to use them. You do not need to write code or configure complex integrations. You just talk to the assistant, and it handles the details.

This does not mean MCP replaces APIs. MCP often uses APIs under the hood. But it presents them to the assistant in a way the assistant can understand and use intelligently.

The Future of AI Integration

MCP represents a new way of integrating AI assistants into your work. Instead of treating the assistant like a separate tool, MCP lets you treat it like a team member who has access to your systems.

As MCP grows and more systems adopt it, AI assistants will become more capable. They will be able to work with more types of data and perform more types of actions. The vCon MCP Server is one example of this future. It gives assistants the ability to work with conversation data in a standard way.

Conclusion

MCP bridges the gap between AI assistants and your systems. It gives assistants real capabilities by providing tools, resources, and prompts they can understand and use. The vCon MCP Server implements MCP to make conversation data accessible to AI assistants.

The next post in this series covers the complete scope of what the vCon MCP Server can do. It goes into detail about all the features and capabilities available.

Have you ever wanted to ask an AI assistant about past conversations? Maybe you want to find all the times a customer called about billing issues, or analyze patterns in support calls, or track what happened in a sales meeting. The vCon MCP Server makes this possible.

This post explains what the vCon MCP Server is, what problem it solves, and why it might be useful for you.

The Problem with Conversation Data

Most businesses have conversations happening everywhere. Phone calls, video meetings, chat messages, emails. These conversations contain valuable information, but they are usually scattered across different systems. Each system stores data in its own format. This makes it hard to:

• Search across different types of conversations

• Analyze patterns over time

• Share conversation data between tools

• Work with AI assistants on conversation history

• Maintain privacy and compliance standards

You might have customer support calls in one system, sales meetings in another, and email threads in yet another. To get a complete picture, you would need to check all three systems separately. That takes time and effort.

What is vCon?

vCon stands for Virtual Conversation. It is an IETF standard format for representing conversations. Think of it like PDF for conversations. Just as PDF is a standard format that works across different computers and programs, vCon is a standard format that works across different systems.

A vCon file can contain:

• The actual conversation content, whether it came from voice, video, text, or email

• Information about who participated in the conversation

• Analysis results from AI, like transcripts, sentiment scores, or summaries

• Attachments like documents or images related to the conversation

The key benefit is portability. If you store conversations in vCon format, you can move them between systems without losing data. You are not locked into one vendor's system. You own your conversation data in a standard format.

What is MCP?

MCP stands for Model Context Protocol. It is a way for AI assistants to use external tools and data sources. Without MCP, AI assistants can only work with the information they learned during training. They cannot access your live data or perform actions in your systems.

With MCP, an AI assistant can:

• Read data from your databases

• Perform actions using your tools

• Access real-time information

• Maintain context about what you are working on

Think of MCP like giving an AI assistant access to your toolbox. The assistant can see what tools are available, understand what each tool does, and use them when you ask. This makes AI assistants much more useful for real work.

What is the vCon MCP Server?

The vCon MCP Server combines these two ideas. It is a server that lets AI assistants work with conversation data stored in vCon format. You connect the server to an AI assistant like Claude, and then the assistant can:

• Create new conversation records

• Search through historical conversations

• Analyze conversations for insights

• Organize conversations with tags

The server speaks the MCP protocol, which AI assistants understand. When you ask the assistant to do something with conversation data, it uses the server's tools to get the job done.

What Can It Do?

Here are the main capabilities:

Store conversations - The server can store conversations in vCon format, following the IETF standard exactly.

Search conversations - You can search in four different ways:

• Basic filtering by subject, participants, or dates

• Keyword search that looks for exact words

• Semantic search that finds conversations by meaning, even if the exact words are different

• Hybrid search that combines keyword and semantic approaches

Organize with tags - You can add tags to conversations for easy organization and filtering. Tags work like labels you might put on file folders.

Analyze and monitor - The server can provide analytics about your conversation database, showing growth trends, content patterns, and health metrics.

Manage components - You can add or update different parts of a conversation, like adding analysis results or attaching files, without recreating the whole conversation.

Use templates - The server includes templates for common conversation types, making it easier to create new records.

Extend with plugins - The server supports plugins that can add custom functionality, like privacy controls or compliance features.

Who Would Use This?

Several groups of people might find this useful:

Customer support teams - Store and search support calls, track issues, analyze agent performance, and maintain compliance records.

Sales teams - Record sales conversations, extract action items, analyze what works, and generate meeting summaries.

Compliance and legal teams - Maintain conversation archives, apply privacy controls, track consent, and generate audit reports.

Researchers - Collect conversation datasets, study communication patterns, and build training data for machine learning models.

Developers - Build applications that work with conversation data using a standard format and API.

Business analysts - Search across conversations to find insights, track trends, and answer questions about customer interactions.

A Simple Example

Imagine you run a customer support team. You have thousands of support calls stored in a system. You want to know: "What are customers complaining about most this month?"

Without the vCon MCP Server, you might need to:

1. Export data from your phone system

2. Load it into a spreadsheet or database

3. Write queries or scripts to analyze it

4. Create reports manually

With the vCon MCP Server, you can simply ask your AI assistant: "What are customers complaining about most this month?" The assistant uses the server's search tools to find relevant conversations, analyzes them, and gives you an answer. If you want more detail, you can ask follow-up questions. The assistant has access to all your conversation data through the server.

Why Standards Matter

Both vCon and MCP are open standards. This means:

• They are not controlled by a single company

• Anyone can implement them

• They work across different systems

• They evolve through community input

Using standards gives you options. If you build on top of the vCon MCP Server and later want to switch to a different system, your data is in a standard format. You are not locked in. You also benefit from the work others do with these standards. New tools and integrations appear as the standards grow.

Getting Started

The vCon MCP Server is open source and free to use. You need:

• Node.js installed on your computer

• A Supabase account for the database (free tier available)

• An AI assistant that supports MCP, like Claude Desktop

The server connects to your database and exposes tools that the AI assistant can use. You talk to the assistant in natural language, and it figures out which tools to use and how to use them.

What's Next?

This was a high-level overview. If you want to learn more, the next posts in this series cover:

• How MCP works with AI assistants in more detail

• The complete scope of what the server can do

• How the server is built and why it is designed that way

• Real-world business cases and use cases

Each post goes deeper into different aspects of the server. You can read them in order or jump to what interests you most.

The conserver's configuration file is the heart of how the system operates, defining how conversations flow through the system and how they are processed and stored. Let's break down each major component and how to configure them.

Configuration File Location

The configuration file location is specified in the environment (I use the .env file), typically at config.yml in the vcon-server root.

Configuration File Structure

The configuration file is a YAML document with several main sections:

• links: Defines the processing modules available to the system

• storages: Specifies where vCons can be stored

• chains: Defines the workflow pipelines

• followers: Configures how the system can follow other conservers

Let's explore each section in detail:

Configuring Links

Links are the processing units of the conserver. Each link is a module that performs a specific operation on a vCon. Here's how to configure a link:

Each link configuration needs:

• A unique name (e.g., 'deepgram', 'analyze')

• The module path that implements the link functionality

• An options dictionary containing the link's specific configuration

Configuring Storages

Storages define where vCons are saved after processing. The conserver supports multiple storage backends:

Each storage needs:

• A unique name

• The storage module implementation

• Connection and authentication options specific to the storage type

Configuring Chains

Chains are where you define your processing workflows. They connect links together and specify where the results should be stored:

A chain configuration includes:

• The links to execute, in order

• Input lists (ingress_lists) where new vCons arrive

• Storage locations for the processed vCons

• Output lists (egress_lists) for downstream processing

Configuring Followers

Followers allow one conserver to monitor and process vCons from another conserver:

Each follower needs:

• The URL of the remote conserver

• Authentication credentials

• The remote list to monitor (egress_list)

• The local list to populate (follower_ingress_list)

Configuration Best Practices

When configuring your conserver:

1. Use meaningful names for your chains, links, and storage configurations to make the system easier to understand and maintain.

2. Consider your processing pipeline carefully - organize links in a logical order where each step builds on the previous ones.

3. Use multiple storage backends when needed - for example, storing in both S3 for long-term storage and Postgres for quick querying.

4. Configure appropriate timeouts for your chains based on the expected processing time of your links.

The configuration file is loaded by the system at startup and can be updated via the API endpoint /config. The system will use the new configuration immediately after updating.

Remember that the conserver uses Redis as its working storage, so all the lists referenced in ingress_lists and egress_lists are Redis lists. The actual vCons are stored in Redis using JSON data types, making them quickly accessible during processing.

This configuration system provides a flexible way to define complex processing pipelines for your vCons while keeping the configuration clear and maintainable.

The Conserver processes vCons, storing them locally, and projecting them into the third party information services. The building blocks of the Conserver are links, which have an interface to accept a single vCon, and can then forward that vCon, or create new ones, to other links for further processing. Links are formed into chains, designed to apply a series of analysis and transformation to the vCons. Chains are executed by the conserver periodically on a timer, or on request from a third party system.

Links: The Fundamental Building Block

The heart of the conserver functionality is the "link". A link is a Python module that takes a single vCon and processes it. Chains are ultimately created by combining links in serial. All links have the same interface. Using links has multiple advantages:

• Configurable: Uses a flexible options system for customization.

• Retry Mechanism: Implements exponential backoff for API call retries.

• Caching: Avoids redundant analysis by checking existing data.

• Metrics: Tracks performance and error metrics.

As an example, let's look at This link takes a vCon, applies a prompt to it, then adds an analysis to the vCon with the result.

Main Function: run

The run function is the entry point for links. , it performs the following steps:

1. Merges provided options in the "config.yml" file with default options.

2. Retrieves the vCon (voice conversation) object from Redis.

3. Applies inclusion filters and sampling.

4. Iterates through dialog entries in the vCon:

Default Options

A default_options dictionary defines the options for the link, and are overridden by the configuration file. For instance, the analysis link is defined with the following options:

• Prompt for summarization

• The value to set as the analysis type when added to the vCon (default: "summary")

• GPT model (default: "gpt-3.5-turbo-16k")

• Sampling rate and temperature

Error Handling and Metrics

The module includes error handling for API calls and retries. It also tracks metrics such as analysis time and failures using custom metric functions.

Return Values

Links can return one of two kinds of values. Links can return a vCon UUID, or None. Typically, it would be the vCon UUID that was passed in. However, if the link created a new vCon, as would be required for creating a new, redacted vCon, the new UUID would be returned by the link. To stop chain processing, a link could return None. This is useful for links that filter vCons out, only allowing certain ones down the chain, and stopping the processing of links downstream of the chain.

Chains: Links for Workflow

The fundamental implementation of workflow is created by a series of links. These chains take vCon uuids from REDIS lists, runs the chain of links on the vCon, stores it, then places the uuids in egress REDIS links.

Chain Processing, Link by Link

The processes vCons:

• Loads configuration and sets up the ingress chain map.

• Enters a loop that continuously checks for new items in the ingress lists using Redis.

• When an item (vCon ID) is found, it creates a VconChainRequest and processes it.

• Handles exceptions by moving problematic vCons to a Dead Letter Queue.

Step by step:

1. Processing starts when vCon UUIDs are placed into a ingress list. Chains may have several ingress lists, and have to have at least one to kick off processing. Lists are implemented as REDIS lists, and processing is controlled at the thread layer by blocking until the a new element is placed on the list. UUIDs can be added to the ingress list by other chains, allowing them to be placed in series, from links that can request processing, or from the API. A typical pattern is to create the vCon using the API, then inserting the UUID into the desired ingress list.

2. For each vCon taken from the ingress list, it is processed by each link in the chain. This _process_link function handles the execution of a single link in the processing chain for a vCon. Here's a summary of its functionality:

   This enables flexible and dynamic execution of different processing steps (links) in the vCon processing chain, with built-in logging and timing measurements.

Tech Stack

The Conserver is built off of two core platforms: a python API framework FASTAPI, and a REDIS real time database. The conserver itself is written in Python, and uses the standard vCon Python library to create and modify vCons.

REDIS is responsible for storing the conversations, while FAST API coordinates the application software that manages them. Each conversation is stored as a REDIS JSON object in the standard vCon format. In practice, each vCon is stored in REDIS by the UUID of the vCon, making them easy to discover and fast to process. Instead of copying the conversation as it’s built and transformed, it stays stored in REDIS, and the ID to the vCon is passed, optimizing processing efficiency even at very large data sizes. REDIS also provides inter task communication using a series of PUB/SUB channels, coordinating the activities of the conserver for both local software (that inside the conserver itself) but also for external software such as Lambdas or exporting onto other systems like Apache Kafka. Also, third party and hardware enabled systems can use REDIS as a data interchange system, loading and unloading large media files in coordination with the data pipeline.

Each vcon is stored in REDIS using JSON and named with a regular key: vcon:{{vcon-uuid}}, as are chains "chains:{{name}}", links "link:{{name}}" and storages "storage:{{name}}}". REDIS allows for the addition of dedicated hardware to accelerate long running and high compute use cases such as transcription and video redaction, as these systems can connect directly to REDIS relieving scale issues from general purpose hardware, while managing the overhead of moving large amounts of data. Links take a vCon ID as inputs, and bear the responsibility of reading vCons if required, or giving them the option to hand off to optimized hardware.

FAST API provides the application infrastructure for the conserver. The transformation steps are developed as Python modules and loaded as tasks managed by FAST API. As each task finishes, it notifies other system elements by publishing UUID of the vCon. Other tasks wait on these notifications, and when they receive the notification, they can act on that same vCon for whatever purpose they may have. In addition, FAST API provides a REST API to the store of vCons, and a simple UI to manage the conserver.

The vCon Store: Building an Open Ecosystem for Conversational Applications

Introduction: From Infrastructure to Innovation

The history of telecommunications reveals a profound truth: what we perceive as infrastructure today often began as revolutionary applications. Alexander Graham Bell's telephone wasn't conceived as the backbone of global communication—it was commissioned by Samuel Gridley Howe, president of the Perkins School for the Blind, as an assistive device for the blind, built atop existing telegraph infrastructure. This pattern of application-driven innovation has repeated throughout telecommunications history, from Interactive Voice Response (IVR) systems that businesses once had to be convinced to adopt, to prepaid calling cards that drove massive traffic in the telecommunications field during the 1970s and 80s, each representing an attempt to unlock new value from voice communications.

Ubuntu Install

Based on a digital ocean install, to keep it vanilla. Created a 4 GB Memory / 2 Intel vCPUs / 120 GB Disk / NYC3 - Ubuntu 23.04 x64 droplet, logged in.

Conserver Start

The conserver repo , but is also included in the vcon repo in the von-server directory.

Create an ~/vcon/.env file. See example .env below. *Note that the default URL for REDIS assumes it is running in a docker container, thus the hostname "redis".

Example vcon-server/config.yml

Most of the configuration is done through the config.yml file. Here's a very simple one. Inbound vCons in the ingress chain cause a slack webhook into a workflow, then it will be stored in mongo.

Standalone Operation

When running a conserver in "standalone mode" (using vcon-admin as a simple portal, which will also provide the basic versions of all of the apps and databases), it will automatically register a domain name and generate a valid SSL certificate using LetsEncrypt, assuming that the domain name has an A record pointing to your server.

Start the Conserver

Troubleshooting and Checking

You can validate that the conserver is running on the command line using "docker ps". In the example below, we can see four instances running.

You can see the operational logs using "docker compose logs -f". Here's a typical log:

The is a nice tool for managing the conserver.

Abstract

The increasing complexity of software supply chains has created unprecedented security challenges, as demonstrated by high-profile attacks like SolarWinds and Log4Shell. Supply Chain Integrity, Transparency and Trust (SCITT) emerges as a comprehensive framework designed to create an immutable, transparent ledger for software supply chain artifacts and attestations. This whitepaper examines SCITT's architecture, security model, and interoperability features, demonstrating how it addresses critical gaps in current supply chain security approaches while maintaining compatibility with existing tools and workflows.

1. Introduction

Modern software development relies on complex supply chains involving multiple parties, from open-source contributors to commercial vendors. Each component may pass through numerous hands before reaching production systems, creating opportunities for compromise at every stage. Traditional approaches to supply chain security rely on point-in-time verification and trust relationships that can be exploited by sophisticated attackers.

SCITT provides a standardized framework for creating tamper-evident, publicly verifiable records of claims about software artifacts throughout their lifecycle. By establishing a cryptographically secured, append-only registry of attestations, SCITT enables organizations to make verifiable statements about their software while allowing consumers to independently verify these claims and trace complete component histories.

2. Technical Architecture

2.1 Core Components

SCITT's architecture consists of four primary components:

Transparency Service: The central registry that maintains an append-only log of all claims. This service provides cryptographic receipts proving that claims have been registered at specific points in time.

Claims: Signed statements about software artifacts, including but not limited to Software Bills of Materials (SBOMs), vulnerability reports, build provenance, and security assessments. Claims are format-agnostic, allowing integration with existing standards.

Receipts: Cryptographic proofs issued by the Transparency Service confirming that a claim has been registered. These receipts enable offline verification without accessing the service.

Verifiers: Entities that validate claims and their associated receipts to establish trust in software components before deployment or use.

2.2 Cryptographic Foundation

SCITT builds upon established cryptographic standards, primarily CBOR Object Signing and Encryption (COSE) for signature formats. This ensures compatibility with existing public key infrastructure while providing flexibility for future cryptographic algorithms. The framework uses hash chains similar to certificate transparency logs, creating an immutable record that makes tampering immediately detectable.

3. Relationship to Blockchain Technology

While SCITT shares fundamental concepts with blockchain technology, it represents a specialized application optimized for software supply chain metadata rather than general-purpose transactions.

3.1 Shared Principles

Both SCITT and blockchain systems implement:

• Immutable append-only logs where historical records cannot be altered

• Cryptographic linking between entries to ensure temporal ordering

• Transparent verification allowing any party to audit the complete history

• Decentralization potential through federated architectures

3.2 Key Differentiators

Unlike traditional blockchains, SCITT:

• Eliminates consensus overhead: No proof-of-work or proof-of-stake mechanisms required

• Enables efficient scaling: Designated transparency services operated by trusted organizations

• Separates storage and verification: Federated registries can reference each other without full replication

• Optimizes for specific use cases: Designed specifically for software attestations rather than financial transactions

This specialized approach makes SCITT more energy-efficient and performant while maintaining the security guarantees essential for supply chain integrity.

4. Security Benefits

4.1 Non-Repudiation and Accountability

Once an organization registers a claim about their software, the cryptographic receipt creates an undeniable record. This accountability mechanism ensures that malicious actors cannot quietly inject compromised components or retroactively alter their attestations after a breach is discovered.

4.2 Tamper-Evidence and Forensic Capabilities

SCITT's cryptographic receipts provide temporal proof of when specific claims existed, enabling precise forensic analysis. Security teams can definitively determine what was known at any point in time, identifying exactly when and where compromises occurred in the supply chain.

4.3 Attack Prevention and Detection

SCITT addresses several critical attack vectors:

Supply Chain Injection: Unauthorized modifications become immediately visible due to missing or invalid SCITT registrations from legitimate sources.

Dependency Confusion: Internal packages can be cryptographically distinguished from public packages through issuer verification.

Time-of-Check/Time-of-Use: Cryptographic receipts ensure the verified version matches the deployed version.

Retroactive Tampering: The append-only nature prevents attackers from covering their tracks by modifying historical records.

4.4 Policy Enforcement

Organizations can implement automated security policies that verify multiple conditions before allowing software deployment:

• Presence of required attestations (SBOMs, vulnerability scans)

• Signatures from authorized entities

• Build provenance from approved CI/CD systems

• Compliance with regulatory requirements

These policies can be enforced programmatically across organizational boundaries, creating a transparent trust framework.

5. Interoperability and Integration

5.1 Format-Agnostic Design

SCITT's architecture accepts any serializable content type, enabling seamless integration with existing tools and standards:

• SPDX and CycloneDX for software composition

• In-toto and SLSA for build provenance

• Custom formats for proprietary security assessments

• Industry-specific compliance attestations

This flexibility allows organizations to adopt SCITT without abandoning their current toolchains or workflows.

5.2 Federation Capabilities

Multiple SCITT instances can interoperate through claim references, enabling:

• Cross-organizational trust without centralization

• Industry-specific registries that maintain autonomy

• Geographic distribution for performance and compliance

• Gradual adoption across supply chain participants

5.3 Standardized APIs

SCITT employs standard HTTP REST APIs with COSE signatures, ensuring:

• Language-agnostic integration

• Minimal modification to existing tools

• Consistent verification regardless of claim format

• Simplified adoption across diverse ecosystems

6. Implementation Considerations

6.1 Deployment Models

Organizations can choose from several deployment approaches:

Public Registries: Industry-wide transparency services operated by trusted entities Private Registries: Internal services for proprietary software and sensitive attestations Hybrid Models: Selective publication based on confidentiality requirements Federated Networks: Interconnected registries sharing trust relationships

6.2 Performance and Scalability

SCITT's design prioritizes efficiency:

• Lightweight claim registration process

• Offline verification capabilities

• Distributed caching of receipts

• Selective synchronization between registries

These characteristics enable SCITT to scale to global software supply chains without creating performance bottlenecks.

6.3 Migration Strategies

Organizations can adopt SCITT incrementally:

1. Begin with high-value or high-risk components

2. Integrate with existing CI/CD pipelines

3. Gradually expand coverage across the software portfolio

4. Establish federation with supply chain partners

7. Future Directions

The SCITT framework continues to evolve through the IETF standardization process. Key areas of development include:

• Enhanced privacy features for sensitive attestations

• Improved federation protocols for cross-registry trust

• Integration with emerging software identity standards

• Automated policy languages for complex trust requirements

8. Conclusion

SCITT represents a fundamental advancement in software supply chain security, providing the transparency and accountability necessary for modern software ecosystems. By combining the immutability of blockchain-inspired architectures with the efficiency required for practical deployment, SCITT offers a path toward comprehensive supply chain integrity.

The framework's format-agnostic design and standardized APIs ensure that organizations can adopt SCITT without disrupting existing workflows, while its cryptographic foundation provides the security guarantees necessary to detect and prevent sophisticated supply chain attacks. As software supply chains continue to grow in complexity, SCITT's transparent trust model becomes increasingly critical for maintaining security at scale.

References

• IETF SCITT Working Group. "Supply Chain Integrity, Transparency and Trust." Internet Engineering Task Force. https://datatracker.ietf.org/wg/scitt/about/

• SCITT Architecture Internet-Draft. "An Architecture for Supply Chain Integrity, Transparency, and Trust." https://datatracker.ietf.org/doc/draft-ietf-scitt-architecture/

• Microsoft Corporation. "SCITT Confidential Consortium Framework Ledger Implementation." https://github.com/microsoft/scitt-ccf-ledger

• SCITT Community. "SCITT API Emulator Reference Implementation." https://github.com/scitt-community/scitt-api-emulator

To illustrate the normal operation of the conserver, let’s follow along as a conversation is extracted, transformed and the data is provided to a business team. For this example, we’ll assume the Conserver is started and configured to take conversations from a Freeswitch system, transcribe them, look for a particular subject (recalls) and send those to a PostGres table for the operations team.

1. A customer and an agent has a conversation using Freeswitch. A Freeswitch adapter is running that monitors calls and requesting recordings. For context, refer to https://developer.signalwire.com/compatibility-api/xml/ to see the kinds of call events and recording options.

2. When the call on Freeswitch ends, the adapter uses the data from the call (parties, recordings) to create a vCon. This vCon is then sent to the Conserver in a POST to the conserver's API, naming the REDIS lists that feed each conserver chain. Alternatively, the vCon could also be inserted into REDIS directly, then adding the vCon UUID to each chain's ingress list.

ASR (Automatic Speech Recognition) for many languages is still in development. That is why Le Voice Lab exists, a French association that brings together various institutional players (universities, research laboratories, etc.) and private companies whose common interest is to build an independent ecosystem and common standards to enable France and Europe to remain competitive in the global voice market. It’s not just Europe, around the world there is a substantial quality gap compared to the English speaking world for ASR.

But which ASR works best for business’s customers, and is it good enough for the intended applications? Enterprises are now equipped to easily compare the different ASR engines from global and regional providers. vCon enables a single source of test data to accurately and repeatedly measure speech recognition performance across 100s or 1000s of samples, to gather statistically meaningful performance data.

As it’s a computer file format the vCons can be processed through an Excel sheet or business intelligence application. Businesses can make quantified decisions based on their specific situation. The ‘Rolls Royce’ ASR may be the best with an accuracy range of 94-96%, but the ‘Honda Civic’ ASR is good enough at 92-94% for the intended application. The vCons from the different ASRs can be processed through the business application, and the business results compared, not just word error rates.

A business may receive 95% of their voice calls from 3G mobile networks with a range of dialects. They can build their own vCon test set, run them through the ASRs, and with nothing more than Excel compare the results. It could be that ASR in general is not currently up to the task, this will change given the continued performance improvements, but better to make an informed decision and revisit; than assume ASR is inadequate until the gap with competitors becomes clear and leaves your business struggling to catch up.

vCons democratize an opaque industry, which relies on fear, uncertainty, and doubt to stop the buyer making a quantified decision that is best for their situation.

This post explains why conversation data matters in business, what problems organizations face with it, and how MCP servers using the vCon format can help. It also covers specific use cases and considerations for implementation.

Why Conversation Data Matters

Businesses have conversations with customers, partners, and employees every day. These conversations contain valuable information that can drive better decisions and outcomes.

Customer insights - Conversations reveal what customers care about, what problems they face, and how they feel about your products or services. This information is more direct and actionable than surveys or analytics.

Operational intelligence - Conversations show how well your team is performing, what processes work, and where improvements are needed. You can identify training opportunities, process bottlenecks, and quality issues.

Compliance requirements - Many industries must maintain records of certain conversations for regulatory compliance. Healthcare, finance, and legal services all have specific requirements.

Relationship management - Conversation history helps teams understand relationships over time. When a customer calls, agents can see past interactions and provide better service.

Analytics and research - Aggregated conversation data can reveal trends, patterns, and insights that inform strategy, product development, and marketing.

Despite this value, many organizations struggle to capture, organize, and use conversation data effectively.

Problems with Conversation Data

Organizations face several common problems when working with conversation data:

Data fragmentation - Conversations happen across many systems. Phone calls are in one system, emails in another, chat messages in yet another, and video meetings somewhere else. Getting a complete picture requires checking multiple systems.

Vendor lock-in - Each system stores data in its own format. Moving data between systems is difficult, and switching vendors often means losing access to historical data or spending significant effort to migrate it.

Limited search capabilities - Most systems only support basic search by date, participant, or subject. Finding conversations by meaning, sentiment, or topic is difficult or impossible.

Integration challenges - Connecting conversation data to other business systems requires custom development. Each integration is a new project with ongoing maintenance costs.

Compliance complexity - Meeting regulatory requirements often means building custom solutions for consent tracking, data retention, redaction, and audit trails.

AI integration difficulty - AI assistants and analysis tools cannot easily access conversation data because it is locked in proprietary systems with limited APIs.

These problems make it hard to realize the full value of conversation data.

How MCP Servers Solve These Problems

MCP servers provide a standard way for AI assistants to access conversation data. This solves several problems:

Standardized access - AI assistants understand the MCP protocol, so they can work with any MCP server without custom integration code. You can switch AI assistants or use multiple ones without rebuilding integrations.

Natural language interaction - Instead of writing code or learning specific APIs, you can ask AI assistants to work with your conversation data using plain language.

Real-time capabilities - MCP servers provide access to live data, not just historical snapshots. AI assistants can work with current information.

Extensibility - MCP servers can expose multiple tools, making them more capable over time without requiring changes to how assistants interact with them.

The Value of the vCon Format

The vCon format adds additional value on top of MCP:

Portability - vCon is a standard format that works across systems. You can move conversation data between vendors or tools without losing information. You own your data in a format you can use anywhere.

Completeness - vCon captures all aspects of a conversation in one place. Participants, content, analysis results, attachments, and metadata are all included. You get a complete picture, not fragments scattered across systems.

Interoperability - Because vCon is a standard, different tools can work with the same data. A transcription service, an analysis tool, and a compliance system can all use the same vCon files.

Future-proofing - As new tools and services emerge, they can work with your vCon data because it follows a standard. You are not locked into today's technology choices.

Compliance-ready - The vCon format includes fields for consent tracking, privacy markers, and redaction. You can implement compliance features on top of standard data.

Detailed Use Cases

Here are specific examples of how organizations use MCP servers with vCon for business value:

Contact Centers

Contact centers handle large volumes of customer interactions. They need to track issues, analyze performance, and maintain compliance.

How they use it: The center stores all customer calls in vCon format through an MCP server. Agents and managers can ask AI assistants questions like "What are the top three issues customers called about this month?" or "Show me calls where customers were frustrated."

Value delivered:

• Faster issue identification and resolution

• Better training based on actual customer interactions

• Automated compliance reporting

• Performance analytics without manual data collection

Specific capabilities:

• Search for calls by topic, sentiment, or issue type

• Generate summaries of common problems

• Track resolution rates and customer satisfaction

• Identify training opportunities for agents

Sales Teams

Sales teams have conversations with prospects and customers throughout the sales process. These conversations contain information about needs, objections, timelines, and decision criteria.

How they use it: Sales teams record calls and meetings in vCon format. They tag conversations with deal stages, product names, and customer segments. They can ask AI assistants to extract action items, identify decision makers, or find similar past deals.

Value delivered:

• Better deal tracking and forecasting

• Faster onboarding for new sales team members

• Insights into what messaging works

• Automatic extraction of next steps and commitments

Specific capabilities:

• Search for conversations about specific products or features

• Find similar past deals to inform strategy

• Extract action items and follow-up tasks automatically

• Analyze which approaches lead to closed deals

Compliance and Legal Teams

Legal and compliance teams must maintain records of regulated communications and ensure they meet retention, privacy, and audit requirements.

How they use it: Teams store all regulated communications in vCon format. Plugins add compliance features like automatic retention policy enforcement, consent tracking, and audit logging.

Value delivered:

• Automated compliance with regulations like GDPR, CCPA, and HIPAA

• Complete audit trails for regulatory reviews

• Efficient response to privacy requests

• Reduced risk of compliance violations

Specific capabilities:

• Automatic redaction of sensitive information

• Consent tracking and management

• Retention policy enforcement

• Audit log generation for regulators

Research and Analytics Teams

Research teams collect conversation datasets to study communication patterns, build training data for machine learning, or analyze language use.

How they use it: Teams store research conversations in vCon format, which provides a standard structure for analysis. They can export data in a format that works with analysis tools.

Value delivered:

• Standardized data format across research projects

• Easy integration with analysis tools

• Reproducible research with consistent data structures

• Sharing datasets with other researchers

Specific capabilities:

• Export conversations in standard formats

• Search and filter conversations by research criteria

• Anonymize data for sharing

• Track metadata about research participants

Healthcare Organizations

Healthcare organizations must document patient interactions while maintaining strict privacy and compliance standards.

How they use it: Organizations store patient consultation records in vCon format. Plugins add HIPAA compliance features, access controls, and integration with electronic health record systems.

Value delivered:

• Better documentation of patient interactions

• Compliance with healthcare regulations

• Integration with existing health record systems

• Improved care coordination through accessible records

Specific capabilities:

• Store consultation transcripts and notes

• Link conversations to patient records

• Automatic privacy controls and access restrictions

• Generate clinical summaries automatically

ROI Considerations

Implementing an MCP server with vCon format can provide returns in several areas:

Time savings - Teams spend less time searching for information, exporting data, or switching between systems. AI assistants can answer questions that previously required manual work.

Better decisions - Access to conversation insights leads to better decisions about products, services, processes, and strategy.

Compliance cost reduction - Automated compliance features reduce the manual work and risk associated with meeting regulatory requirements.

Integration cost reduction - Standard formats reduce the cost of integrating conversation data with other systems. Instead of custom integrations for each system, you use standard formats.

Vendor flexibility - Not being locked into a single vendor allows you to choose tools based on what they do best, not just what integrates with your existing system.

Future capability - As new AI tools and services emerge, you can take advantage of them because your data is in a standard format.

When to Use vCon MCP Server vs Alternatives

The vCon MCP Server is a good choice when:

• You need to work with conversation data across multiple systems or tools

• You want AI assistants to access your conversation data

• You value data portability and avoiding vendor lock-in

• You need to meet compliance requirements with conversation data

Alternatives might be better when:

• You only use a single conversation system and do not need integration

• Your conversation volume is very small and does not justify the setup

• You have existing systems that meet all your needs and you do not plan to change

• You need features that are not yet available in the open source version

Implementation Considerations

If you decide to implement the vCon MCP Server, here are things to consider:

Database setup - You will need a Supabase account or self-hosted PostgreSQL database. The free tier works for development and small deployments, but production may require a paid tier.

AI assistant selection - You need an AI assistant that supports MCP. Currently, Claude Desktop supports MCP, with more assistants adding support over time.

Data migration - If you have existing conversation data, you will need to migrate it to vCon format. The server includes tools and examples for this.

Training - Teams need to learn how to work with AI assistants and the vCon format. The learning curve is relatively gentle because you interact in natural language, but some training helps.

Compliance plugins - If you need compliance features, you may need proprietary plugins in addition to the open source server.

Scaling - For large deployments, consider caching with Redis and potentially running multiple server instances. The architecture supports scaling, but you need to plan for it.

Integration - Think about how the server fits into your existing systems. The server works well as part of a larger ecosystem, but you need to plan the integrations.

Getting Started

If you want to try the vCon MCP Server:

1. Set up a Supabase account (free tier works for testing)

2. Install the server following the documentation

3. Connect Claude Desktop or another MCP-compatible assistant

4. Start with a small set of test conversations

The server is open source, so you can evaluate it without commitment. Many organizations start with a pilot project to understand the value before broader deployment.

Conclusion

Conversation data is valuable, but realizing that value requires solving problems of fragmentation, vendor lock-in, and limited access. MCP servers provide a standard way for AI assistants to access conversation data, and the vCon format ensures data portability and completeness.

Organizations use this combination to improve customer service, sales effectiveness, compliance, research, and healthcare documentation. The value comes from better access to insights, automated compliance, reduced integration costs, and future flexibility.

If you want to learn more about implementing the vCon MCP Server, the earlier posts in this series cover the overview, MCP and AI integration, server capabilities, and architecture in detail.

The vCon MCP Server provides over 27 tools that let AI assistants work with conversation data. This post gives you a complete overview of what the server can do, organized by category.

Core Operations: Managing Conversations

The server can create, read, update, and delete conversation records. These are the basic operations you need for managing any conversation data.

Creating Conversations

You can create new conversation records in several ways:

Create from scratch - Provide all the conversation data in vCon format, including participants, dialog content, analysis results, and attachments. The server validates everything to ensure it follows the IETF vCon standard before storing it.

Create from templates - Use predefined templates for common conversation types. The server includes templates for phone calls, chat conversations, email threads, and video meetings. Templates set up the basic structure, and you add the specific details.

When you create a conversation, the server automatically generates a unique identifier if you do not provide one. It also records when the conversation was created and can track when it was last updated.

Reading Conversations

You can retrieve conversations by their unique identifier. The server returns the complete conversation record, including all participants, dialog content, analysis results, and attachments.

You can also request only specific parts of a conversation. For example, you might want just the participant information, or just the analysis results. This is useful when you do not need the entire conversation and want to reduce the amount of data transferred.

The server also provides resources, which are URI-based ways to access conversation data. This lets you access specific parts of conversations directly without going through the full tool interface.

Updating Conversations

You can update the metadata of conversations, such as the subject line or custom extensions. The server supports different update strategies. You can replace existing values, merge new values with existing ones, or append to existing arrays.

Updates are validated to ensure the conversation still follows the vCon standard after changes. This prevents accidental corruption of your data.

Deleting Conversations

You can delete conversations and all their related data. The server requires explicit confirmation to prevent accidental deletions. When you delete a conversation, it removes all associated participants, dialog entries, analysis results, and attachments.

Component Management: Adding Parts to Conversations

A conversation record can have several types of components. You can add or update these components without recreating the entire conversation.

Dialog Entries

Dialog entries are the actual conversation content. This might be a phone call recording, a text chat, an email message, or a video call segment. Each dialog entry includes information about when it occurred, who participated, and the content itself.

The server supports different types of dialog:

• Recordings of audio or video

• Text-based conversations

• Transfers where a call was moved between agents

• Incomplete conversations where the recording was cut off

You can add multiple dialog entries to a single conversation, which is useful for conversations that happened across multiple sessions or channels.

Analysis Results

Analysis results are insights generated by AI or other processing tools. Examples include transcripts of audio recordings, sentiment analysis, summaries, topic extraction, and named entity recognition.

Each analysis entry includes information about what tool created it, what version or model was used, and when it was created. This makes it possible to track how analysis results were generated and compare results from different tools.

The server can store analysis results in different formats. Some might be plain text, while others might be structured JSON data. The server handles both types correctly.

Attachments

Attachments are files or documents related to the conversation. This might be an invoice discussed during a call, a screenshot shared during a chat, or a contract sent via email.

Attachments can be stored in different ways. They can be embedded directly in the conversation record, or they can be referenced by URL if stored elsewhere. The server tracks what type of file each attachment is and can link attachments to specific dialog entries or participants.

Tags are a special type of attachment used for organization, which we will cover in more detail later.

Participant Management

Participants, called parties in the vCon standard, are the people or entities involved in a conversation. Each party has information like name, email address, phone number, role, and organization.

The server lets you add, update, and manage participants. You can link dialog entries and attachments to specific participants, making it easy to see what each person said or contributed.

Search Capabilities: Finding What You Need

The server provides four different ways to search conversations. Each method works better for different types of queries.

Basic Filter Search

Basic filter search lets you find conversations by metadata like subject line, participant names, email addresses, phone numbers, or date ranges. This is the fastest search method and works well when you know specific details about what you are looking for.

For example, you could search for all conversations from last week where a specific customer participated. The search returns complete conversation records that match your criteria.

Keyword Search

Keyword search looks for specific words or phrases within the conversation content. It searches through subject lines, dialog text, analysis results, and participant information. This is useful when you remember a specific word or phrase but do not remember other details about the conversation.

The search uses full-text indexing, which makes it fast even with large numbers of conversations. It also handles minor typos and variations in spelling. Results show snippets of where the keywords were found, making it easy to see the relevant parts.

You can combine keyword search with filters like date ranges or tags to narrow down results.

Semantic Search

Semantic search finds conversations by meaning rather than exact words. It uses AI embeddings to understand what conversations are about and can find related content even when the exact words are different.

For example, if you search for "customer frustration," semantic search might find conversations where customers were "upset," "angry," "disappointed," or "unhappy," even if those exact words were not used. This makes semantic search useful when you are looking for concepts rather than specific phrases.

Semantic search requires that conversations have been processed to generate embeddings. The server can generate these embeddings when conversations are created or updated, or you can process existing conversations in batch.

Hybrid Search

Hybrid search combines keyword search and semantic search. It uses both methods and combines the results, giving you the benefits of both approaches. Keyword search finds exact matches, while semantic search finds conceptually related content.

You can control how much weight each method has in the results. For example, you might want exact keyword matches to rank higher than semantic matches, or vice versa.

Tag System: Organizing Conversations

Tags are key-value pairs that you can attach to conversations for organization and filtering. Tags are flexible. You can use them however makes sense for your workflow.

Adding and Managing Tags

You can add tags individually or in groups. Tags can have string, number, or boolean values. For example, you might tag conversations with department names, priority levels, resolution status, or customer IDs.

The server provides tools to add, update, get, and remove tags. You can also bulk update tags across multiple conversations, which is useful when you need to reorganize or reclassify conversations.

Searching by Tags

All search methods support filtering by tags. You can require conversations to have specific tags, or you can search for conversations that have any of several tags. This makes it easy to narrow down results to the conversations you care about.

For example, you might search for high-priority sales conversations from last month. The tag system makes this type of query simple and fast.

Tag Analytics

The server can analyze your tag usage to show you what tags are used most often, what values are most common, and how tags are distributed across your conversations. This helps you understand how conversations are organized and can guide decisions about tag structure.

Database Analytics: Understanding Your Data

The server provides comprehensive analytics about your conversation database. These tools help you understand what you have, how it is growing, and how it is structured.

Overall Analytics

You can get analytics about database size, growth trends, content distribution, and health metrics. This includes information like total number of conversations, how many have been added over time, what types of content are stored, and how the database is performing.

Growth Analytics

The server can analyze growth patterns over time, showing monthly trends and projections. This helps you understand if your conversation data is growing steadily, if there are seasonal patterns, or if growth is accelerating.

Content Analytics

Content analytics show what types of conversations you have, what types of dialog entries are stored, what analysis has been performed, and how participants are distributed. This helps you understand the composition of your conversation data.

Attachment Analytics

Attachment analytics show what types of files are stored, how much storage they use, and how they are distributed across conversations. This helps you understand storage usage and plan for capacity.

Health Metrics

Health metrics show database performance indicators like query speed, index usage, and cache hit rates. This helps you identify performance issues and optimize your database configuration.

Database Tools: Inspection and Optimization

The server includes tools for inspecting and optimizing your database. These are useful for understanding your database structure and ensuring it performs well.

Database Shape

You can inspect the database structure to see what tables exist, what indexes are defined, how large tables are, and how tables relate to each other. This is useful for understanding the database schema and debugging issues.

Database Statistics

You can get statistics about database usage, including how often tables are accessed, how indexes are being used, and cache performance. This helps identify optimization opportunities.

Smart Limits

For large databases, the server can recommend search limits based on database size. This prevents queries from using too much memory or taking too long. The server analyzes your database and suggests appropriate limits for different types of searches.

Templates and Schemas: Working with Standards

The server includes support for templates and schemas that make it easier to work with the vCon standard.

Templates

Templates provide pre-configured structures for common conversation types. Instead of building everything from scratch, you can start with a template and fill in the specifics. This reduces errors and speeds up creation of new conversation records.

The server includes templates for phone calls, chat conversations, email threads, video meetings, and custom scenarios.

Schemas

You can request the vCon schema in different formats, including JSON Schema and TypeScript types. This is useful when building integrations or writing code that works with vCon data. The schema shows exactly what fields are required, what fields are optional, and what types of values are allowed.

Examples

The server can provide example vCon records in different formats. Examples include minimal records, phone calls, chat conversations, emails, video meetings, and full-featured records. These examples serve as references when creating your own conversations.

Plugin Architecture: Extending the Server

The server supports plugins that can add custom functionality. Plugins can:

• Add new tools that the assistant can use

• Add new resources for data access

• Intercept operations to add custom logic

• Implement privacy and compliance features

Plugins use hooks that fire at different points in the request lifecycle. For example, a plugin might run code before a conversation is created, after it is created, before it is read, or after it is updated. This lets plugins add logging, access control, data transformation, or other functionality.

The core server focuses on standard conversation management. Plugins extend it for specific needs like compliance, privacy, or integrations.

What is Included vs What is Not

The server is open source and includes all the features described above. However, some advanced features are available only through proprietary plugins.

Included in Open Source

The open source version includes:

• Complete CRUD operations for conversations

• All four search modes

• Tag management

• Component management

Available Through Plugins

Advanced features available through plugins include:

• Consent management and tracking

• Privacy request handling for regulations like GDPR and CCPA

• Automatic compliance checking

• Advanced audit logging

The open source version is fully functional for general conversation data management. The proprietary plugins add features needed for regulated industries or strict compliance requirements.

Practical Examples

Here are some practical examples of how you might use these features:

Example 1: Customer Support Team A support team uses the server to store all customer calls. They tag conversations with issue types, customer IDs, and resolution status. They use semantic search to find similar past issues when helping customers. They add analysis results that include transcripts and sentiment scores.

Example 2: Sales Team A sales team records all sales calls and meetings. They tag conversations with product names, deal stages, and customer segments. They use keyword search to find conversations where specific products were discussed. They generate summaries automatically and attach them as analysis results.

Example 3: Compliance Team A compliance team stores all regulated communications. They use tags to track consent status and retention periods. They use database analytics to monitor data growth and ensure compliance with retention policies. They use plugins to add automatic compliance checking and audit logging.

Example 4: Research Team A research team collects conversation datasets for analysis. They use the server to store conversations in a standard format that works across different tools. They use semantic search to find conversations by research themes. They export data for use in machine learning pipelines.

Integration Points

The server integrates with several systems:

Supabase - The database backend. Supabase provides PostgreSQL with additional features like real-time subscriptions and REST APIs.

Redis - Optional caching layer. Redis can be added to dramatically speed up reads of frequently accessed conversations.

OpenAI - Optional for semantic search. The server can use OpenAI's API to generate embeddings for semantic search, though local models can also be used.

AI Assistants - Any assistant that supports MCP can connect to the server. Currently this includes Claude Desktop, with more assistants adding support over time.

Conclusion

The vCon MCP Server provides a comprehensive set of tools for managing conversation data. It covers the basics of creating and managing conversations, advanced search capabilities, organization through tags, analytics for understanding your data, and extensibility through plugins.

The next post in this series covers the architecture of the server, explaining how it is built and why it is designed the way it is.

Available Links

vCon

A vCon is the container for data and information relating to a real-time, human conversation. It is analogous to a [] which enables the definition, interchange and storage of an individual's various points of contact. The data contained in a vCon may be derived from any multimedia session, traditional phone call, video conference, SMS or MMS message exchange, webchat or email thread. The data in the container relating to the conversation may include Call Detail Records (CDR), call meta data, participant identity information (e.g. STIR PASSporT), the actual conversational data exchanged (e.g. audio, video, text), realtime or post conversational analysis and attachments of files exchanged during the conversation. A standardized conversation container enables many applications, establishes a common method of storage and interchange, and supports identity, privacy and security efforts

Introduction

In an era where conversational data represents one of the most valuable yet challenging assets for enterprises, the Conserver platform emerges as a critical infrastructure component that bridges the gap between raw communication data and actionable intelligence. Built upon the open vCon (Virtual Conversation) standard, Conservers provide organizations with unprecedented operational flexibility in how they capture, process, analyze, and manage conversation data while maintaining strict security and compliance requirements.

The operational benefits of Conservers extend far beyond simple conversation recording or transcription. They represent a fundamental shift in how organizations can architect their conversation intelligence infrastructure, offering the flexibility to adapt to diverse deployment requirements, security constraints, and processing needs while maintaining a consistent, standardized approach to conversation data management.

The vCon ecosystem includes two main components: the MCP server and the conserver. They serve different purposes but work together to create a complete system for managing conversation data. This post explains what each does, how they differ, and how they combine with Redis and Supabase to optimize performance.

Two Different Roles

The MCP server and conserver solve different problems in the vCon ecosystem.

The MCP server is a storage and query system. It provides an interface for AI assistants to work with conversation data. It focuses on storing, searching, and retrieving vCons through the Model Context Protocol.

The vCon MCP Server is built in layers, with each layer handling a specific responsibility. This architecture makes the server reliable, performant, and extensible. This post explains how it works.

The Three-Layer Architecture

The server has three main layers:

MCP Server Layer - Handles communication with AI assistants using the Model Context Protocol. This layer exposes tools, resources, and prompts that assistants can use.

Business Logic Layer - Contains the core functionality for managing conversations. This includes query engines, validation, and plugin systems.

Database Layer