{"slug": "ai-agents-calling-your-existing-backend-without-mcp-development", "title": "AI Agents Calling Your Existing Backend Without MCP Development", "summary": "Graftcode Gateway is a tool that exposes an existing backend's public methods to AI agents over the Model Context Protocol without requiring developers to write or maintain a dedicated MCP server. The gateway loads backend modules, discovers their public methods, and serves them both as generated packages for regular applications and as MCP tools for AI clients, keeping the backend method itself as the source of truth.", "body_md": "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.\n\nThe 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.\n\nIn 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.\n\nMost 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.\n\nFor example:\n\nInformation 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.\n\nTraditionally, 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.\n\nGraftcode 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.\n\nThe backend stays as the source of truth, while AI agents become another consumer of those capabilities.\n\n[Graftcode](https://graftcode.com) 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.\n\nIt 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.\n\nFor 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.\n\nBut 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.\n\nThere are two sides to this model:\n\nThe Caller talks to the Receiver through a generated package called a Graft, or through MCP if the Caller is an AI client.\n\n| Feature | Custom MCP Server | Graftcode Gateway | \n|---|---|---|\n| Tool definitions | Written and maintained as an additional layer | Discovered automatically from your code | \n| Keeping tools in sync with the backend | Manual, on every change | Automatic | \n| Extra integration layer | Yes | No | \n| Who owns the source of truth | The MCP server's tool schema | The backend method itself | \n\nWhen 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**.\n\nThere's no separate MCP implementation sitting between the Gateway and your backend. The public methods are the capabilities.\n\nWhen Gateway hosts a module, it opens two ports:\n\n`/mcp`.\nNo OpenAPI spec, no manually defined MCP tool, and no custom server. Gateway does the discovery for you.\n\nYou don't have to expose every method in a module. Gateway supports filtering with flags like `--types` and `--methods`:\n\n```\ngg ./service \\\n  --types SupportService \\\n  --methods getCustomerProfile,getSubscriptionDetails,searchKnowledgeBase\n```\n\nThis 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.\n\nFor 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`.\n\n```\nmkdir customer-support-ai\ncd customer-support-ai\nnpm init -y\n```\n\nCreate an `index.js` file:\n\n``` js\nclass SupportService {\n  static getCustomerProfile(customerId) {\n    const customers = {\n      \"customer-1001\": {\n        id: \"customer-1001\",\n        name: \"Sarah Johnson\",\n        email: \"sarah@example.com\",\n        plan: \"Professional\",\n        status: \"active\"\n      },\n      \"customer-1002\": {\n        id: \"customer-1002\",\n        name: \"James Wilson\",\n        email: \"james@example.com\",\n        plan: \"Starter\",\n        status: \"active\"\n      }\n    };\n\n    return customers[customerId] ?? {\n      error: \"Customer not found\"\n    };\n  }\n\n  static getSubscriptionDetails(customerId) {\n    const subscriptions = {\n      \"customer-1001\": {\n        customerId,\n        plan: \"Professional\",\n        billingCycle: \"monthly\",\n        renewalDate: \"2026-10-01\",\n        status: \"active\"\n      },\n      \"customer-1002\": {\n        customerId,\n        plan: \"Starter\",\n        billingCycle: \"monthly\",\n        renewalDate: \"2026-09-20\",\n        status: \"active\"\n      }\n    };\n\n    return subscriptions[customerId] ?? {\n      error: \"Subscription not found\"\n    };\n  }\n\n  static searchKnowledgeBase(query) {\n    const articles = [\n      {\n        title: \"How subscription renewals work\",\n        content: \"Subscriptions automatically renew at the end of each billing period.\"\n      },\n      {\n        title: \"Changing your subscription\",\n        content: \"Customers can change their subscription plan from the billing settings.\"\n      },\n      {\n        title: \"Cancelling a subscription\",\n        content: \"Customers can cancel their subscription before the next renewal date.\"\n      }\n    ];\n\n    const searchTerm = query.toLowerCase();\n\n    return articles.filter((article) =>\n      `${article.title} ${article.content}`\n        .toLowerCase()\n        .includes(searchTerm)\n    );\n  }\n}\n\nmodule.exports = { SupportService };\n```\n\nThis 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.\n\nNow 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.\n\nThe easiest way to get started is by installing Graftcode Gateway using the official one-line installer.\n\n```\niwr https://grft.dev/get|iex\ncurl -fsSL https://grft.dev/get |sh\n```\n\nOnce installed, you can verify the Gateway is available:\n\n```\ngg --help\n```\n\nGraftcode Gateway is responsible for loading your module, discovering its public methods, exposing them through Graftcode, and automatically making them available through MCP.\n\nAfter installation, you can host your service by pointing Gateway at your project:\n\n```\ngg ./package.json\n```\n\nAfter installation, we need to host the module through Graftcode Gateway.\n\nGraftcode Gateway is the runtime host that loads the module, discovers its public callable surface, and exposes it to consumers.\n\nIn this tutorial, we'll use Docker to work with Graftcode Gateway. Firstly, let’s create a `Dockerfile`:\n\n```\nFROM node:24\n\nARG TARGETARCH\n\nWORKDIR /usr/app\n\nCOPY . /usr/app/\n\nRUN apt-get update \\\n && apt-get install -y wget \\\n && wget -O /usr/app/gg.deb \"https://github.com/grft-dev/graftcode-gateway/releases/latest/download/gg_linux_${TARGETARCH}.deb\" \\\n && dpkg -i /usr/app/gg.deb \\\n && rm /usr/app/gg.deb \\\n && apt-get clean \\\n && rm -rf /var/lib/apt/lists/*\n\nEXPOSE 80\nEXPOSE 81\n\nCMD [\"gg\", \"./package.json\"]\n```\n\nBuild and run it:\n\n```\ndocker build --no-cache --pull -t customer-support-ai:test .\n\ndocker run -d \\\n  -p 80:80 \\\n  -p 81:81 \\\n  --name graftcode_support_demo \\\n  customer-support-ai:test\n```\n\nAt this point, the MCP endpoint is already live. You haven't written an MCP server, defined a tool, or written an OpenAPI spec.\n\nOpen:\n\n```\nhttp://localhost:81/GV\n```\n\nYou should see the methods Gateway found; `SupportService`, `getCustomerProfile`, `getSubscriptionDetails`, and `searchKnowledgeBase`.\n\nVision also lets you try each method directly, so you can confirm what's exposed before connecting an AI agent.\n\nGraftcode 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.\n\nBefore integrating a frontend application or AI client, you can verify:\n\nThis creates a feedback loop that is much easier than repeatedly modifying prompts or MCP configurations while debugging.\n\n**Cursor.** Add this to `.cursor/mcp.json`:\n\n```\n{\n  \"mcpServers\": {\n    \"customer-support\": {\n      \"url\": \"http://localhost:81/mcp\"\n    }\n  }\n}\n```\n\n**Claude Desktop.** Claude Desktop only supports stdio, and Gateway exposes MCP over HTTP, so bridge the two with `mcp-remote`:\n\n```\n{\n  \"mcpServers\": {\n    \"customer-support\": {\n      \"command\": \"npx\",\n      \"args\": [\n        \"-y\",\n        \"mcp-remote\",\n        \"http://localhost:81/mcp\"\n      ]\n    }\n  }\n}\n```\n\nRestart the client after saving the config.\n\nAsk your AI client: “What subscription does customer-1001 have?”\n\nThe agent should call `getSubscriptionDetails(\"customer-1001\")` and return the real result from your backend:\n\n```\n{\n  \"customerId\": \"customer-1001\",\n  \"plan\": \"Professional\",\n  \"billingCycle\": \"monthly\",\n  \"renewalDate\": \"2026-10-01\",\n  \"status\": \"active\"\n}\n```\n\nNow 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?\n\nTo answer that, the agent needs to call `getSubscriptionDetails()` and `searchKnowledgeBase()`, then combine the results. If it does, your setup is working.\n\n`--types` and `--methods` to expose only what the agent actually needs.\nMCP 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.\n\nThe 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.\n\nInstead 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.\n\nFor 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.\n\nIf you already have backend functionality an AI agent could use, try exposing one of your own services through Graftcode's MCP quick start.", "url": "https://wpnews.pro/news/ai-agents-calling-your-existing-backend-without-mcp-development", "canonical_source": "https://dev.to/coderoflagos/ai-agents-calling-your-existing-backend-without-mcp-development-320d", "published_at": "2026-09-24 09:06:11+00:00", "updated_at": "2026-09-24 09:30:48.578729+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "developer-tools", "ai-tools"], "entities": ["Graftcode", "Graftcode Gateway", "Model Context Protocol"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/ai-agents-calling-your-existing-backend-without-mcp-development", "markdown": "https://wpnews.pro/news/ai-agents-calling-your-existing-backend-without-mcp-development.md", "text": "https://wpnews.pro/news/ai-agents-calling-your-existing-backend-without-mcp-development.txt", "jsonld": "https://wpnews.pro/news/ai-agents-calling-your-existing-backend-without-mcp-development.jsonld"}}