Skip to content
RasaGet a free licence
Menu

tutorial

Chapter 0 of 5

Move a customer-service assistant from REST tools to MCP

by Rod Rivera Published

Move a CRM assistant’s tools to an MCP server while retaining its customer-service instructions.

Your CRM assistant identifies customers, checks support tickets and records interactions. Today its Python tools call the CRM through REST. Model Context Protocol (MCP) lets an assistant discover and call tools exposed by a server. You want to move those CRM tools behind that connection without rewriting the customer-service instructions.

In this series, you will adapt the fictional Ora assistant and compare its skill instructions before and after the change. You will also test a local MCP connection. Keeping the skill text unchanged does not mean the tool schemas or model behaviour are unchanged.

The earlier transport plan

The older README below describes the plan before Mantle had a working MCP runtime. It is quoted as historical context:

HubSpot also exposes an MCP server, and Mantle has an `mcp_servers:` block in
`integrations.yml`. In `3.19.0.dev7` that block is parsed but has no runtime
consumer yet — the Mantle engine never connects to it — so this tutorial uses
REST. When MCP lands, the same three skills can keep their instructions and
swap `tools/crm.py` for imported remote tools.

The following chapters check that specific promise against the working MCP variant.

What you will end up with

The same agent, with its transport replaced and its instructions untouched, and a script that fails if that ever stops being true:

  1. skill instructions are unchanged by the swap
  ✓ check_tickets: only import_tools differs     2 changed line(s)
  ✓ check_tickets: instruction body byte-identical 687 bytes
  ✓ identify_customer: only import_tools differs 2 changed line(s)
  ✓ identify_customer: instruction body byte-identical 804 bytes
  ✓ log_interaction: only import_tools differs   2 changed line(s)
  ✓ log_interaction: instruction body byte-identical 1226 bytes

  The transport changed. The instructions did not.

No licence, no API key, no HubSpot account. The whole chapter runs on loopback.

The five chapters

  1. The promise, and how to check it — read the claim as a test, and get the proof failing before it passes.
  2. Swapping the transport — mcp_servers:, import_tools: mcp/<server>:<tool>, and the three-line diff.
  3. What MCP takes away — no tool context, no stdio, and a failure that arrives after training rather than during it.
  4. What survives anyway — why the confirmation constraint still fires against a remote tool.
  5. Shaping the answer for the channel — the narrowest channel decides the shape, and it is a skill decision, not a transport one.

What you need first

This chapter extends a tutorial that already works. Build Ora over REST first, or at least clone it and read the three skills — the swap is only visible against something that already ran.

That is not a formality. A from-scratch MCP tutorial cannot teach this, because “the instructions did not change” needs a before.