AppMatic Tech builds MCP servers in four phases: resource and tool design, a stateless protocol handler on the official MCP SDK, a parameterised data access layer with per-user authentication, and validation against real LLM queries under load, in Node.js, TypeScript, or Python. AppMatic Tech is based in Ahmedabad, India, with 330+ products shipped since 2017.
An MCP server build has a defined sequence. The sequence matters because each phase produces decisions that constrain the next. Teams that skip the resource design phase and start with implementation discover at the integration phase that the schema needs restructuring. Teams that skip load testing discover at launch that the server handles sequential requests correctly but degrades under concurrent load. The four phases below reflect the build order AppMatic Tech follows across all MCP server engagements.
AppMatic Tech has delivered MCP servers for construction, healthcare, and SaaS clients across 330+ product builds since 2017, including the ConstructionMCP platform that saved field teams 32% of project management time. The guidance below comes from that production experience, not from documentation examples.
Phase 1: How do you design MCP resources before writing code?
The most consequential decisions in an MCP server build happen on paper, not in a code editor. Resource design determines what data the LLM can access, at what granularity, and through what query patterns. Getting this wrong requires rework that touches every subsequent phase.
Start by listing every question the LLM needs to be able to answer using live business data. For a construction platform this might be: which projects are behind schedule, show me foundation photos from Site B uploaded last Thursday, generate a safety compliance summary for Project X. For a CRM integration it might be: what is the current pipeline value for this account, which deals are due to close this month, what were the last three interactions with this contact.
Each question maps to a resource, a named, schematised data object the MCP server exposes. In Model Context Protocol terms, parameterised lookups the model invokes are declared as tools and read-only data addressed by URI is declared as resources; this guide uses resource for the data object behind either. The resource name and description are what the LLM uses to decide which resource to query for a given user request, so the descriptions need to be precise. A resource described as "project data" will be queried for requests it cannot answer. A resource described as "live construction project records including status, milestones, team assignments, and task completion percentages" will be queried correctly.
Define the schema for each resource: the fields it returns, the filter parameters it accepts, and the data types for each. Use the strictest typing that the underlying data supports. A field that is sometimes a Unix timestamp and sometimes an ISO string should be normalised to one format at the data access layer before it reaches the resource schema.
AppMatic Tech typically completes resource design in two to five business days during the discovery session. The output is a written resource specification that both the engineering team and the product team can read and validate before implementation begins.
Phase 2: How should the MCP protocol handler be implemented?
The protocol handler is the component that parses incoming MCP messages, validates them against the resource schemas, and routes them to the appropriate data access function.
For most MCP server builds, AppMatic Tech uses the official MCP SDK for TypeScript or Python, which provides the protocol message parsing and serialisation layer. The SDK handles the Model Context Protocol specification compliance, which leaves the implementation work focused on resource handlers and data access rather than protocol internals.
The protocol handler should be implemented as a stateless request processor. Each request is handled independently. State that needs to persist across requests, such as a user's authentication token or a session context, belongs in the data access layer or in an external session store, not in the protocol handler itself. Stateless handlers scale horizontally without session affinity requirements, which is the architecture that supports production load.
Implement error handling at the protocol layer before connecting the data access layer. Every resource handler should return structured error responses for invalid parameters, missing required fields, and unsupported operations. Testing error paths before the data access layer is connected means the error handling works correctly under real LLM query patterns, which frequently include edge cases the initial implementation did not anticipate.
Phase 3: How should the data access layer connect to live systems?
The data access layer translates validated MCP resource requests into database queries or API calls. Three decisions at this phase have the most impact on production reliability.
Parameterised queries, always. Every database query should be constructed from validated, typed parameters extracted by the protocol handler. Do not build queries by interpolating strings from LLM output or from unvalidated request fields. LLMs occasionally produce unexpected parameter values. Parameterised queries mean those values are handled safely by the database driver rather than reaching the query parser.
Minimum necessary data retrieval. Each resource handler should retrieve only the fields the resource schema defines, not a full row or document. SELECT * queries against wide tables return more data than the LLM needs, increase the payload size that passes through the server, and degrade response time as the data volume grows. Define the SELECT list explicitly for every query.
Authentication at the data access layer. For single-tenant deployments with a single service credential, API key authentication managed centrally in environment variables is appropriate. For multi-tenant products where different users have different data access rights, the authentication pattern needs to be designed explicitly. AppMatic Tech implements per-user token passthrough for healthcare and financial services builds, where the MCP server forwards the requesting user's credential to the downstream system rather than holding a single shared credential.
Phase 4: How do you validate an MCP server under real LLM load?
The final phase before deployment is validation against realistic LLM query patterns and realistic load. This phase surfaces failures that unit tests and sequential integration tests do not.
LLM query behaviour validation means testing the MCP server by running the intended LLM through realistic user scenarios, not by calling the resource handlers directly with known-good inputs. LLMs route queries to resources based on the resource descriptions and the user's input. Testing with the actual LLM reveals cases where the model routes a query to the wrong resource, sends filter parameters in an unexpected format, or makes multiple sequential resource calls to assemble context that a single well-designed resource could have provided.
Load validation means running the server under concurrent request volume that matches or exceeds the expected production peak. The failure modes that appear under concurrent load are different from sequential failures. Connection pool exhaustion in the data access layer, race conditions in authentication token handling, and memory pressure from large response payloads are all patterns that appear under load but are invisible during sequential testing.
AppMatic Tech runs load testing at 500 requests per minute as a standard deliverable on all MCP server builds. This is not a performance benchmark, it is a regression test: if the server behaves correctly at 500 RPM during QA, it will behave correctly at production load for the client's expected usage volume.
What does an agency-built MCP server deliver that in-house builds miss?
The four phases above are each straightforward to describe and require significant engineering judgement to execute correctly. The decisions that most commonly go wrong in in-house MCP builds are resource schema design, which requires understanding both the LLM's query routing behaviour and the downstream data model simultaneously, and load testing, which requires realistic concurrent query patterns that are time-consuming to construct.
AppMatic Tech's standard single-source MCP server build takes 4 weeks from discovery to handover at a fixed price of $25,000. The engagement includes the full build process described above plus 30 days of post-launch support. For multi-source builds and enterprise integrations with per-user authentication, AppMatic Tech scopes and prices individually after the discovery session.
Full engagement details are on the MCP Server Development service page. For the architecture context that informs the decisions in each phase, see MCP Server Architecture: How It Works Under the Hood.
For a delivered example, see how AppMatic Tech built the ConstructionMCP project management platform with a Flutter app and a Laravel backend. Contact AppMatic Tech at contact@appmatictech.com to start the build conversation.
Related MCP guides from AppMatic Tech: what is an MCP server and when a business needs one, MCP server security best practices, and MCP server vs custom API.
Frequently Asked Questions
- How do you build an MCP server?
- AppMatic Tech builds MCP servers in four phases: design the resources and tools the LLM needs on paper first, implement a stateless protocol handler on the official MCP SDK, connect a data access layer that uses only parameterised queries, and validate the server with the real LLM under concurrent load. Each phase constrains the next, so skipping design causes rework later.
- Which SDK should be used to build an MCP server?
- AppMatic Tech uses the official MCP SDK for TypeScript or Python, which handles protocol message parsing, serialisation, and specification compliance. That leaves the engineering effort on tool and resource handlers and the data access layer rather than protocol internals.
- How should an MCP server authenticate to business systems?
- For single-tenant internal tools, a service credential held centrally in environment configuration is appropriate. For multi-tenant products and healthcare or financial services builds, AppMatic Tech uses per-user token passthrough, forwarding the requesting user's credential so the downstream system enforces that user's permissions.
- How do you stop an LLM from injecting SQL through an MCP server?
- AppMatic Tech builds every query from validated, typed parameters extracted by the protocol handler and never interpolates LLM output into SQL, so unexpected values are handled safely by the database driver. Each handler also selects only the fields its schema defines, never SELECT *, which limits payload size and data exposure.
- How is an MCP server tested before launch?
- AppMatic Tech runs the intended LLM through realistic user scenarios to catch mis-routed queries and unexpected parameter formats, then load-tests the server at 500 requests per minute. Concurrent load exposes connection pool exhaustion, token handling race conditions, and memory pressure that sequential tests never show.