In the last few articles, we have been gradually building up a ColdFusion AI assistant without giving it enough rope to rappel into production and start making architectural decisions.

We started with the vocabulary: LLMs, prompts, tokens, context windows, temperature, hallucinations, memory, tools, RAG, MCP, and guardrails.

Then we built the ColdFusion AI version of “Hello World” with ChatModel(). Send a prompt. Get a response. Display response.message. Nice and simple.

After that, we introduced Agent() and memory. The assistant could finally remember what the user had just said, maintain short-term conversation context, and stop behaving like every request was being shouted at it from a different parking lot.

Then we added CFC tools. That was a major upgrade. Instead of guessing ticket status, order status, registration status, or other application-specific facts, the assistant could request controlled access to ColdFusion methods. The AI could ask. ColdFusion could validate, authorize, execute, and decide.

That got us to this point:

ChatModel()
	Good for simple, stateless prompts.

Agent() with memory
	Good for multi-turn conversations and per-user context.

Agent() with CFC tools
	Good for letting the AI request capabilities inside your ColdFusion application.

Now we move to the next layer:

Agent() with MCP
	Good for connecting AI workflows to tools, prompts, and resources through a standard protocol.

This article is about adding MCP. And yes, it is another acronym. Sorry. At this point, AI development has enough acronyms to qualify as a government department.

What problem does MCP solve?

CFC tools are great when the thing you want the AI to use lives inside your ColdFusion application. For example:

getTicketStatus( ticketId )
calculateCartTotal( cartId )
listUpcomingEvents( userId )
createSupportTicket( summary, priority )

Those are local application capabilities. You own the code. You can expose specific CFC methods to the agent. You can validate arguments and enforce authorization inside the tool. That is a good pattern. But what happens when the thing the AI needs is not local? What if the assistant needs to talk to:

• Jira
• Confluence
• GitHub
• Slack
• an internal wiki
• a reporting service
• a document system
• another ColdFusion application
• a shared enterprise tool server
• a service owned by another team that already has strong opinions and three architecture diagrams

You could write one-off integrations for each system. You could build custom wrappers. You could invent your own tool discovery format. You could email another team and ask them for documentation, then wait six months and receive a PDF last updated during the jQuery era.

Or you could use a standard protocol. That is where MCP comes in.

MCP, or Model Context Protocol, gives AI clients and external systems a consistent way to communicate. Adobe describes MCP as the protocol AI agents use to communicate with external systems in a consistent, auditable way. It standardizes tool discovery and invocation, prompt management, resource access, and optional flows such as sampling, elicitation, logging, and roots. (guides.adobe.com)

In plain English: “MCP is a standard way for AI applications to discover and use tools, prompts, and resources outside the immediate application.”

Or, even more plainly: “CFC tools let the robot use your app. MCP lets the robot use other systems without every integration becoming a bespoke snowflake.”

A quick mental model

Think of MCP as a contract between two sides. On one side, you have an AI host or client. On the other side, you have an MCP server. The client asks:

What tools do you have?

The server responds:

I have these tools:
- getTicketStatus
- searchDocs
- createIssue

The client asks:

Can you call searchDocs with this query?

The server responds:

Here are the results.

That is the basic idea. MCP standardizes that conversation. The client does not need to know the implementation details of the server. It does not need to know whether the server is written in ColdFusion, Node, Python, Java, Go, or whatever language someone used after saying, “This will only be a small service.” It just needs to speak MCP.

The three roles: host, client, and server

Adobe’s docs describe three primary MCP roles: host, client, and server. ColdFusion can participate in more than one role. (guides.adobe.com) Let’s translate those into developer terms.

MCP host

The host is the outer application that manages the user experience.

It usually owns:

• the UI
• the conversation
• the LLM interaction
• user sessions
• when to call tools
• what to show the user

Examples of hosts include applications like Claude Desktop, Cursor, or a ColdFusion web application that maintains user sessions and calls MCP tools as needed.

In our series, your ColdFusion application can be the host. It has the page, the session, the user ID, the authentication state, the conversation flow, and the deeply unfair responsibility of making everything look easy.

MCP client

The MCP client is the protocol adapter. It knows how to communicate with MCP servers over supported transports such as HTTP or STDIO. Adobe’s docs describe MCPClient(configData) as the primary way to create MCP clients in ColdFusion. The MCP client exposes ColdFusion-friendly methods such as listTools(), callTool(), listResources(), readResource(), listPrompts(), and getPrompt(). (guides.adobe.com)

