Is an MCP server a drop-in replacement for your tools?

You are moving your agent’s CRM tools onto an MCP server. MCP, the Model Context Protocol, lets an agent call tools that run on a separate server. The pull request is small. It adds a server entry to the config. Two skills gain an import_tools entry that points at the server, and the third has its import line rewritten. The old tool code is moved aside.

It also comes with a proof script, and the proof passes. This is part of its output, trimmed:

  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

  The transport changed. The instructions did not.

Can you approve it as an ordinary config change? Not yet. First list the arguments each new tool requires, and decide for each customer id where it may come from. That matters if a tool reads or writes a customer’s record. A wrong id there can mean a tool returns another customer’s tickets, or writes a note on another customer’s record.

In the example below, two of the three tools changed this way.

Why the passing proof is not enough

In Rasa, an agent’s tasks live in skills. A skill is a folder with the model’s instructions in skill.md, plus the tools that task uses. Project memory is where the agent keeps values such as the identified customer’s id.

Before the swap, the tools were local Python tools in the project. The lookup tool found the caller by email and wrote their customer id into project memory. The ticket tool and the note tool read the id from there. This excerpt is the start of the ticket tool, from skills/check_tickets/tools.py:

async def list_open_tickets(context: ToolContext = None) -> ToolResult:
    """Read the caller's tickets from the CRM."""
    contact_id = context.memory.get("project.contact_id") if context else None

An MCP tool cannot read project memory. A local tool receives a ToolContext, the object that gives it memory access. An MCP tool does not, so the id has to arrive as an argument. The companion’s README says the model “fills it from the conversation”. This excerpt is the same tool on the companion’s MCP server, scripts/mcp_crm_server.py:

@mcp.tool(description="List the support tickets on the identified customer's account.")
async def list_open_tickets(contact_id: str) -> CrmResult:
    """Read the caller's tickets from the CRM.

    Args:
        contact_id: HubSpot contact id of the identified customer.
    """
    # `contact_id` is a PARAMETER here, not a memory read. An MCP tool has no
    # ToolContext, so the value has to travel as an argument. See the README
    # section "What MCP does not do for you".
    if not contact_id:
        return CrmResult(ok=False, error="not_identified")

The note tool changed the same way. Locally it took only the note text. Over MCP it takes the customer id too.

This is the pattern to look for. When a value that used to come from server-held state now arrives as a tool argument the model fills in, it has moved to the model’s side of the trust boundary.

What a different id does

We called the companion’s MCP tools directly, with no model and no conversation. The script identifies the caller as Sam Rivera, then passes Dana Okafor’s id, 701, to the ticket and note tools. Both servers were the companion’s local mocks. The output, unedited:

$ uv run python scripts/call_with_other_id.py 2>/dev/null
call_tool find_contact_by_email {'email': 'sam.rivera@example.com'}
  -> {'ok': True, 'contact_id': '702', 'name': 'Sam Rivera', 'company': 'Rivera Foods'}
call_tool list_open_tickets {'contact_id': '702'}
  -> {'ok': True, 'count': 0, 'tickets': []}
call_tool list_open_tickets {'contact_id': '701'}
  -> {'ok': True, 'count': 2, 'tickets': [{'id': '9001', 'subject': 'Invoice 4471 shows the wrong VAT rate', 'stage': 'waiting_on_us', 'created': '2026-08-11'}, {'id': '9002', 'subject': 'Add a second admin to the account', 'stage': 'waiting_on_contact', 'created': '2026-08-19'}]}
call_tool add_timeline_note {'contact_id': '701', 'summary': 'Sam asked to close his account.'}
  -> {'ok': True, 'note_id': '10000'}
mock CRM stored note 10000: body='Sam asked to close his account.' on contact ['701']

The ticket tool returned Dana’s tickets, and the note about Sam was stored on Dana’s record. This shows what the tools do with a given id, not that a model would pass the wrong one.

