Connecting real apps to AI agents with the Model Context Protocol

A chat window inside an app is useful. It is even more useful when the AI agent you already use (Claude Desktop, Cursor or another client) can work with that app directly. That is what the Model Context Protocol (MCP) is for, and both CVolve and Plate Plan include an MCP server.

What MCP is

MCP is an open protocol that lets AI applications discover and use tools from other software in a standard way. An app exposes an MCP server. An AI client connects to it, asks which tools exist, and calls them when the conversation needs them.

You do not have to write one integration for Claude Desktop, another for Cursor and a third for the next client. You write one server, and every MCP client can use it.

Smaller than you think

MCP is built on JSON-RPC 2.0. A tools-only server needs to answer a handful of methods:

Both of our servers are written in plain PHP, without an SDK. CVolve's core server class is about 120 lines. A call from an agent looks like this:

{"jsonrpc": "2.0", "id": 7, "method": "tools/call",
 "params": {"name": "add_to_plan", "arguments": {"day_of_week": 3, "meal_id": 12, "meal_type": "dinner"}}}

The server runs the tool and returns the result as text and as structured content, which the agent then reads.

Plate Plan: a small, readable example

Plate Plan exposes ten tools at /mcp.php, including get_meals, create_meal, get_weekly_plan, add_to_plan, change_meal_on_day, clear_day, get_grocery_list and evaluate_weekly_plan. Connect it to Claude Desktop and you can say "plan next week around fish twice and no red meat, then give me the shopping list" and watch the board fill in.

Because Plate Plan has no framework and no login, it is a good codebase to read if you want to see how MCP works from end to end.

CVolve: one toolbox, two doors

CVolve's MCP server lives at /mcp, uses the streamable HTTP transport and is secured with personal API tokens sent as a Bearer header. It supports protocol versions 2025-06-18, 2025-03-26 and 2024-11-05.

The most important design decision is that the MCP server does not have its own tools. It reuses the same CvToolbox as the AI assistant inside the CVolve editor: get_cv, tailor_to_job_description, translate_cv, check_cv, export_cv and the rest of its 24 tools.

This gives us one important guarantee: the same rules apply everywhere. Tools that change a CV never write directly. They create a proposal, and the person reviews the diff in CVolve and chooses Apply or Discard. An external agent cannot do anything the in-app assistant cannot do.

Safety rules we follow

Letting an AI agent act on real data needs care. These are the rules we built into both projects:

1. Changes are proposals. In CVolve, an agent can suggest a new summary but cannot apply it. The person stays in control.
2. Authenticate every call. CVolve's tokens are personal, can be revoked, and act only as their owner.
3. Defend local servers too. Plate Plan has no login because it is meant to run on your own machine. That is exactly why it checks the Host header (against DNS rebinding) and the Origin and Sec-Fetch-Site headers (against cross-site requests). A website open in your browser cannot use your local Plate Plan, while MCP clients and curl, which send no browser headers, still work.
4. Describe tools honestly. Tool descriptions tell the agent what each tool does, including when it uses the app's own AI provider. Clear descriptions lead to fewer wrong calls.

Takeaway

MCP turns an application into something any AI agent can use, and a useful server can be very small. The hard part is not the protocol. The hard part is deciding what an agent is allowed to do. Design that first, share the rules with your in-app assistant, and the rest is a few hundred lines of code.

Both projects are open source under the MIT License. Try connecting them to your favourite MCP client.