MCP server development becomes a business purchase when an AI assistant needs reliable access to your company’s systems. The interesting part is rarely making a tool appear in a chat window. It is deciding which records the assistant can see, what it can change, and how your team knows whether an operation actually finished.
Commission a custom MCP server when a supported connector cannot deliver a clearly defined business workflow with the permissions and operational controls you need. Start with a narrow task, test it in the intended AI client and keep authorisation in the connected system. Budget for integration, failure handling and maintenance as well as the protocol interface.
Imagine a sales colleague asking an assistant for the status of a customer order. Reading the permitted order is a useful first scope. Changing a delivery address, cancelling an order or emailing the customer introduces different authority and recovery requirements. Treating all of these as one generic integration makes the project harder to price and harder to accept.
This guide explains how to commission that work, compare an existing connector with a custom build, and request evidence before expanding access. The examples are proposed designs, not descriptions of customer deployments or promises of a particular saving.
What MCP server development adds to an existing API
The official MCP architecture overview describes a host application, its clients and connected servers. Servers can expose tools, resources and prompts. Tools provide executable operations; resources provide context; prompts provide reusable interaction templates. A server can run locally or remotely.
An existing API still does the business work. The MCP layer gives an AI application a discoverable interface to selected operations, with descriptions and structured inputs and results. It does not replace your accounting system, invent missing API capabilities or determine the commercial meaning of a record.
For the order example, a useful interface could accept an order reference and return its status, observation time and permitted next steps. A raw database wrapper that accepts arbitrary queries would give the assistant a much wider surface than the task requires. Our recommendation is to design the interface around the outcome a colleague is authorised to obtain.
The protocol also does not decide whether a response is good enough for your customer. That remains an application and business decision. A technically successful tool call can return an incomplete record, stale information or an answer whose meaning depends on another system.
Compare a connector, direct API integration and a custom server
Begin with what already exists. A supported connector may cover the required read operation with less bespoke code to own. Check its actual tool set, account permissions and available deployment options rather than assuming its name proves it supports your workflow.
| Approach | A reasonable fit | Evidence to request |
|---|---|---|
| Existing MCP connector | Its tools and access model match the task | Demonstration with your client and ordinary user permissions |
| Direct API integration | A single application needs a fixed workflow | Clear authentication, operation handling and maintenance ownership |
| Custom MCP server | Your task needs a tailored interface across intended MCP clients | Defined tool contracts, compatibility tests and operational handover |
| Conventional automation | The steps and decision rules are already deterministic | Exception handling and destination reconciliation |
MCP is useful when the assistant needs to discover and select appropriate business operations. If a scheduled job always copies an approved record into the same destination, a conventional integration may be simpler. Introducing a model into that path should have a reason beyond making the architecture fashionable.
Avoid commissioning a universal server before proving the first workflow. Broad interfaces accumulate permissions, tool descriptions and support obligations. A small useful interface gives the team a concrete basis for deciding what to add next.
Define tools around business decisions
Write each tool contract before implementation. It should explain the caller, required inputs, permitted records, result meaning and failure states. Define which fields are identifiers and which are display text. Specify what happens when the reference is ambiguous or the destination is unavailable.
Separate reading from making a commitment
An illustrative tool called get_order_status retrieves information. A separate prepare_address_change could validate a proposed address and show the effect without changing the order. An apply_address_change operation would require its own authorisation and business checks. These names are examples, not standard MCP methods.
This separation makes review useful. The person approving a change should see the destination, the affected record and the proposed values. A vague confirmation that an assistant wants to use a tool provides little evidence that the person understood the business consequence.
Return outcomes the assistant can explain
Distinguish a completed operation from a rejected request and an uncertain result. If an upstream system times out after receiving a change, returning a generic failure can encourage an unsafe retry. The integration should preserve an operation reference and provide a way to inspect the destination before deciding what to do next.
Keep results concise but sufficient. A status, source reference, observation time and reason for a refusal are often more useful than an unrestricted record dump. The right result depends on the task and the sensitivity of the source data.
The MCP tools specification defines input schemas and supports structured tool results. Use those contracts to make required fields and returned evidence explicit. A valid schema still needs tests against the destination’s business rules.
Keep identity and permissions explicit
The MCP authorisation specification describes an authorisation framework for HTTP transports. Local standard-input/output integrations use a different credential approach. Agree the deployment and intended clients before choosing an authentication design, and verify the supported specification during implementation.
There are distinct access decisions in a business integration. The caller needs permission to use the MCP server. The server also needs appropriate authority in the destination application. A successful login to the first does not automatically establish access to every customer record in the second.
Test the ordinary user’s scope
For a shared remote service, document how the requesting user and organisation are identified. Check how that scope reaches the backend, especially if the server uses a service account. Test attempts to read another customer’s order, modify a protected field and use an expired or revoked identity.
The official MCP security guidance warns against token passthrough: accepting and forwarding tokens without the appropriate validation introduces security risks. Do not turn a custom server into a general credential relay. Ask the implementation team to explain token audiences, credential storage and the authority used for each downstream operation.
Permissions should remain enforceable even if the assistant proposes an inappropriate action. Tool descriptions help guide selection; they are not substitutes for a backend authorisation check. Our separate AI agent security guide covers the wider questions around hostile inputs, approval and limited autonomy.
Test compatibility and uncertain outcomes
The MCP transport specification describes standard-input/output and Streamable HTTP transports. Agree which transport and clients the project will support. A deployment choice changes the connection and authentication work; it does not remove the need to test the business outcome.
A server that works in a developer’s test harness still needs testing in the client’s actual application. Identify the intended hosts, account types and deployment environment. Verify discovery, input validation, result presentation and the approval experience for the agreed operations.
| Test situation | Expected evidence | Acceptance decision |
|---|---|---|
| An authorised user requests a permitted record | Correct result and source reference | The workflow answers the intended question |
| A user requests another organisation’s record | Backend refusal without disclosure | Isolation holds outside the happy path |
| A required reference is missing or ambiguous | Validation or clarification | The integration does not guess the record |
| A write request receives an uncertain response | Operation reference and reconciliation path | Retry is held until the outcome is understood |
| The destination is unavailable | Clear error and owned escalation | Colleagues know how to continue manually |
Use representative examples supplied by the workflow owner. Include records with awkward but legitimate values, missing fields and changed permissions. Keep sensitive test data controlled and document what was used; copying live customer records into a development environment should not be the default test strategy.
Define acceptance before the supplier demonstrates the finished integration. Otherwise the most impressive example can quietly become the standard, while the cases that matter to operations remain untested. Keep the evidence with the tool and deployment version so it can be repeated after changes.
Plan support, recovery and handover
Operational ownership is part of the deliverable. Someone must know who receives alerts, who can disable a write tool and how to investigate a disputed operation. Logging should support that investigation without collecting unrestricted customer content or secrets.
For the order workflow, record enough to connect a request to its user scope, tool, destination reference and observed result. Agree what happens if a write is already in flight when access is revoked. Where an operation cannot be safely reversed, prevention and reconciliation matter more than a generic promise of rollback.
Request source code, deployment instructions, configuration ownership, tool documentation and a repeatable acceptance suite. Include dependency and protocol compatibility checks in the maintenance arrangement. A handover that only shows how to start the server leaves your team dependent on the original developer when a connected system changes.
What determines the development cost?
The number of tools is a poor pricing measure on its own. A read-only lookup against a documented API has a different scope from a write operation involving several organisations, approval, uncertain outcomes and a legacy backend. Ask for a scoped proposal in GBP with assumptions and exclusions.
| Work package | What it should establish | Common reason scope grows |
|---|---|---|
| Discovery | Workflow, API access and intended clients | The source system lacks a supported operation |
| Identity and access | Caller scope and downstream authority | Shared service identities hide record boundaries |
| Tool implementation | Validated inputs and meaningful outcomes | Business rules are undocumented or contradictory |
| Testing and release | Compatibility, failures and acceptance evidence | Several clients behave differently |
| Operations and handover | Monitoring, recovery and maintenance ownership | Nobody owns upstream changes or exceptions |
Separate development cost from hosting, model use, monitoring and ongoing support. Not every tool call requires the same amount of model work, and a protocol interface does not establish the cost of the surrounding assistant. Model the actual workflow and expected usage rather than quoting an unsupported universal cost per agent.
Compare proposals by their accepted outcome. A cheaper demonstration may omit the identity mapping, failure handling and documentation that make the integration useful in daily work. Equally, a large custom platform may be unnecessary when an existing connector meets the brief.
Commission a bounded first integration
Prepare a brief describing the user, business task, source systems and destination. Include representative requests, operations that are excluded, required client applications and what your team will accept as evidence. Identify the person who can decide how exceptions should be handled.
Our AI integration service provides a starting point for discussing that bounded workflow. We can assess whether a custom MCP interface belongs in the design, or whether an existing connector or direct integration better fits the requirement. The implementation approach follows the task and access constraints.
If you are ready to scope work, send us the workflow and intended systems . Share a redacted example and the decision you want the integration to support. We can use that to discuss discovery, acceptance tests and a proposal without assuming every available API should become an agent tool.
Frequently Asked Questions
What is MCP server development? MCP server development creates an interface through which compatible AI applications can discover and use selected tools, resources or prompts. For a business integration, the work also includes the connected system’s access rules, operation handling, testing and maintenance.
Do we need a custom MCP server if our software has an API? Not always. An existing connector or direct API integration may already meet the task. A custom server is worth considering when you need a tailored MCP interface with specific workflows, access boundaries and supported clients.
Can an MCP server make changes to business records? It can expose tools that request changes if the connected system supports them. Those operations need explicit permissions, validated inputs and agreed approval and recovery behaviour. Exposing a tool does not make every caller authorised to use it.
How much does custom MCP server development cost? Cost depends on the source APIs, identity model, operations, intended clients, testing and operational requirements. Request a scoped GBP proposal that separates discovery, implementation, acceptance, hosting and maintenance rather than comparing tool counts alone.
What should an MCP development handover include? Request source code, deployment and configuration instructions, documented tool contracts, repeatable acceptance tests and named support ownership. The handover should explain how to restrict access, disable operations and reconcile uncertain results after a failure.
Can we start with read-only tools? Yes. Start with a bounded lookup when it answers a useful business question. Add write operations only after their permissions, approvals and recovery paths are agreed.
Should we retry a tool call after a timeout? Not automatically when the call could change a record. A timeout can mean the response was lost after the destination completed the operation. Keep the operation reference, inspect the destination and establish whether the intended effect happened. Retry only under an agreed policy that prevents a repeated business effect. If the outcome cannot be established, route the case to a named owner instead of asking the assistant to guess.
How can we compare two MCP development proposals? Give both suppliers the same workflow, intended clients, access constraints and acceptance examples. Compare what they include in discovery, implementation, failure testing and handover. Ask each to identify unresolved assumptions and excluded operations. Tool counts alone do not show whether either proposal will deliver a workflow your team can operate.