In plain English: The MCP client is how your ColdFusion app talks to an MCP server. It performs the handshake, handles the protocol details, and gives your CFML code methods that feel like normal application calls instead of raw protocol wrestling. That is good because most of us have enough JSON-RPC in our lives already.

MCP server

The MCP server provides capabilities. It may expose:

• tools
• prompts
• resources

Adobe’s docs describe the MCP server as the provider of capabilities. It may wrap external APIs, file systems, or ColdFusion CFCs, and it receives standardized MCP methods such as tools/list, tools/call, and prompts/get. ColdFusion creates MCP servers using MCPServer(configData). (guides.adobe.com)

In plain English: The MCP server is the thing offering useful stuff to AI clients. That useful stuff may be:

• “search our knowledge base”
• “create a Jira issue”
• “read this approved resource”
• “return this reusable prompt”
• “call this ColdFusion service method”
• “summarize this internal report”
• “fetch deployment status”

The MCP server is where capabilities live. The MCP client is how your app reaches them. The host is the application coordinating the experience.

ColdFusion can be the client, the server, or both

This is the important ColdFusion-specific part. ColdFusion 2025 Update 8 supports MCP in both directions: client and server. (guides.adobe.com) That means your ColdFusion application can do two different things.

First, it can call MCP servers. For example, your ColdFusion AI assistant might connect to a Jira MCP server, list available tools, and call a tool to look up issue status.

Second, it can expose an MCP server. For example, your ColdFusion application might expose carefully selected CFC methods as MCP tools so another MCP host can use them.

And third, in real enterprise fashion, it can do both. Because apparently one direction was too merciful.

Client mode: ColdFusion calls an MCP server

Use the MCP client when your ColdFusion application needs to consume tools, prompts, or resources exposed by another MCP server.

Typical flow:

1. Create an MCPClient with transport configuration.
2. Call listTools() to discover available tools.
3. Call callTool() to invoke a tool.
4. Optionally call listResources(), readResource(), listPrompts(), or getPrompt().

That flow comes directly from Adobe’s MCP overview. (guides.adobe.com) Conceptually, the code looks like this:

<cfscript>
mcpClient = MCPClient( {
	transport : {
		type : "http",
		url : "https://mcp.example.com/mcp"
	}
} );

tools = mcpClient.listTools();

writeDump( var = tools, label = "Available MCP tools" );
</cfscript>

Then, once you know the tool you want:

<cfscript>
result = mcpClient.callTool(
	name = "getIssueStatus",
	arguments = {
		issueKey : "APP-1234"
	}
);

writeDump( var = result, label = "MCP tool result" );
</cfscript>

The exact configuration shape depends on the MCP server and transport you are using, so check the ColdFusion docs and the server’s own requirements before wiring this into production. The important idea is the pattern: Discover > Call > Handle the result. Do not guess what the remote server exposes. Ask it. That is one of the practical benefits of MCP. The tool list comes from the server. Your application does not need to hardcode every detail about every possible capability up front.

Although, because we are developers, we will still find creative ways to hardcode things we should not. Tradition matters.

Server mode: ColdFusion exposes an MCP server

Use the MCP server when your ColdFusion application should expose capabilities to external MCP clients. Typical flow:

1. Create an MCPServer with server info, capabilities, and tool/prompt/resource definitions.
2. Register CFCs as tools.
3. Define prompts and resources as needed.
4. Expose an HTTP endpoint that delegates to application.mcpServer.handleRequest().
5. External MCP clients connect to your server.

Adobe’s MCP overview describes that exact flow for using ColdFusion as an MCP server. Conceptually, your application startup might initialize the server:

<cfscript>
application.mcpServer = MCPServer( {
	serverInfo : {
		name : "Support Tools",
		version : "1.0.0"
	},
	capabilities : {
		tools : true,
		resources : true,
		prompts : true
	},
	tools : [
		{
			cfc : "tools.SupportTool",
			methods : [
				{
					method : "getTicketStatus",
					description : "Get the current status of a support ticket by ticket ID."
				}
			]
		}
	]
} );
</cfscript>

Then your endpoint delegates incoming MCP requests:

<cfscript>
result = application.mcpServer.handleRequest(
	requestBody = getHttpRequestData().content
);

cfcontent(
	type = "application/json",
	reset = true
);

writeOutput( serializeJSON( result ) );
</cfscript>

This is not intended to be a complete drop-in production server. It is a conceptual shape. The details depend on your exact ColdFusion version, transport, authentication model, and how your endpoint receives and returns MCP payloads.

