Model Context Protocol

MCP Server Development Services

Give your agents real access to real systems — without handing over the keys

An agent is only as useful as the systems it can reach. We build custom MCP servers that expose your CRM, ERP, data warehouse and internal APIs to AI agents through a single typed interface — with scoped auth, rate limiting and a full audit trail on every tool call.

MCPTOOL CALLINGSALESFORCENETSUITESAPOAUTH 2.1AUDIT LOGGING

Typed

Schema-validated tools, not free-text prompt glue

Scoped

Per-tool permissions mapped to your existing roles

Audited

Every call logged with actor, args and result

2–6 weeks

Typical time from kickoff to production server

Why Zenthos

Most MCP servers fall over the moment they leave the demo

The Model Context Protocol made it trivial to wire a model to a tool. It did not make it trivial to do that safely against a production system. The reference implementations assume a single trusted user on a laptop. Your Salesforce org has field-level security, your NetSuite instance has governance limits, and your finance team has an auditor who will ask who approved a write.

That gap is where most MCP projects stall. A server that works beautifully against a sandbox starts throwing 429s under real concurrency, leaks records the calling user was never entitled to see, or gives an agent a delete tool with no approval gate. None of these show up in a proof of concept.

We build MCP servers the way you would build any other production service: typed schemas, explicit permission boundaries mapped to your existing identity model, rate limiting that respects upstream quotas, structured logging on every invocation, and a test suite that runs against recorded fixtures so you can change a tool without praying. The agent gets capability. Your security team gets a review it can actually sign off.

What We Deliver

Core Capabilities

[01]

Custom MCP Server Development

Purpose-built servers in TypeScript or Python exposing your internal systems as typed, discoverable tools. Stdio for local agents, HTTP/SSE with proper session handling for hosted deployments.

[02]

Enterprise System Connectors

Salesforce, NetSuite, SAP, HubSpot, Snowflake, Postgres and internal REST/GraphQL APIs. We handle the pagination quirks, governance limits and field-level security each one imposes.

[03]

Auth, Scoping & Permissions

OAuth 2.1 with PKCE, service-account delegation, and per-tool scopes mapped to your existing roles — so an agent acting for a support rep cannot read what that rep cannot read.

[04]

Human-in-the-Loop Approval Gates

Destructive and high-value tools route through an approval step before execution, with the proposed arguments rendered for a human to accept or reject. Configurable per tool and per threshold.

[05]

Observability & Audit Trails

Structured logs for every tool call — actor, arguments, latency, result, error — exported to your existing stack. The record an auditor asks for, available before they ask.

[06]

Hardening & Security Review

Prompt-injection resistance on tool descriptions, argument validation, egress controls, secret handling, and a written threat model for the server you are about to put in front of an LLM.

How It Compares

Custom MCP server vs. the alternatives

There are three realistic ways to connect an agent to an internal system. They fail in different places.

Custom MCP serverOff-the-shelf connectorDirect API integration
Time to first working toolDaysHoursDays to weeks
Works across agent frameworksYes — any MCP client (Claude, OpenAI Agents SDK, LangGraph, Cursor)Usually one vendor’s runtime onlyNo — rewritten per framework
Permission modelMapped to your existing roles, per-tool scopesVendor’s model, often all-or-nothingWhatever you build
Handles upstream rate limitsYes — backoff, queueing, quota awarenessVaries, usually opaqueOnly if you implement it
Audit trailStructured, per-call, exportableVendor-dependent, often absentOnly if you implement it
Custom business logicAnyLimited to exposed endpointsAny
Who maintains itYou (or us, on retainer)The vendor — including breaking changesYou
Best whenThe system is core to your business and the agent needs write accessYou need read-only access to a common SaaS tool, fastOne model, one framework, no plans to change

Off-the-shelf connectors are the right call more often than vendors like us admit. If you need read-only Slack or Google Drive access, buy it. Build when the system is differentiating, the permissions are non-trivial, or an agent needs to write.

How We Work

Our Process

01

Tool Surface Design

We map what the agent actually needs to do to a minimal set of tools. Fewer, better-described tools beat a thin wrapper over sixty endpoints — model accuracy drops sharply as the tool list grows.

02

Auth & Permission Model

Decide how the server authenticates to the upstream system and how the calling identity maps to scopes. This is settled before any tool is written, because retrofitting it is expensive.

03

Build & Instrument

Typed schemas, argument validation, error surfaces the model can recover from, rate-limit handling, and structured logging wired in from the first commit rather than bolted on later.

04

Adversarial Testing

We test against recorded fixtures, run prompt-injection attempts at the tool descriptions, and verify permission boundaries hold when the agent is actively trying to exceed them.

05

Deploy & Hand Over

Containerised deployment into your infrastructure, runbook, threat model document, and a test suite your team can run in CI. You own the code.

Tools & Technologies

Tech Stack

We choose the right tool for the job — not the trendiest one.

TypeScript
Python logoPython
MCP SDK
OAuth 2.1
PostgreSQL
Docker logoDocker
OpenTelemetry
AWS logoAWS
Questions

Frequently Asked Questions

What is an MCP server, in practical terms?
It is a small service that describes a set of tools in a standard format and executes them when an AI agent asks. Because the format is standardised, the same server works with Claude, the OpenAI Agents SDK, LangGraph, Cursor and any other MCP-compatible client — you write the integration once instead of once per framework.
How long does a custom MCP server take to build?
A read-only server over a well-documented API is typically two to three weeks. A server with write access, an approval workflow and a non-trivial permission model is usually four to six. The variable is almost never the MCP layer — it is how strange the upstream system is.
Should we build an MCP server or use an existing connector?
Use an existing connector when you need read-only access to a common SaaS product and speed matters more than control. Build when the system is core to your business, when permissions need to mirror your own roles, or when the agent needs write access — those three cases are where off-the-shelf connectors tend to run out of road.
How do you stop an agent from doing something destructive?
Three layers. Tools are scoped so the destructive ones are not exposed to agents that should not have them. High-impact tools route through a human approval gate that renders the proposed arguments before execution. And every call is logged, so if something does go wrong you can reconstruct exactly what happened rather than guessing.
Can you connect an MCP server to Salesforce, NetSuite or SAP?
Yes — those three are the most common requests we get. Each has its own tax: Salesforce has field-level security and API limits, NetSuite has governance units that will silently throttle you, and SAP varies enormously by deployment. We budget for those explicitly rather than discovering them in week three.
How do you handle prompt injection through tool results?
Tool descriptions and returned data are both untrusted input. We validate and constrain what comes back, avoid echoing raw upstream content into instruction context where we can, keep destructive operations behind approval gates regardless of what the model believes it was told, and test with deliberately malicious fixtures before shipping.
Do we own the code?
Yes. Everything we build is delivered into your repository with tests, a runbook and a threat model. There is no runtime dependency on Zenthos and no per-seat licence. Retainer support is available if you want it, but it is optional.
Do you work with companies outside India?
Most of our engagements are with teams in the US, UK and EU. We work in overlapping hours with both coasts and European time zones, and we are used to operating inside client security reviews, DPAs and procurement processes.
Insights

Related Articles

View all →

Ready to connect your agents to real systems?

Tell us which system you need an agent to reach and what it needs to do there. We will tell you honestly whether to build, buy, or leave it alone for now.