MCP Server Development
We design, build and test Model Context Protocol servers in TypeScript, Python or your own stack, with read-only tools first and confirmed, audited actions.
An MCP server is the program that gives AI applications a standard way to use your data and actions. The Model Context Protocol (MCP) is an open, JSON-RPC 2.0-based protocol: an AI host creates one MCP client per server, and each server exposes tools (functions the model can call), resources (data addressed by URIs) and prompts (templates the user chooses). GeekMidst designs, builds and tests MCP servers remotely from India.
We have built and run one MCP server of our own: the public, read-only server at the /mcp endpoint on this website, described in the GeekMidst MCP server project. Any server we design for Salesforce, Marketing Cloud, Data 360, Braze or your internal systems is a proposed design: we validate the APIs, edition and permissions for each implementation.
Check vendor servers first: Salesforce Hosted MCP Servers are GA (29 April 2026), the Marketing Cloud Engagement MCP Server is GA (2 June 2026), and Braze describes its remote server as generally available (23 July 2026). If one fits, start with MCP integration consulting. Build a custom server when no vendor server covers the need or the data is your own.
What's included
| Area | What we cover |
|---|---|
| Architecture and readiness | Use cases, data classification, systems in scope, vendor server fit |
| Custom server development | TypeScript SDK v2 (@modelcontextprotocol/server 2.3.1) or v1 (@modelcontextprotocol/sdk 1.32.1), Python (mcp 2.3.0), or another stack |
| Tool schemas and input validation | JSON Schema per tool, unknown fields rejected, errors the model can correct |
| Resources and prompts | Resource URIs, pagination, and prompts for your own review steps |
| Read-only knowledge servers | Documentation and policy knowledge with cited passages |
| Controlled action tools | Write tools behind human confirmation, with honest annotations |
| Authentication and authorisation | OAuth 2.1 resource server per the spec: protected resource metadata, audience-checked tokens, minimal scopes |
| Audit logging and observability | Caller, tool, outcome and timing, without sensitive arguments |
| Deployment and versions | Environments, server-side secrets, protocol eras, tool versioning |
| Security testing and permission reviews | Tokens, origin checks, cross-user isolation, per-tool permissions |
| Client compatibility testing | SDK clients, MCP Inspector and your target hosts |
| Lifecycle and troubleshooting | Spec and SDK upgrades, deprecations, failing connections |
How we work
- 01
Discovery
We list the questions and actions people want help with, the systems behind them and their owners.
- 02
Design
We write the tool catalogue, permission model and confirmation rules before any code. Read-only tools come first.
- 03
Build
Business logic stays separate from the transport, so it is unit tested without an AI client.
- 04
Test
We run a protocol test matrix, then test with your target clients.
- 05
Launch
Sandbox or staging first, then production with monitoring and rate limits on.
- 06
Support
We track spec and SDK releases, review audit logs and add tools one at a time.
Prerequisites and licences
- Upstream API access. Vendor API limits apply to every tool call; check the vendor's limits.
- An identity provider for protected servers. Authorisation is optional in the spec, but non-public data needs it.
- Vendor licences. Salesforce Hosted MCP Servers are documented as intended for customers with Flex Credits. Confirm your contract.
- Runtimes. TypeScript SDK v2 needs Node 20+; the Python SDK needs Python 3.10+.
The current protocol revision, 2026-07-28, is stateless, but the official TypeScript SDK client and the MCP Inspector still default to the older initialize handshake, so we usually support both. See the MCP architecture guide.
Who it suits
Teams whose knowledge or APIs no vendor server covers, and platform teams standardising how assistants reach company systems.
Common mistakes
- One large server for every domain, so a single permission review covers everything.
- Generic "run any query" tools instead of narrow, named operations.
- Passing the user's upstream token straight through. The spec forbids it.
- Write tools with no confirmation step, or annotations treated as a security control (they are hints).
- Testing with a single client and a single protocol version.
Related services
See MCP integrations, the MCP host, client and server architecture, MCP security and authorisation and MCP security and governance. If the main job is connecting systems rather than serving AI, start with MCP vs direct API integration.
Questions we hear
Do we need a custom server if the vendor has one?
Which language should the server use?
Can the AI change data through the server?
How do users sign in?
Sources
- https://modelcontextprotocol.io/docs/learn/architecture
- https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
- https://modelcontextprotocol.io/specification/2026-07-28/changelog
- https://www.npmjs.com/package/@modelcontextprotocol/sdk
- https://pypi.org/project/mcp/
- https://developer.salesforce.com/blogs/2026/04/salesforce-hosted-mcp-servers-are-now-generally-available
Plan your MCP server
Tell us which systems and questions you want an assistant to handle. We will suggest a read-only first version and a test plan.