The architectural point is: The MCP server wraps your approved capabilities and exposes them through a standard protocol. That means external AI hosts can discover your tools, call them, read approved resources, or retrieve prompt templates without being given unrestricted access to your application.

That is the whole point.

Not “the robot gets everything.” More like, “Here is the reception desk. Ask politely. Sign in. Stay out of the server room.”

Application scope lifecycle matters

An MCP server should not be recreated randomly on every request.

Adobe’s lifecycle guidance says that once initialized, your MCP server should live for the full lifetime of the ColdFusion application. That allows tools and prompts to be loaded once, preserves server state and caches, and lets clients assume the server is available while the app is running. Adobe also describes the common pattern of storing the shared MCP server instance in application.mcpServer.

That fits the way ColdFusion developers already think about application-level services. A typical pattern belongs in Application.cfc:

component {

	this.name = "McpDemoApplication";
	this.sessionManagement = true;

	public boolean function onApplicationStart() {
		application.mcpServer = MCPServer( {
			serverInfo : {
				name : "ColdFusion Support MCP",
				version : "1.0.0"
			},
			capabilities : {
				tools : true,
				resources : true,
				prompts : true
			},
			tools : [
				{
					cfc : "tools.SupportTool",
					methods : [
						{
							method : "getTicketStatus",
							description : "Get the current status of a support ticket by ticket ID."
						}
					]
				}
			]
		} );

		return true;
	}
}

That gives your MCP server a clear lifecycle. On application start, build it. During the application lifetime, use it. On application restart, rebuild it.

If your server opens external resources, spawns local processes, or needs cleanup, add an appropriate shutdown hook in onApplicationEnd(). Adobe’s lifecycle docs specifically call out that shutdown cleanup may be needed for servers that open external resources, files, background tasks, or local processes.

MCP tools versus CFC tools

This is the section that will save future confusion. CFC tools and MCP tools are related, but they are not the same thing.

CFC tools

CFC tools are local to your ColdFusion application’s agent. You register a CFC directly on Agent(). The agent can request those methods. Your ColdFusion application inspects toolExecutionRequests, validates arguments, executes the CFC, and handles the result.

Use CFC tools when:

• the tool lives inside the current application
• only this application needs it
• you want the simplest possible integration
• you do not need tool discovery across systems
• you do not need other AI hosts to consume it

This is what we covered in the previous article.

MCP tools

MCP tools are exposed through an MCP server and consumed through an MCP client. Use MCP tools when:

• tools live outside the current application
• multiple applications or AI hosts need the same tools
• tool discovery matters
• prompts or resources should also be shared
• you want a protocol boundary
• governance and auditability matter
• the tool provider and the tool consumer are different systems

CFC tools are like calling a method inside your own house. MCP is like giving other houses a front door, a doorbell, and a guest policy. Do not confuse that with giving them a key to the basement.

Tools, prompts, and resources

CFC tools mostly focus on callable methods. MCP is broader. It standardizes three major categories: tools, prompts, and resources. Adobe’s MCP overview specifically lists tool discovery/invocation, prompt management, and resource access as standardized MCP capabilities.

Let’s translate those.

Tools

Tools do things. For example:

• get ticket status
• search issues
• calculate shipping
• create support ticket
• fetch account summary
• list deployments
• validate registration eligibility

Tools may read data or change data. As usual, write tools need more caution. If the tool changes the world, require authorization, validation, logging, and probably confirmation. The robot does not get to click “Send all invoices” because it looked confident.

Prompts

Prompts are reusable prompt templates. For examples:

• summarize a support case
• draft a release note
• turn logs into an incident summary
• explain an error to a non-technical user
• generate a migration checklist

A prompt exposed by an MCP server lets multiple clients reuse the same carefully designed instruction. That is useful because prompt drift is real. Without shared prompts, every team eventually writes its own version of:

Please summarize this issue, but not badly.

And then everyone is surprised when output quality varies. MCP prompt management gives you a place to define and share approved prompt patterns.

Resources

Resources are readable context. For example:

• approved documentation
• system status
• deployment metadata
• policy snippets
• configuration summaries
• logs made safe for AI consumption
• support knowledge base articles

Resources are not the same as tools. A resource is something the client can read. A tool is something the server can execute. That distinction matters. Reading an approved status page is not the same as calling restartProduction(). One is context. The other is how you get invited to a very tense meeting.

When should you use MCP?

Use MCP when standardization is more valuable than local simplicity. Good MCP use cases include:

