When a client says "we want AI that can access our systems", the real work begins. Building a custom MCP server isn't just writing code — it's understanding your business, mapping your data, designing security controls, and delivering something your team will actually use every day.
Here's how we do it, step by step.
Phase 1: System Discovery (Days 1-3)
We start by mapping every system the AI needs to talk to. Not just the obvious ones — the databases and CRMs — but the edge cases: the spreadsheet on the shared drive that everyone relies on, the legacy system with the awkward API, the email inbox that's actually a critical workflow tool.
For each system we document:
- What data it holds and how it's structured
- How it's currently accessed (API, direct database, file system)
- Who uses it and what they need from it
- Authentication and security requirements
- Data sensitivity classification
Phase 2: Capability Design (Days 3-5)
This is where we define what the AI will be able to do — and critically, what it won't. For each system connection, we specify:
- Tools: The specific actions the AI can perform (search, read, create, update)
- Permissions: What data fields are visible, what's hidden, what's read-only
- Filters: Automatic restrictions (e.g., a recruiter's AI only sees their own candidates)
- Rate limits: How many queries per minute to prevent bulk extraction
- Response formatting: How data is structured when returned to the AI
We present this as a capability document — a clear specification of what the MCP server will do. You review and approve before we write a line of code.
Phase 3: Build (Days 5-12)
We build the MCP server in modular components:
- Connectors: Secure, authenticated connections to each of your systems
- Tool definitions: The MCP protocol interface that the AI model uses
- Business logic: Your specific rules — how data should be filtered, formatted, and validated
- Audit logging: Every request and response captured for compliance
- Error handling: Graceful failures that don't expose system internals
Each component is tested independently, then integrated and tested as a complete system.
Phase 4: Security Review (Days 10-12)
Before anything goes live, we run a thorough security review:
- Attempt to access data outside the defined permissions
- Test prompt injection scenarios (can a user trick the AI into bypassing controls?)
- Verify audit logs capture everything
- Confirm rate limiting works under load
- Check that error messages don't leak system information
We fix anything we find. Your security team is welcome to run their own review — we encourage it.
Phase 5: Deployment & Testing (Days 12-14)
We deploy the MCP server on your infrastructure and connect it to your AI model. Then we test with real users doing real tasks:
- Can the recruiter find candidates as expected?
- Does the accountant get accurate invoice data?
- Are the solicitor's document searches returning relevant results?
- Is the response time acceptable for interactive use?
We iterate based on feedback until the team is confident in the system.
What Makes a Good MCP Server
After building dozens of these, we've learned what separates a useful MCP server from a frustrating one:
- Speed: Responses in under 2 seconds. If the AI takes 10 seconds to check the database, nobody will use it
- Accuracy: The right data, formatted correctly, every time. No hallucinated results mixed with real data
- Appropriate scope: The AI should be able to do everything the user needs, and nothing they don't. Too narrow is frustrating; too broad is a security risk
- Clear errors: When something goes wrong, the AI should explain what happened in plain language, not return a cryptic error code
- Maintainability: When your systems change (new fields, new APIs, new business rules), the MCP server should be easy to update
A custom MCP server should feel invisible. The user asks a question, gets an answer from their data, and never thinks about the infrastructure making it happen.
After Deployment
An MCP server isn't a "build it and forget it" project. We provide ongoing support:
- Monitoring: We track usage patterns, response times, and error rates
- Updates: When your systems change, we update the connectors
- Expansion: As you identify new use cases, we add new tools and connections
- Optimisation: We tune queries and caching based on real usage data
Most clients start with one or two system connections and expand over time. The first MCP server proves the value; the subsequent ones are faster and cheaper because the infrastructure is already in place.
Talk to us about building a custom MCP server for your systems. We'll start with a discovery session to map what you need.