Inspiration
We started with a simple question: Why should AI have to understand our entire platform just to answer a simple question?
Today, we give AI a growing toolbox of MCP tools and expect it to figure out which tools to use and how to combine them. Meanwhile, the platform already has the context needed across Search, Hypertrail, Ticket APIs and Conversation Store.
We wanted to flip this model:
AI should say WHAT it needs. The platform should figure out HOW to get it.
What it does
Headless Gateway introduces a platform-side intelligence layer between MCP and our platform services.
Our prototype demonstrates two capabilities:
Capability Resolution — resolve user intent into a meaningful capability instead of exposing a large set of API-shaped tools. Context Enrichment — gather information from Ticket API, Hypertrail, Search and Conversation Store and combine it into one enriched response.
Instead of:
Select → Call → Reason → Select → Call → Reason
we move toward:
Intent → Capability → Enriched Context → Answer
How we built it
We built a working prototype around a simple ticket-investigation scenario.
First, we demonstrate the current experience, where AI navigates a large toolset and makes four sequential tool calls.
Then we demonstrate the proposed experience, where Headless Gateway:
Resolves the request to Ticket Investigation Dispatches the required platform services Gathers context in parallel Composes the results into one enriched response Challenges we ran into
Our biggest challenge was defining the right boundary between AI and the platform.
We didn't want to simply move API calls from the MCP Gateway into another gateway. That would only move the complexity.
The key distinction became:
AI decides WHAT it needs. The platform decides HOW to fulfill it.
Accomplishments that we're proud of
We're proud that we turned an architectural idea into a working, interactive Before vs After prototype.
The prototype makes the problem tangible and demonstrates how existing platform capabilities can become composable building blocks for AI, rather than isolated APIs that every AI client has to discover independently.
What we learned
Our biggest learning was that reducing the number of tools isn't enough.
The real opportunity is to move knowledge about how platform capabilities work together into the platform itself.
If multiple AI clients repeatedly need the same combination of Search, ticket data, history and conversation context, that orchestration shouldn't have to be rediscovered every time.
Build the intelligence once. Reuse it everywhere.
What's next for Headless Gateway/MCP tool graph
This prototype is the first step toward an MCP tool graph that can:
Compile frequently repeated tool chains into deterministic workflows Cache capability and tool resolution Compose more platform capabilities automatically Move from read-only enrichment to actions such as scheduling, email and ticket updates Make AI-created workflows visible and reusable inside Freshservice and Freshdesk Provide the same capability layer across different AI clients
Our vision is simple:
Don't give AI a bigger toolbox. Give it better capabilities.