• connecting ColdFusion to an existing external MCP server
• exposing ColdFusion business capabilities to other AI clients
• sharing tools across multiple applications
• centralizing prompt templates
• exposing approved resources to AI hosts
• wrapping third-party APIs behind a standard interface
• building enterprise AI workflows where auditability matters
• allowing tools to be discovered instead of hardcoded

For example, imagine a company with multiple internal applications:

• ColdFusion support portal
• Jira
• internal wiki
• deployment dashboard
• CRM
• document archive

Without MCP, every AI-enabled application may need custom integration code for every system. With MCP, each system can expose capabilities through a standard protocol, and AI hosts can discover and use those capabilities more consistently. That does not eliminate work. It moves the work into a better shape. Which, frankly, is most of software architecture.

When should you not use MCP?

Do not use MCP just because it sounds impressive. If your tool lives inside your ColdFusion application and only your application needs it, a local CFC tool may be simpler. For example, if your AI assistant only needs this:

getTicketStatus( userId, ticketId )

And that method lives inside the same application, registering it as a CFC tool may be enough. Adding MCP in that case may be architectural cosplay.

MCP adds value when:

• there is a system boundary
• tools need to be shared
• discovery matters
• prompt/resource sharing matters
• multiple clients need access
• standardization matters
• governance matters

If none of those are true, start with CFC tools. You do not need a passport to walk from the kitchen to the fridge.

MCP and security

MCP is a protocol. It is not a force field. Using MCP does not automatically make a tool safe. You still need:

• authentication
• authorization
• input validation
• output filtering
• audit logging
• rate limiting
• tenant isolation
• secrets management
• clear tool boundaries
• safe error handling
• confirmation for write actions

The MCP server should expose only approved tools, prompts, and resources. The MCP client should call only servers it trusts. Your ColdFusion application should not blindly connect to random MCP servers and let them influence application behavior. That would be like installing browser extensions by vibes. The protocol gives you structure… You still provide judgment.

MCP and authorization

Authorization needs to happen at the right boundary. If ColdFusion is consuming an MCP server, your application still needs to decide whether the current user is allowed to request that capability. If ColdFusion is exposing an MCP server, the server needs to authenticate callers and authorize tool/resource access. For example, if your MCP server exposes:

getCustomerAccountSummary

Then it needs to know:

• who is calling
• what tenant/account they belong to
• whether they are allowed to access that customer
• what fields should be returned
• whether the call should be logged
• whether sensitive fields should be redacted

Do not assume the AI host will enforce your business rules. The host might be trustworthy. The host might be misconfigured. The host might be a demo someone left running on a laptop named TEMP-DO-NOT-USE. The server must protect itself.

Same rule as before: The AI can ask. ColdFusion decides. With MCP, we add: Other systems can ask. Your server still decides.

MCP and observability

ColdFusion 2025 Update 8 also added AI services monitoring in PMT, including tabs for LLMs, Agents, RAG, MCP Clients, MCP Servers, Vector Stores, and a Trace Viewer for AI requests. That matters because once you add MCP, failures can happen in more places.

A request may involve:

• your web page
• your ColdFusion agent
• an MCP client
• an external MCP server
• a remote API behind that server
• a model response
• tool result summarization
• output validation

That is a lot of moving parts. If the user sees:

Sorry, I could not complete that request.

You need to know where it failed. Was it the model? The MCP handshake? The remote server? Tool authorization? A timeout? A bad argument? A malformed response? A service outage? A bad day?

Logging and monitoring are not optional. They are how you avoid debugging distributed AI workflows by staring at the ceiling and making increasingly specific guesses.

A practical MCP example

Let’s imagine a support assistant. In the previous article, the support assistant had a local CFC tool:

getTicketStatus( userId, ticketId )

That worked because ticket data lived inside the current ColdFusion app. Now imagine ticket data lives in another system. Maybe it is Jira. Maybe it is ServiceNow. Maybe it is another ColdFusion application. Maybe it is a system named NewSupportPortal that everyone still calls “the old ticket system.” Instead of adding Jira-specific or ServiceNow-specific integration directly into the assistant, you connect to an MCP server that exposes a tool like:

getIssueStatus

Your ColdFusion app can discover the tool:

<cfscript>
mcpClient = MCPClient( {
	transport : {
		type : "http",
		url : "https://support-tools.example.com/mcp"
	}
} );

availableTools = mcpClient.listTools();

writeDump( availableTools );
</cfscript>

Then call it:

<cfscript>
toolResult = mcpClient.callTool(
	name = "getIssueStatus",
	arguments = {
		issueKey : "SUP-12345"
	}
);
</cfscript>

Then summarize it with the agent:

<cfscript>
finalPrompt = "
	The user asked:
	What is the status of SUP-12345?

	The MCP server returned:
	#serializeJSON( toolResult )#

	Answer in one short paragraph.
	Do not add facts that are not in the MCP result.
";

response = agent.chat(
	finalPrompt,
	session.sessionId
);

writeOutput( encodeForHtml( response.message ) );
</cfscript>

Again, the exact production implementation will depend on your server, transport, authentication, error handling, and how deeply you integrate MCP tools into the Agent() workflow. But the idea is the same as CFC tools… The assistant identifies the need. The application calls a controlled capability. The tool result becomes the source of truth. The model explains.

MCP as a tool source for Agent()

In the CFC tools article, the agent could request CFC methods. MCP can also become a source of tools. Conceptually, your agent can be configured so the model knows that external MCP tools exist and can request them during conversation. That gives you a powerful pattern:

User asks a question.
Agent decides a tool is needed.
Tool may be local CFC or external MCP.
ColdFusion validates and executes the request.
Tool result comes back.
Agent explains the answer.

The important part is that MCP does not remove the safety rules from the previous article. It expands where tools can come from. You still need:

• allowlists
• argument validation
• user authorization
• confirmation before writes
• safe error handling
• logging
• result filtering

If CFC tools gave the assistant hands, MCP gives it a network cable. Please do not plug that cable into everything.

Exposing your ColdFusion app as an MCP server

Now let’s flip the direction. Suppose your ColdFusion application owns valuable business capabilities:

• get registration status
• list available programs
• calculate cart totals
• get order status
• read approved help articles
• return reusable support prompts

You may want other AI hosts to use those capabilities. Instead of each host integrating directly with your internal APIs, your ColdFusion app can expose an MCP server. The server can provide:

• approved tools
• approved resources
• approved prompts

External clients can discover what is available. That is useful when:

• your organization has multiple AI clients
• you want centralized governance
• you want consistent tool definitions
• you want a clear protocol boundary
• you want to avoid one-off integrations
• you want to expose capabilities without exposing the whole codebase

But once again, do not expose everything. Expose a curated surface area. Think “public API,” not “garage sale.”

A conceptual MCP endpoint

A simple endpoint may look conceptually like this:

<cfscript>
requestData = getHttpRequestData();

responseData = application.mcpServer.handleRequest(
	requestBody = requestData.content
);

cfcontent(
	type = "application/json",
	reset = true
);

writeOutput( serializeJSON( responseData ) );
</cfscript>

That endpoint receives MCP requests and delegates to your application-level MCP server. But do not stop there in production. Production needs:

• authentication
• authorization
• request size limits
• rate limiting
• logging
• error handling
• transport security
• tenant boundaries
• safe resource exposure
• clear deployment configuration

The endpoint is the doorway. Do not forget the lock.

Resources are not a document dumpster

Because MCP can expose resources, it may be tempting to expose everything. Documentation. Logs. Reports. Files. Internal notes. Half-finished migration plans. A spreadsheet named final_final_really_final.xlsx.

Please do not.

Resources should be curated. Before exposing a resource through MCP, ask:

• Should an AI client be allowed to read this?
• Does it contain secrets?
• Does it contain personal data?
• Does access depend on user role?
• Is it tenant-specific?
• Is it current?
• Is it safe to summarize?
• Should it be redacted?
• Should it be available only through a tool with authorization checks?

Resources can be useful. They can also become a data leak with better branding.

Prompts are reusable business logic… sort of

MCP prompt management is interesting because prompts often become part of business behavior. A prompt that says:

Summarize this incident for an executive audience.

May encode company preferences about tone, format, risk language, and required sections. If every app writes its own version, output quality varies. If a central MCP server exposes the approved prompt, multiple clients can reuse it.

That gives you:

• consistency
• easier updates
• central review
• fewer copy-pasted prompt mutations
• less “why does this assistant sound like a pirate accountant?”

Treat shared prompts with the same care you would treat shared templates or business rules. They are not just strings. They are instructions that shape application behavior.

MCP does not replace CFC tools

MCP is not a replacement for CFC tools. It is another layer. Use local CFC tools for simple, application-local capabilities. Use MCP for shared, external, discoverable, or protocol-bound capabilities. Sometimes you will use both. For example:

Local CFC tool:
	getCurrentUserProfile()

External MCP tool:
	searchCompanyWiki()