What the proof checked instead

The proof’s first check finds each skill’s instructions byte-identical. So the MCP version of skills/check_tickets/skill.md still says this:

Call `list_open_tickets`. It reads the identified customer from project memory,
so it is the authority on whether the caller has been identified yet.

The memory read that sentence describes was in a file the swap moved aside. The proof checked that the sentence survived, not that it is still true.

The proof is also looser than it looks on the settings block at the top of each skill file. It accepts any changed settings line that starts with - , whatever it sits under. We moved the note skill’s confirmation rule from the write tool to the ticket tool with a one-line change. Our diff, unedited:

@@ -6,7 +6,7 @@
 import_tools:
   - mcp/hubspot_crm:add_timeline_note
 tool_constraints:
-  - add_timeline_note:
+  - list_open_tickets:
       requires_confirmation:
         enabled: true
         utter_for_confirmation: utter_confirm_note

The proof still reported every check green and exited with status 0.

How to check your own swap

Do this for every tool your agent will call over MCP. In your own project, the files are the skill files that gain an import_tools entry, the integrations file and the local tool code the swap removes.

git clone https://github.com/RasaHQ/rasa-community-resources.git
cd rasa-community-resources
git checkout 69e27b6
cd tutorials/rasa-hubspot-crm-tutorial

$ uv run python -c 'import asyncio, scripts.mcp_crm_server as s
for t in asyncio.run(s.mcp.list_tools()): print(t.name, "requires", t.inputSchema["required"])' 2>/dev/null
find_contact_by_email requires ['email']
list_open_tickets requires ['contact_id']
add_timeline_note requires ['contact_id', 'summary']

  - id: write_note
    execute_tool: add_timeline_note
    parameters:
      summary: session.log_interaction.note_summary

write_note step as shipped: {'summary': 'Dana asked about invoice 4471.'}
  -> {"error": "Invalid tool arguments: Missing required argument(s): 'contact_id'.", "retryable": true, "code": "invalid_arguments"}
with contact_id added: {'contact_id': '101', 'summary': 'Dana asked about invoice 4471.'}
  -> None

How to check the fix works

Run the proof. It checks the instruction text and the mock server, not the ids. The full output is folded at the end of this page.

Start the agent against the real server. Use the same server name and import lines, outside production. In the Rasa Pro 3.20.0rc1 source, loading the model does not check whether the server offers each imported tool. That check runs when the agent starts and connects. A missing tool raises this error, quoted from rasa/mantle/tools/mcp_runtime.py as an excerpt:

            if tool_schema is None:
                raise ValueError(
                    f"MCP server {reference.server_id!r} does not expose imported "
                    f"tool {reference.tool_name!r} for skill {skill_id!r}."
                )

In the same source, Rasa then stops loading the agent rather than return one without its MCP tools.

The error is loud, but it comes after the proof has passed.

Test the conversation. Write tests where the caller gives one email and then names another customer. The companion has no test files, so this is new work.

Read the settings diff yourself. The proof accepts a confirmation rule moved to the wrong tool. Check each tool_constraints entry by eye.

Who reviews what

This guide recommends splitting the work. Each id decision needs a reviewer who did not write the diff; your organisation decides who. If you scoped the workflow with a written boundary, as in choosing an agent workflow worth building, check that boundary against the tools here. For the companion:

Limits

• This covers one companion project and its local mock. It says nothing about how any vendor’s MCP server behaves.
• It asks one question: where each id comes from. It is not a security review of the vendor, the transport or the data.
• Neither version checks that the caller owns the email they give.
• The direct tool calls show what the tools do with a given id. The Rasa behaviour at agent start and after a failed step comes from reading the source. We made no live run, so whether a model passes the right id is untested.
• The CRM transport swap tutorial is the engineer’s walkthrough of this swap. Its chapters 3 to 5 say the swap keeps the instructions working and moves one tool’s id. The evidence here shows two tools’ ids moved, one of them a write.

