Connect Your Systems to Any AI Client, Once
Custom MCP server development: Model Context Protocol servers that give Claude, ChatGPT, Copilot, IDEs and your own agents controlled access to your data and actions, built to the current specification and secured like any production API.
What does MCP server development involve?
MCP server development is the design, build and operation of an MCP server: a service that exposes an organisation's data and actions to AI applications through the Model Context Protocol, an open standard that defines how AI clients discover and call tools, read resources and use prompt templates, so one integration can serve many AI clients instead of being rebuilt for each.
Every AI assistant becomes more useful when it can reach your systems: the CRM, the job management platform, the policy library, the data warehouse. Before the Model Context Protocol, each of those connections was custom code written for one model or one product, and rewritten when you changed either. MCP, introduced by Anthropic in November 2024 and contributed to the Agentic AI Foundation under the Linux Foundation in December 2025, standardises that connection.
An MCP server describes what it offers in three forms the protocol defines: tools the model can execute, resources that supply context and data, and prompts that package common workflows. Any compliant client can then discover and use them. At the time of writing (September 2026), MCP client support is built into Claude, ChatGPT, Microsoft Copilot, Gemini, Cursor and Visual Studio Code, among others, and Anthropic's Messages API can connect to remote MCP servers directly through its MCP connector, in beta at the time of writing.
Writing a demo MCP server takes an afternoon. Writing a custom MCP server you can safely point at production data is a different job, and it is the one we do. The current specification (version 2026-07-28) defines two standard transports: stdio for servers launched locally by the client, and Streamable HTTP for remote servers. For remote servers, the authorisation framework is based on OAuth 2.1: the MCP server acts as an OAuth resource server, must publish protected resource metadata, must check that each access token was issued specifically for it, and must not pass tokens through to other services.
We implement that properly against your identity provider, so users only reach what their own permissions allow. Beyond the protocol, we design tools a model can use well (clear names, tight input schemas, useful errors, bounded result sizes), separate read tools from write tools, treat tool descriptions and returned content as untrusted, log every call, and version the server so an upgrade on the AI side does not break your integration. The result is one well governed interface to your systems that any approved AI client can use.
AWLabs is a Sydney based AI and software development company for growing businesses and enterprise. Sister company to All Webbed Up, a separate websites and marketing company.
Why have AWLabs build your MCP server?
Build Once, Use Everywhere
One MCP server can serve Claude, ChatGPT, Copilot, developer tools and your in house agents. When you change model provider or add a new AI client, the integration with your systems stays put, which removes a common source of vendor lock in.
OAuth Done to the Spec
Remote servers authenticate users through your existing identity provider using the OAuth 2.1 based flow the specification defines, with protected resource metadata, audience bound tokens and scope challenges. Users act with their own permissions, never a shared service account.
Tools Models Can Actually Use
Tool design decides whether an assistant uses your server well or flounders. We write precise descriptions, strict input schemas, paginated and size bounded results, and error messages that tell the model how to recover, then test them with real clients.
Read and Write Kept Apart
Read only tools and state changing tools are separated, scoped and rate limited independently. Destructive actions can require confirmation through the client. An organisation can approve the read only server widely and the write enabled one for a smaller group.
Every Call on the Record
Each tool call is logged with the user, client, arguments, result size and outcome, and can carry OpenTelemetry trace context. Security teams can see which AI clients touched which data, and investigate anything unusual.
Ready for a Moving Standard
MCP has had several specification revisions since 2024, including a move to a stateless request model in 2026. We build on the official SDKs, test against multiple clients and keep your server current, so a protocol update is routine maintenance rather than a rebuild.
What technologies do we use for MCP server development?
How do we deliver MCP server development?
Typical timings; your Schedule of Work sets the real ones.
Capability and Risk Mapping
We list what AI clients should be able to see and do in your systems, who should be able to do it, and which clients will connect. Each capability is classified by risk, and we decide which become tools, which become resources, and which should stay out of reach.
Interface and Auth Design
We design tool names, descriptions and schemas, choose local (stdio) or remote (Streamable HTTP) deployment, and design the authorisation flow against your identity provider, including scopes, token lifetimes and how existing role permissions map across.
Server Build
We implement the server on the official MCP SDKs over your APIs or databases, with input validation, pagination, rate limiting, structured errors and logging. Where your system has no suitable API, we build a thin service layer first.
Client Testing and Security Review
We test the server with the AI clients you plan to use and with scripted evaluation tasks, then run a security review covering token handling, scope enforcement, injection through returned content, excessive data exposure and denial of service limits.
Deployment and Rollout
We deploy into your cloud account behind your network controls, in an Australian region where your Schedule of Work requires it, and register the server with the approved clients. Rollout usually starts read only with a pilot group before write tools are enabled.
Handover and Upkeep
You receive the source code, test suite, client configuration notes and runbooks. We can maintain the server as the specification and client support evolve, adding tools as new use cases are approved.
Which organisations need an MCP server?
Is an MCP server the right fit?
When it is the right fit
- Several AI clients, such as Claude, Copilot, IDE assistants and your own agents, need access to the same systems
- You want staff to use approved AI assistants against live business data with their own permissions
- You sell software and want customers to connect it to the AI assistant of their choice
- You want to avoid rebuilding integrations every time you change model or AI vendor
- Your security team needs one governed, logged interface for AI access instead of many ad hoc ones
When it is not the right fit
- Only one application will ever call the system, where a direct API integration is simpler
- The system has no API and the data is not ready; data engineering or an API layer comes first
- A vendor already ships a maintained MCP server for the product and it covers your needs
- You need autonomous multistep work rather than access; that is agent development, which may use MCP underneath
- Your policy does not yet allow AI assistants near the data in question; governance should come first
MCP Server Development: a quick glossary
- Model Context Protocol (MCP)
- An open standard, built on JSON-RPC 2.0, that defines how AI applications connect to external systems to discover and call tools, read resources and use prompt templates.
- MCP Server
- A service that exposes capabilities to AI applications over MCP. It advertises tools, resources and prompts, and executes requests from connected clients.
- MCP Host and Client
- The host is the AI application a person uses, such as a desktop assistant or IDE. Inside it, an MCP client manages the connection to each MCP server.
- Tools, Resources and Prompts
- The three kinds of server feature in MCP. Tools are functions the model can execute, resources supply context and data, and prompts are templated messages and workflows for users.
- Streamable HTTP
- The standard MCP transport for remote servers, where each message is an HTTP POST to a single endpoint and replies return as JSON or a request scoped event stream. The alternative, stdio, is for locally launched servers.
- Protected Resource Metadata
- A document, defined in RFC 9728, that a remote MCP server must publish so clients can discover which authorisation server issues its access tokens.
Common questions about MCP server development
The Model Context Protocol is an open standard for connecting AI applications to external systems. It works a little like a universal adapter: your system runs an MCP server describing the tools, data and prompts it offers, and any AI application with an MCP client can discover and use them. It uses JSON-RPC 2.0 messages and is maintained as an open project under the Agentic AI Foundation, part of the Linux Foundation.
If only one application will ever call your system, a direct API integration may be simpler. MCP pays off when several AI clients need the same access, for example staff using Claude or Copilot, developers using an IDE assistant and your own agents. You build and secure the integration once and each client connects to it. If you already have a good REST API, the MCP server usually sits in front of it rather than replacing it.
It can be, if the server is engineered for it. The specification itself says tools represent arbitrary code execution and must be treated with caution, and that hosts must obtain user consent before invoking tools. We add the controls a production API needs: user level OAuth, least privilege scopes, separate read and write tools, rate limits, validation, logging and a security review. The main residual risk is prompt injection through content the assistant reads, which is why write actions stay narrow and confirmable.
At the time of writing (September 2026), MCP support is built into Claude, ChatGPT, Microsoft Copilot, Gemini, Cursor and Visual Studio Code, and Anthropic's Messages API can call remote MCP servers directly through its MCP connector, which is in beta. Support for individual features varies by client and changes often, so we test against the specific clients you intend to approve.
Local servers run on the user's machine over stdio and take credentials from the environment. They suit developer tools and personal workflows. Remote servers run over Streamable HTTP in your cloud and use the OAuth based authorisation framework. They suit shared business systems because access, logging and updates are managed centrally. Most business deployments are remote.
Increasingly, buyers expect AI assistants to work with the products they use. A published MCP server lets your customers connect your product to the assistant of their choice without you building a separate integration for each. The work then includes multitenant authorisation, per customer rate limits and a stable, versioned tool surface, which we design for from the start.
A focused server with a handful of read tools over an existing API typically takes 3 to 6 weeks including authorisation, testing and deployment. Servers that add write actions, span several systems or need to serve many customer tenants take longer. Every build starts with a Discovery Audit, a fixed fee credited in full against the build. After two strategy sessions you receive a fixed price Schedule of Work with three options: The Minimum, The Recommended and The Complete.
Every build is priced on its own scope. It starts with a Discovery Audit (a fixed fee, credited in full against the build). After the audit you get a fixed price Schedule of Work with three options: The Minimum, The Recommended and The Complete. The option you choose is paid in three stages against work you have accepted. We never publish day rates. Scope drives the price: the number of tools and systems, whether writes need confirmation flows, and how many AI clients must be tested.
A custom MCP server is the controlled doorway between AI clients and your own systems. The model decides what it wants to do; the server decides what it is allowed to do, runs the call against your API or database with the user's own permissions and returns a bounded result. Ready made MCP servers exist for many popular products, but anything specific to your business, such as an internal job system or a warehouse with your own access rules, needs a custom server.
Both. The official MCP SDKs include TypeScript and Python, the two languages we use most for servers. We usually match the language of the system the server sits in front of, so your team can maintain it alongside the code it already owns.
For a remote server, users add its URL in the client's connector or MCP settings and sign in through your identity provider, so they only see what their own account allows. A local server is configured with the command that launches it. We supply setup instructions for each client you approve and work with your administrators on how the server is approved and rolled out across the organisation.
RAG retrieves relevant passages from your documents so a model can answer from them. MCP is a standard way for an AI client to call tools and read data in your systems. They work together: a RAG search over your policy library can be exposed as one tool on an MCP server, alongside tools that look up a customer record or create a ticket. RAG is about grounding answers; MCP is about access.
No. An agent is the part that plans and decides what to do next; an MCP server is a set of tools and data it can use. The same MCP server can serve Claude, ChatGPT, Copilot and your own custom agents, each deciding when to call it. Building the server first gives every agent you add later the same governed access to your systems.
It depends on traffic and where it runs. A remote MCP server runs like any other small web service in your cloud account, so your cloud provider bills the hosting directly, separately from AI model usage, which the model provider bills. We size the hosting during design and show the expected running costs alongside the build options in your Schedule of Work.