External MCP resource:
	readRefundPolicy()

Agent:
	Combines profile context, wiki search, policy resource, and conversation memory.

That is a more advanced assistant. And yes, it sounds complicated. That is why we are building the series one layer at a time instead of starting with a diagram that looks like a subway map designed during an outage.

MCP does not replace RAG

MCP and RAG are also different. MCP is a protocol for connecting AI clients to tools, prompts, and resources. RAG is a pattern for retrieving relevant information from documents or data and using it to ground model responses. They can work together. An MCP server might expose a resource. An MCP tool might search a document system. A RAG pipeline might use content retrieved through MCP. But they are not the same thing.

MCP answers:

How does my AI application connect to external capabilities?

RAG answers:

How does my AI application retrieve relevant knowledge and use it in a grounded answer?

We will cover RAG in the next article. That is where the robot gets an open-book test.

Common mistakes

Let’s review the easiest ways to make MCP weird.

Using MCP when a local CFC tool would do

If the capability is local and only needed by one application, start with a CFC tool. MCP is useful, but it is not required for every tool. Do not build a toll bridge between your couch and your coffee table.

Exposing too much

Do not expose every CFC, every method, every file, every prompt, or every resource. Expose approved capabilities. Least privilege still applies. The robot does not need root access just because it learned a protocol.

Trusting remote MCP servers blindly

If your ColdFusion app connects to an MCP server, know what that server is. Who runs it? What tools does it expose? What data does it return? What authentication does it require? What happens when it fails? What are you logging? What are you sending?

“Found it on GitHub” is not a vendor risk assessment.

Forgetting tenant boundaries

Multi-tenant apps need careful boundaries. If an MCP server exposes customer or organization data, every call must enforce tenant isolation. Do not let an AI workflow become the scenic route around your permissions model.

Returning huge responses

MCP tools and resources should return the minimum useful data. Huge responses increase cost, latency, context pressure, and confusion. No model needs a 9 MB JSON response unless your goal is to stress-test billing.

Skipping observability

Once MCP enters the picture, failures span systems. Log requests. Log tool names. Log safe argument summaries. Log timings. Log errors. Use PMT or whatever monitoring strategy makes sense in your environment.

You cannot fix what you cannot see. You also cannot explain it to your boss, which is often worse.

Not confirming write actions

If an MCP tool can send email, create records, cancel things, charge money, or make public changes, require confirmation and authorization. The fact that a tool lives behind MCP does not make it less dangerous. It just makes the danger more standardized.

A better first MCP feature

A good first MCP feature is read-only and low risk. For example:

• list tools from a known internal MCP server
• call a read-only status tool
• fetch an approved prompt template
• read a safe documentation resource
• search a company wiki with limited access
• expose one read-only ColdFusion CFC method as an MCP tool

Avoid making your first MCP feature:

• send email
• delete records
• issue refunds
• change permissions
• modify production settings
• expose raw logs
• expose arbitrary file reads
• expose SQL execution

Start with visibility. Then move to action. That pattern has served us well before, mostly because the opposite pattern has created outages with exciting names.

Where we go next

At this point, our ColdFusion AI assistant has grown up quite a bit. We now have:

ChatModel()
	Basic stateless AI calls.

Agent() with memory
	Conversation context and per-user continuity.

CFC tools
	Local application capabilities.

MCP
	Standardized tools, prompts, and resources across system boundaries.

That is a strong foundation. But we still have another major problem. What if the assistant needs to answer questions from our own documents, not application state? Not tool results. Not ticket status. Documents. Policies. Guides. Knowledge base articles. Manuals. Internal documentation that may or may not have been written by someone who considered paragraphs optional.

That is where RAG comes in.

In the next article, we will add Retrieval-Augmented Generation and teach the assistant to answer from our own content instead of relying on model memory, vibes, or whatever it read on the internet before lunch.

Final thought

MCP is not magic. It is not a security model by itself. It is not a replacement for CFC tools. It is not a reason to expose everything in your application. It is a standard protocol for connecting AI clients to tools, prompts, and resources in a consistent, auditable way. That is valuable. Especially once your AI workflows need to cross application boundaries. Use CFC tools when the capability lives inside your app. Use MCP when the capability needs to be shared, discovered, governed, or accessed across systems.

Keep the boundaries clear.

Validate everything.

Authorize everything.

Log enough to debug the inevitable weirdness.

And remember: CFC tools gave the assistant hands. MCP gives it a passport. ColdFusion still decides where it is allowed to go.