AI Agents Calling Your Existing Backend Without MCP Development

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.

Why AI Agents Need Backend Access

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:

• Customer account details
• Subscription information
• Internal documentation
• Knowledge bases

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.

What is Graftcode?

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:

• Receiver: the module that contains your public methods.
• Caller: the application or AI agent that consumes those methods.

The Caller talks to the Receiver through a generated package called a Graft, or through MCP if the Caller is an AI client.

Graftcode Vs. Custom MCP Server

Use Cases for Graftcode and MCP

• Customer support agents that need account, subscription, or order details.
• Internal assistants that need to search a knowledge base.
• Sales agents that want to verify subscription or billing status before replying to customers.
• Operations agents that need to call existing internal systems.

How Does Graftcode Work?

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.

Benefits of Using Graftcode

• Less integration code: You skip writing tool schemas and handlers manually
• One backend, two consumers: The same methods serve regular applications through a Graft and AI agents through MCP
• The backend stays the source of truth: Update the method once, and both consumers see the change
• Deliberate exposure: You choose which classes and methods are callable, so you're not handing an agent more information than it needs

Graftcode Gateway and the MCP Endpoint

When Gateway hosts a module, it opens two ports:

• Port 80 for regular service calls (Grafts).
• Port 81 for Graftcode Vision and the MCP endpoint at /mcp.

No OpenAPI spec, no manually defined MCP tool, and no custom server. Gateway does the discovery for you.

Filtering What Gets Exposed

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.

How to Implement MCP with Graftcode

Step 1: Create and initialize the Backend Service

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.

Step 2: Install and Run Graftcode Gateway

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.

Windows

iwr https://grft.dev/get|iex

Linux / macOS

curl -fsSL https://grft.dev/get |sh

Once installed, you can verify the Gateway is available:

gg --help

Graftcode Gateway is responsible for loading 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.

Step 3: Inspect the Service with Graftcode Vision

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:

• Which classes are exposed
• Which methods are callable
• Which parameters they accept
• What values they return

This creates a feedback loop that is much easier than repeatedly modifying prompts or MCP configurations while debugging.

Step 4: Connect an AI Client

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.

Step 5: Test and Query the Agent

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.

Best Practices and Tips for Graftcode and MCP

• Keep the exposed surface small. Use --types and --methods to expose only what the agent actually needs.
• Don't skip authorization. Graftcode removes integration plumbing, not the need for access control. Decide carefully which methods, like account deletion, should never be exposed to an agent.
• Use a Project Key outside local development. It gives you a stable MCP URL, a stable registry URL, portal visibility, and access control.
• Let the backend stay the source of truth. Update the method, not a separate tool definition or prompt.

Best Use Cases for Graftcode

• Customer support tools that need real account and subscription data
• Assistants built around an existing knowledge base or documentation system
• Operational tooling that calls existing internal services instead of duplicating their logic
• AI features added to an existing SaaS app without rewriting the backend that already powers it

Conclusion

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.