What is the Model Context Protocol (MCP)?

How does the Model Context Protocol work?

MCP has three roles. The host is the AI application, such as a coding assistant or a chat app. Inside it, one MCP client holds the connection to each MCP server, and the servers provide the capabilities. Every message is a JSON-RPC 2.0 request, response or notification, so all clients and servers share one format.

Servers offer three kinds of capability. Tools are functions the model can decide to call, resources are data that gives the model context, such as files or database schemas, and prompts are reusable instruction templates. A client asks what a server offers, for example with tools/list, then runs a tool with tools/call.

Messages travel over one of two transports. A local server runs on the same machine and uses standard input and output (stdio). A remote server runs on the web and uses Streamable HTTP, where the client POSTs each message to one endpoint. In the current version of the specification, 2026-07-28, each request is stateless and carries everything the server needs.

For example, with a calendar server connected, an assistant asked to book a meeting can read your calendar as a resource, then call a tool to create the event, without a custom integration between that assistant and the calendar.

Why does MCP matter for a website voice agent?

MCP can sit on either side of a voice agent. A voice agent that acts as an MCP client can call tools during a conversation, such as a lookup in your own systems. A voice agent product that runs its own MCP server lets a coding agent set it up and maintain it from the editor where your team already works.

Because every action is a named tool, MCP also makes access easier to see and limit. The specification says hosts must get the user’s consent before they invoke any tool, and that tool descriptions from servers you don’t trust should be treated as untrusted.

How Kawl Now uses MCP

Kawl Now runs a remote MCP server at https://app.kawlnow.com/api/mcp for managing your workspace, not for use during calls. With a workspace token, a coding agent can read your settings, usage and automatic insights, change either agent’s greeting, instructions, voice and allowed origins, switch customer calls on or off, add knowledge, import a GitHub document, list recent conversations and fetch the embed code. It can also turn on human handover, an early release, for a team phone number you’ve already verified. Only the signed-in dashboard can verify or change that number.

Knowledge a coding agent adds is always saved unapproved. Approving it is a separate tool, approve_knowledge, which you can keep for a person if your MCP client lets you block a tool. Settings changes apply straight away, so review those too.

The voice agent itself doesn’t connect to MCP servers during calls and can’t call tools in your own systems. It answers from the knowledge your team has approved. Automated tests cover the protocol rather than named clients, so check the connection in your own client first.

Common questions