MCP development

When you need this

• Customers are asking to use your product from their AI assistant or their own agents, and you need a server that exposes the right operations, not a thin wrapper over your whole API.
• You wrote an MCP server in a weekend and it works locally over stdio, but you now need remote transport, authentication and per-user authorization before anyone outside the team can use it.
• Your agent has a growing pile of one-off tool wrappers, and you want a single protocol boundary with logging and consent instead of maintaining each integration by hand.
• Internal operations such as admin actions, reports and workflow triggers should be drivable by an AI operator, with an audit trail of exactly what it did.
• You need to connect a LangGraph agent to several third-party MCP servers and manage tokens, scopes and failures across them without the run falling over.

What you get

• MCP server in Python or TypeScript exposing tools, resources and prompts for your product
• Transport and deployment: stdio for local developer use, remote HTTP for production, packaged with Docker
• OAuth / MCP relay for remote servers: authorization flow, token handling and per-user scoping
• Per-tool consent and a tool-call ledger so actions are approved before they run and auditable afterwards
• MCP client integration in your LangGraph or custom agent, with tool-calling hardening
• State and retry handling for tool turns so an interrupted call can be resumed instead of repeated
• Evaluation tests per tool plus integration tests driven by a real MCP client
• Documentation: server reference, tool descriptions written for models, a runbook, and a guide to adding a tool

Outcomes

• An MCP server whose tool surface is deliberately designed: named for the user's task, typed, described for a model to read, and small enough to reason about.
• Remote access with OAuth-based authorization, so each user's tool calls run under that user's identity and scopes rather than a shared service key.
• Every tool call logged with its inputs, outputs and outcome, and tools with side effects gated behind explicit user consent.
• Client-side connectors in your agent that handle discovery, token refresh and server failures without crashing the run.
• Tests that exercise each tool end to end against a real client, used as the acceptance criteria for the sprint.

How it works

1. 1

   20-minute technical call

   We look at what an assistant or agent should be able to do with your product, who the users are, and what already exists: an API, an SDK, an internal admin, a half-built server. I also ask which actions must never happen without a human.

2. 2

   Written diagnosis

   You receive a written diagnosis: which operations belong in the tool surface and which do not, how authorization has to work for your users, where consent is required, what the transport and hosting should be, and what an existing server gets wrong if there is one.

3. 3

   Fixed-scope proposal

   A fixed-scope proposal under the AI Agent Engineering Sprint, starting at $1,200 for 7–10 working days. It lists the tools, the auth model, the tests and the deployment that define done, in writing.

4. 4

   Implementation and handover

   I build the server, the auth layer and the client integration, test every tool against a real client, and hand over the code, the documentation and a runbook. Your team gets a written guide for adding the next tool without me.

Proof: what I built

• In OmidGPT I built the MCP connectors and the OAuth / MCP relay that let the agentic runtime reach external tools under each user's authorization, with resumable tool turns, a tool-call ledger and per-tool user consent. The platform exposes 209 API endpoints.

  Read the OmidGPT case study

• For AiMatin I wrote a custom Node.js MCP server through which an AI operator runs the academy's admin workflows, such as coupons, popups, funnel automations and reports, against a FastAPI and PostgreSQL backend.

  Read the AiMatin case study