AI agents are becoming more useful than ever; they’re now doing more than just generating text. They can now retrieve information from different sources, call tools, and act on a user's prompt. But the problem is that most AI applications are missing one thing: a way to reach systems where the real business logic lives.
The Model Context Protocol (MCP) solves part of this problem. It gives AI applications a standard way to discover and call external tools. The catch is that building a dedicated MCP server for your existing backend adds another piece of software you now have to maintain.
In this tutorial, you'll learn what Graftcode is, how it connects to MCP, and how to expose an existing backend to an AI agent without writing a custom MCP server.
Most agents start by connecting a language model to a user interface. Models can generate text, answer questions, summarize content, and perform reasoning tasks. However, the challenge arises when the AI needs context that isn’t present in the prompt.
For example:
Information like this does not exist inside the model itself. The model needs a way to retrieve it from external systems, and that’s where protocols like MCP come into the picture.
Traditionally, giving AI agents access to backend functionality means introducing another layer to maintain. You build the backend, expose it through an MCP server, define tools, connect handlers, and keep everything in sync whenever the backend changes.
Graftcode starts from a different place; Instead of creating a separate MCP representation of your application, Gateway discovers the public methods you've already exposed and makes them available through MCP.
The backend stays as the source of truth, while AI agents become another consumer of those capabilities.
Graftcode is a tool that makes public backend methods callable across languages, processes, and machines without the need to write API or MCP layer. You write normal business code. Graftcode Gateway loads that code, finds its public methods, and makes them available to consumers, including AI agents over MCP.
It was built around a simple idea: business logic should be written once and reused by different consumers. Instead of exposing backend functionality through manually maintained integration layers, Graftcode treats public methods as the gateway to work with your backend.
For example, a backend service may already have all the business logic an application needs. Customer management systems contain methods for retrieving account information. Payment/checkout systems have methods for calculating invoices. Support platforms contain methods for searching documentation and knowledge bases.
But we can have those applications use generated Grafts or AI agents via MCP rather than the traditional approach that requires creating additional integration layers such as REST APIs, RPC services, or other custom integrations.
There are two sides to this model:
The Caller talks to the Receiver through a generated package called a Graft, or through MCP if the Caller is an AI client.
| Feature | Custom MCP Server | Graftcode Gateway |
|---|---|---|
| Tool definitions | Written and maintained as an additional layer | Discovered automatically from your code |
| Keeping tools in sync with the backend | Manual, on every change | Automatic |
| Extra integration layer | Yes | No |
| Who owns the source of truth | The MCP server's tool schema | The backend method itself |
When you host a module through Graftcode Gateway, it reads your backend, loads the modules, discovers their public methods, and exposes the package. Those methods become callable in two ways at once: via a generated Graft for regular applications and through MCP for AI agents.
There's no separate MCP implementation sitting between the Gateway and your backend. The public methods are the capabilities.
When Gateway hosts a module, it opens two ports:
/mcp.
No OpenAPI spec, no manually defined MCP tool, and no custom server. Gateway does the discovery for you.
You don't have to expose every method in a module. Gateway supports filtering with flags like --types and --methods:
gg ./service \
--types SupportService \
--methods getCustomerProfile,getSubscriptionDetails,searchKnowledgeBase
This matters more with AI agents than almost anywhere else. Giving an agent access to a method means giving it a capability, so keep the exposed surface small and intentional.
For MCP clients that send a bare method name, Gateway can resolve the right class with --mcpBaseClass. Browser-based or edge MCP clients may also need CORS headers set through a cors.config file passed with --corsConfig.
mkdir customer-support-ai
cd customer-support-ai
npm init -y
Create an index.js file:
class SupportService {
static getCustomerProfile(customerId) {
const customers = {
"customer-1001": {
id: "customer-1001",
name: "Sarah Johnson",
email: "sarah@example.com",
plan: "Professional",
status: "active"
},
"customer-1002": {
id: "customer-1002",
name: "James Wilson",
email: "james@example.com",
plan: "Starter",
status: "active"
}
};
return customers[customerId] ?? {
error: "Customer not found"
};
}
static getSubscriptionDetails(customerId) {
const subscriptions = {
"customer-1001": {
customerId,
plan: "Professional",
billingCycle: "monthly",
renewalDate: "2026-10-01",
status: "active"
},
"customer-1002": {
customerId,
plan: "Starter",
billingCycle: "monthly",
renewalDate: "2026-09-20",
status: "active"
}
};
return subscriptions[customerId] ?? {
error: "Subscription not found"
};
}
static searchKnowledgeBase(query) {
const articles = [
{
title: "How subscription renewals work",
content: "Subscriptions automatically renew at the end of each billing period."
},
{
title: "Changing your subscription",
content: "Customers can change their subscription plan from the billing settings."
},
{
title: "Cancelling a subscription",
content: "Customers can cancel their subscription before the next renewal date."
}
];
const searchTerm = query.toLowerCase();
return articles.filter((article) =>
`${article.title} ${article.content}`
.toLowerCase()
.includes(searchTerm)
);
}
}
module.exports = { SupportService };
This code has nothing MCP-specific in it. No decorators, no tool schemas, no handlers. That's the point. The backend doesn't need to know that an AI agent will use it later.
Now that we have our backend service, we need a way to expose its public methods so they can be consumed by applications and AI agents.
The easiest way to get started is by installing Graftcode Gateway using the official one-line installer.
iwr https://grft.dev/get|iex
curl -fsSL https://grft.dev/get |sh
Once installed, you can verify the Gateway is available:
gg --help
Graftcode Gateway is responsible for your module, discovering its public methods, exposing them through Graftcode, and automatically making them available through MCP.
After installation, you can host your service by pointing Gateway at your project:
gg ./package.json
After installation, we need to host the module through Graftcode Gateway.
Graftcode Gateway is the runtime host that loads the module, discovers its public callable surface, and exposes it to consumers.
In this tutorial, we'll use Docker to work with Graftcode Gateway. Firstly, let’s create a Dockerfile:
FROM node:24
ARG TARGETARCH
WORKDIR /usr/app
COPY . /usr/app/
RUN apt-get update \
&& apt-get install -y wget \
&& wget -O /usr/app/gg.deb "https://github.com/grft-dev/graftcode-gateway/releases/latest/download/gg_linux_${TARGETARCH}.deb" \
&& dpkg -i /usr/app/gg.deb \
&& rm /usr/app/gg.deb \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/*
EXPOSE 80
EXPOSE 81
CMD ["gg", "./package.json"]
Build and run it:
docker build --no-cache --pull -t customer-support-ai:test .
docker run -d \
-p 80:80 \
-p 81:81 \
--name graftcode_support_demo \
customer-support-ai:test
At this point, the MCP endpoint is already live. You haven't written an MCP server, defined a tool, or written an OpenAPI spec.
Open:
http://localhost:81/GV
You should see the methods Gateway found; SupportService, getCustomerProfile, getSubscriptionDetails, and searchKnowledgeBase.
Vision also lets you try each method directly, so you can confirm what's exposed before connecting an AI agent.
Graftcode Vision is useful because it allows developers to inspect what the Gateway has actually discovered. It also lets you try each method directly, so you can confirm what's exposed before connecting an AI agent.
Before integrating a frontend application or AI client, you can verify:
This creates a feedback loop that is much easier than repeatedly modifying prompts or MCP configurations while debugging.
Cursor. Add this to .cursor/mcp.json:
{
"mcpServers": {
"customer-support": {
"url": "http://localhost:81/mcp"
}
}
}
Claude Desktop. Claude Desktop only supports stdio, and Gateway exposes MCP over HTTP, so bridge the two with mcp-remote:
{
"mcpServers": {
"customer-support": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"http://localhost:81/mcp"
]
}
}
}
Restart the client after saving the config.
Ask your AI client: “What subscription does customer-1001 have?”
The agent should call getSubscriptionDetails("customer-1001") and return the real result from your backend:
{
"customerId": "customer-1001",
"plan": "Professional",
"billingCycle": "monthly",
"renewalDate": "2026-10-01",
"status": "active"
}
Now try asking a question that needs more than one method; for example, “What plan is customer-1001 using, when does it renew, and how do renewals work?
To answer that, the agent needs to call getSubscriptionDetails() and searchKnowledgeBase(), then combine the results. If it does, your setup is working.
--types and --methods to expose only what the agent actually needs.
MCP gives AI agents a standard way to call external tools, but building a custom MCP server for every backend adds a second integration layer to maintain. Graftcode starts from the backend instead. Write the capability once, host it through Gateway, and let both regular applications and AI agents call the same methods.
The interesting part of MCP is not the protocol itself; it’s rather what it enables. Agents become more useful when they can work with systems instead of relying so much on prompts and fine-tuned data.
Instead of building a custom MCP and connecting it to existing agents, developers can now expose existing business logic with Graftcode Gateway. Those capabilities become available to both traditional applications and AI agents while keeping your backend/logic as the source of truth.
For teams already maintaining customer services, internal tools, knowledge bases, billing systems, or operational platforms, this can reduce the amount of integration work required when introducing AI capabilities into an existing application stack.
If you already have backend functionality an AI agent could use, try exposing one of your own services through Graftcode's MCP quick start.