Read and write are different tools with different scopes. An agent granted only read tools physically cannot mutate the system — there is no write path to reach.
service · integrationsModel Context Protocolclaude-native · build on claude by default
Give every model one protocol to your systems.
We are an MCP server development company that ships production Model Context Protocol servers — typed tool schemas, real auth, stdio and HTTP transport, observability, and enterprise connectors for Salesforce, SAP, and ServiceNow. Not a thin wrapper. Architecture you can operate.
model context protocolcustom mcp servertyped tool schemassalesforce · sap · servicenowstdio · http transportclaude agent sdk
01The Model Context Protocol · why it matters
M times N is a mess. A protocol makes it M plus N.
One open standard between every model and every system, so your integrations outlive the model behind them.
The MxN problem
Every model that needs to reach every tool is a bespoke integration. M models times N systems is a combinatorial mess of one-off adapters that rot the moment an API or a prompt format changes.
What MCP changes
The Model Context Protocol is an open standard that turns M×N into M+N. A tool exposes itself once as an MCP server; any MCP-capable client — Claude, the Claude Agent SDK, Claude Code — speaks to it the same way.
Why it matters now
A protocol means your connectors outlive the model behind them. Swap Opus for Sonnet, add a second client, change the orchestration layer — the server you shipped keeps working untouched.
Where it pays off
Internal tools, data warehouses, ticketing, CRM, ERP. One well-typed server lets every agent in the company read and act on a system safely, with the same audit trail.
New to the standard? Read What is the Model Context Protocol? for the long-form explainer.
02Custom MCP server development · how we build
Auth, schemas, transport, observability — production from line one.
Four layers, none optional. This is what separates a server you can operate from a demo that breaks on the first real request.
01
Auth & identity
OAuth, mTLS, or signed service tokens at the boundary. The server runs as a real identity with scoped permissions — never a shared god-key.
oauth · mtls · scoped tokens02
Typed tool schemas
Every tool is a typed contract — JSON Schema in, JSON Schema out, validated both directions. The model cannot call a tool with a shape the system rejects.
json schema · zod · strict io03
Transport
stdio for local and Claude Code, streamable HTTP for remote and multi-client. We pick per deployment and keep the tool layer identical across both.
stdio · streamable http04
Deployment & observability
Containerised, health-checked, traced. Every tool call emits a span with arguments, latency, and outcome so you can see exactly what an agent did.
otel · traces · structured logs03Enterprise connectors · the systems that run your business
A Model Context Protocol server for Salesforce, SAP, ServiceNow.
The systems of record are where agents earn their keep — and where a careless integration does the most damage. We build the connectors that don't.
CRM
Salesforce
A Model Context Protocol server for Salesforce that exposes queries, record reads, and guarded writes as typed tools — built on the REST and Bulk APIs, scoped to the connected app you control.
ERP
SAP
An MCP server for SAP that reaches S/4HANA and ECC through OData and BAPI/RFC, with read paths separated from write paths and every mutation gated behind explicit approval tools.
ITSM
ServiceNow
An MCP server for ServiceNow over the Table API — incidents, change requests, CMDB lookups — typed so an agent can triage and update tickets without ever touching a field it should not.
Internal
Your services
Internal APIs, data warehouses, and legacy systems wrapped as first-class MCP tools. If it has an interface, we give your agents a typed, audited way to use it.
04A typed tool, in full
What a real MCP server looks like.
A minimal sketch on the Claude Agent SDK pattern — a read tool, a write tool behind its own scope, and a transport. Read and write are different tools on purpose.
typescriptsalesforce-mcp · server.ts
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";import { z } from "zod"; const server = new McpServer({ name: "salesforce-mcp", version: "1.0.0" }); // A typed tool: schema in, schema out, validated both ways.server.tool( "find_account", "Look up a Salesforce account by name. Read-only.", { name: z.string().min(1).describe("Account name to search for") }, async ({ name }) => { const account = await sf.query( "SELECT Id, Name, Industry FROM Account WHERE Name = :name LIMIT 1", { name }, ); return { content: [{ type: "text", text: JSON.stringify(account) }], }; },); // Writes live behind a separate, explicitly-scoped tool.server.tool( "log_activity", "Log a completed activity against an account. Requires write scope.", { accountId: z.string().describe("Salesforce Account Id"), note: z.string().max(2000), }, async ({ accountId, note }) => { requireScope("activity:write"); const id = await sf.createTask({ WhatId: accountId, Description: note }); return { content: [{ type: "text", text: `logged ${id}` }] }; },); await server.connect(new StdioServerTransport());05Security & governance
An agent should only ever see the tools you grant it.
A server that can touch your systems is a security boundary. We treat it like one.
Schemas reject malformed or out-of-range arguments before they touch your backend, so a confused or adversarial prompt cannot smuggle a bad call through.
Every tool invocation is logged with caller identity, arguments, and result. You can reconstruct exactly what any agent did, when, and on whose authority.
High-impact actions can require explicit approval — the server returns a confirmation step rather than executing, so destructive operations are never silent.
The server runs in your cloud account, inside your VPC, under your DPA. Claude is reachable on AWS Bedrock and Google Vertex AI when your governance requires it.
API keys and credentials live in your secret manager and never reach the model context. The agent sees tools, never the keys behind them.
06Related Claude work
A server is one piece. We build the rest of the stack too.
07Questions teams ask before they hire an MCP server development company
Seven things engineering leaders want answered.
What is the Model Context Protocol, in one line?
An open standard that lets any MCP-capable client — Claude, the Claude Agent SDK, Claude Code — talk to any tool or data source through one consistent interface, instead of a custom integration per pairing.
Why hire a custom MCP server development company instead of building it in-house?
We have shipped MCP servers to production and operate them on-call. We bring the auth, schema, transport, and observability patterns pre-solved, so you get a hardened server in weeks rather than discovering the edge cases yourself over months.
Can you build a Model Context Protocol server for Salesforce?
Yes. We expose Salesforce queries, record reads, and guarded writes as typed MCP tools over the REST and Bulk APIs, scoped to a connected app you own, with reads and writes separated.
Do you handle MCP servers for SAP and ServiceNow?
Yes. For SAP we reach S/4HANA and ECC via OData and BAPI/RFC; for ServiceNow we work over the Table API for incidents, change, and CMDB. Both ship with the same typed-schema and audit discipline.
stdio or HTTP transport — which do we need?
stdio for local processes and Claude Code; streamable HTTP for remote, multi-client, or hosted servers. We pick per deployment and keep the tool definitions identical across both so nothing changes when you move.
How do you keep an agent from doing damage through the server?
Least-privilege tools, schema validation at the boundary, secrets kept server-side, a full audit trail, and human-in-the-loop gates on high-impact actions. The agent only ever sees the tools you grant it.
Who owns the server when you are done?
You do, from day one. The repo is yours, the runbook is yours, and we stay on-call after ship to tune and operate it as your systems change.
end · next stepName one system.