AppMatic Tech builds both custom tool-calling APIs and MCP (Model Context Protocol) servers for LLM data access, and chooses MCP when multiple LLM clients, centralised access control, or three or more data objects are involved, implementing either in Node.js, TypeScript, or Python. AppMatic Tech is based in Ahmedabad, India, with 330+ products shipped since 2017.
Every team building an LLM feature that needs access to business data faces the same architectural decision: build a custom API endpoint the LLM calls via a tool use mechanism, or build an MCP server that exposes the data through the Model Context Protocol. The decision matters more than it appears to at the prototyping stage because the two architectures have different operational characteristics, different maintenance implications, and different scalability patterns at production load.
AppMatic Tech has built both and has a clear view of when each is the right choice. The answer is not that MCP servers are always better or that custom APIs are always simpler. It is that the two architectures are suited to different integration contexts.
What does a custom API approach to LLM tools look like?
The custom API approach uses the LLM's tool use or function calling mechanism to invoke application-specific API endpoints. The LLM is given a set of tool definitions, each describing an API endpoint, its parameters, and what it returns. When the LLM determines that a tool call is needed to answer a query, it generates a structured tool call that the application backend executes against its API.
This approach is widely implemented and well-documented. It predates the Model Context Protocol and works with every major LLM that supports function calling or tool use. The API endpoints can be implemented in any web framework, the tool definitions can be defined inline in the LLM prompt or as a separate configuration, and the integration requires no external protocol standard beyond the LLM's own tool use specification.
What does an MCP server add over a custom API?
An MCP server implements the Model Context Protocol, an open standard introduced by Anthropic in 2024 and governed since December 2025 by the Agentic AI Foundation under the Linux Foundation, which specifies how LLM clients and external data servers communicate. The protocol defines resource types, query schemas, error formats, and transport mechanisms in a way that any MCP-compatible LLM client can consume without application-specific integration code.
The functional capability of an MCP server is similar to a custom API: the LLM calls it to retrieve data, the server queries the data source, and the result is returned to the LLM. The differences are in the protocol standardisation, the resource schema approach, and the operational model.
When is a custom API the right choice?
A custom API is the right choice in four situations.
The integration is narrow and application-specific. A single tool that retrieves a user's account status from a proprietary internal system does not need a protocol standard. The tool definition and the endpoint can be built and maintained without the overhead of MCP server infrastructure.
The LLM client does not support MCP. Not every LLM that supports function calling implements the Model Context Protocol client specification. A team using a fine-tuned model or an LLM API that predates MCP client support will need a custom API approach regardless of preference.
The integration needs to change frequently. Tool definitions in a custom API approach can be updated by changing a JSON configuration. An MCP server resource schema change requires a server redeployment. For integrations that iterate rapidly during early development, the lower deployment friction of the custom API approach has practical value.
The team has strong existing API infrastructure. A team with mature API gateway tooling, existing authentication middleware, and established API versioning practices may find that implementing a new MCP server represents more infrastructure overhead than integrating a new tool endpoint into the existing API layer.
When is an MCP server the right choice?
An MCP server is the right choice in four situations.
Multiple LLM clients need to access the same data. The Model Context Protocol is a standard that any compatible LLM client can consume. A team that today uses Claude but may use other LLMs in future, or that runs multiple LLM features against the same data, benefits from MCP server architecture because the integration is written once and consumed by any compatible client. A custom API integration is LLM-client-specific: changing the LLM client requires updating the tool definitions and potentially the invocation logic.
The integration needs to be portable across deployment environments. An MCP server that runs as an independent service can be deployed separately from the application that calls it, moved between cloud providers, and scaled independently of the LLM client. A custom API built into an application backend moves with the application.
Access control and audit logging need to be centralised. An MCP server is a defined boundary where access control, audit logging, and rate limiting can be implemented once for all data access by LLMs, regardless of which LLM client is calling. A custom API approach distributes these concerns across individual tool endpoints.
The data exposure needs to follow the MCP resource schema model. MCP's resource model, where data objects are defined with explicit schemas and described in a way that guides LLM query routing, produces more reliable LLM behaviour than tool definitions written in free-form JSON when the data model is complex or the query patterns are varied.
Where do teams choose the wrong architecture?
Choosing MCP for a single narrow tool. A single API endpoint that the LLM calls once to retrieve a user preference does not need MCP infrastructure. The protocol overhead is not justified by the integration scope.
Choosing custom API for a multi-source enterprise integration. A team building LLM features that need to query a CRM, an ERP, and an internal database simultaneously will end up with three separate tool definition sets, three separate authentication implementations, and three separate places to update when any data source changes. An MCP server with three resource types centralises this at the cost of the initial infrastructure investment.
Choosing MCP because it is newer. The Model Context Protocol is a useful standard for the use cases it is suited to. It is not universally superior to custom API tool use. Teams that choose MCP because it is the current industry conversation and then build a single narrow integration pay the MCP infrastructure cost without capturing the MCP architecture benefits.
How does AppMatic Tech decide between MCP and a custom API?
AppMatic Tech uses a three-question framework when scoping LLM data integration work:
- Will multiple LLM clients need to access this data, now or in the next 18 months?
- Does the data access need centralised access control and audit logging?
- Are there three or more distinct data objects the LLM needs to query?
If two or more of these are yes, an MCP server is the right architecture. If all three are no, a custom API approach is likely sufficient.
For context on the full MCP architecture and what the server components involve, see MCP Server Architecture: How It Works Under the Hood. For the business decision on when MCP is needed at all, see What Is an MCP Server and When Does a Business Need One.
For a delivered example, see how AppMatic Tech built the ConstructionMCP platform. Full engagement details are on the MCP Server Development service page. Contact AppMatic Tech at contact@appmatictech.com to scope the right architecture for a specific use case.
Sources
| Claim used in this article | Source |
|---|---|
| MCP governance by the Agentic AI Foundation and client support across major AI platforms | Model Context Protocol blog, MCP joins the Agentic AI Foundation |
| Decision framework and failure patterns | AppMatic Tech delivery data, see the ConstructionMCP case study |
Frequently Asked Questions
- Should I build an MCP server or a custom API for my LLM feature?
- AppMatic Tech asks three questions: will multiple LLM clients need this data within 18 months, does data access need centralised access control and audit logging, and does the LLM need three or more distinct data objects? If two or more answers are yes, an MCP server is the right architecture; if all three are no, a custom tool-calling API is usually sufficient.
- When is a custom API better than an MCP server?
- A custom API is better for a single narrow, application-specific tool, for an LLM client that does not support MCP, for integrations whose tool definitions change frequently during early development, and for teams whose mature API gateway and authentication tooling makes a new endpoint cheaper than a new server.
- Does MCP work with any LLM?
- MCP is model-agnostic, but the client application must implement the MCP client specification. By late 2025, MCP had first-class client support in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code. AppMatic Tech falls back to a custom tool-calling API for models or clients without MCP support.
- What is the most common mistake when choosing between MCP and a custom API?
- Choosing MCP because it is newer. A single endpoint that retrieves one user preference does not justify MCP infrastructure, and the team pays the cost without the benefits. The opposite mistake is building separate custom tools for a CRM, an ERP, and an internal database, which triples the authentication and maintenance surface an MCP server would centralise.
- Can an MCP server centralise access control for LLMs?
- Yes. An MCP server is a single boundary where access control, audit logging, and rate limiting are implemented once for every LLM that reads the data, regardless of which client is calling. A custom API approach spreads those concerns across individual tool endpoints, which AppMatic Tech finds harder to audit.