Questions you may hear

  Proving: the same three skills keep their instructions while
  tools/crm.py is replaced by import_tools: mcp/<server>:<tool>.
  No licence, no API key, no HubSpot account, loopback only.

  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

  2. integrations.yml parses as MCP server configuration
  ✓ parse_mcp_servers accepts the file           servers: ['hubspot_crm']
  ✓ server url is loopback http                  http://127.0.0.1:8931/mcp

  3. each skill's import parses as mcp/<server>:<tool>
  ✓ check_tickets imports list_open_tickets      server=hubspot_crm llm sees 'list_open_tickets'
  ✓ identify_customer imports find_contact_by_email server=hubspot_crm llm sees 'find_contact_by_email'
  ✓ log_interaction imports add_timeline_note    server=hubspot_crm llm sees 'add_timeline_note'

  4. every imported server is configured
  ✓ no skill imports an unconfigured server      ['hubspot_crm'] ⊆ ['hubspot_crm']

  5. the MCP server exposes the imported tools
  ✓ server exposes list_open_tickets             imported by check_tickets
  ✓ server exposes find_contact_by_email         imported by identify_customer
  ✓ server exposes add_timeline_note             imported by log_interaction

  6. a tool call over MCP returns the CRM fact
  ✓ result is structured, not text blocks        outputSchema published
  ✓ find_contact_by_email over MCP               Dana Okafor at Okafor Logistics
  ✓ absent contact is not an error               error=contact_not_found

  The transport changed. The instructions did not.

import asyncio, os, socket, subprocess, sys, threading, time
from http.server import HTTPServer

ROOT = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
sys.path.insert(0, ROOT)
import scripts.mock_hubspot as crm  # the bundled mock CRM, run in this process
from mcp import ClientSession
from mcp.client.streamable_http import streamablehttp_client

def wait(port):
    for _ in range(100):
        try:
            socket.create_connection(("127.0.0.1", port), timeout=0.5).close(); return
        except OSError:
            time.sleep(0.15)
    raise SystemExit(f"port {port} did not open")

async def main():
    async with streamablehttp_client("http://127.0.0.1:8931/mcp") as (r, w, _):
        async with ClientSession(r, w) as s:
            await s.initialize()
            async def call(name, args):
                res = await s.call_tool(name, args)
                print(f"call_tool {name} {args}")
                print(f"  -> {res.structuredContent}")
                return res.structuredContent
            who = await call("find_contact_by_email", {"email": "sam.rivera@example.com"})
            other = "701"  # Dana Okafor's contact id in the mock CRM, not the caller's
            await call("list_open_tickets", {"contact_id": who["contact_id"]})
            await call("list_open_tickets", {"contact_id": other})
            await call("add_timeline_note", {"contact_id": other, "summary": "Sam asked to close his account."})
    for note in crm.NOTES:
        p = note["payload"]
        print(f"mock CRM stored note {note['id']}: body={p['properties']['hs_note_body']!r} "
              f"on contact {[a['to']['id'] for a in p['associations']]}")

server = HTTPServer((crm.HOST, crm.PORT), crm.Handler)
threading.Thread(target=server.serve_forever, daemon=True).start()
env = {"HOME": os.environ["HOME"], "PATH": os.environ["PATH"],
       "HUBSPOT_BASE_URL": f"http://{crm.HOST}:{crm.PORT}", "HUBSPOT_ACCESS_TOKEN": "mock-token"}
mcp_proc = subprocess.Popen([sys.executable, os.path.join(ROOT, "scripts/mcp_crm_server.py")],
                            env=env, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
try:
    wait(8931); asyncio.run(main())
finally:
    mcp_proc.terminate(); mcp_proc.wait(timeout=5); server.shutdown()

env -i HOME=$HOME PATH=/usr/bin:/bin:$(dirname $(command -v uv)) uv run python scripts/call_with_other_id.py 2>/dev/null