AI agents and MCP servers
Agents that act in your tools with permissions, audit logs and a person in the loop.
In short
MCP server development and AI agent development give AI assistants safe access to your tools and product: scoped permissions, an audit log and a person confirming anything irreversible.
It suits operations teams with multi-step work and SaaS products whose customers want to use them from an assistant.
Key facts
- Engagement
- fixed-scope project
- Price
- Fixed-scope quote after a scoping call
- Timeline
- Agreed per project after a scoping call
- First step
- Map the workWhich tasks, which tools, which data, and which actions need a person's approval.
- Works with
- Model Context Protocol
- Anthropic API
- OpenAI API
- TypeScript
- Python
- PostgreSQL
- OAuth 2.0
- Based in
- Mumbai, India · UTC+5:30I plan my working day around my clients' hours. The overlap with your timezone is shown on the contact page.
What it is
What is an MCP server?
An MCP server is a program that exposes your product's tools and data to AI assistants through the Model Context Protocol, an open-source standard for connecting AI applications to external systems. An assistant that supports MCP can then call those tools, within the permissions your customers control.
Three controls make one safe to run: scoped permissions, so each tool and credential reaches only what its job needs; human confirmation for sending, paying, deleting and changing permissions; and an audit log of every tool call with its inputs and result.
Last verified: 2 November 2026, against the Model Context Protocol introduction.
Who it is for
Who it is for, and who it is not
Who this is for
- Operations, support and finance teams with repetitive multi-step work across several tools
- SaaS companies whose customers ask how to use the product from ChatGPT, Claude or Copilot
- Teams that tried an agent framework and couldn't make it safe enough to deploy
Who this is not for
- Fully autonomous agents with unrestricted access to production systems
- Workflows with no clear definition of a correct result
What you get
What you get
- An agent or MCP server with the tools it needs, and nothing more
- Scoped credentials, permission checks and human confirmation for risky actions
- An audit log of every tool call and its inputs
- An evaluation set of realistic tasks, including attempts to misuse the agent
- Documentation for your team, and for your customers if the server is public
AI agent development and MCP server development
AI agent development and MCP server development cover two kinds of work. Internal agents read and act across your databases, APIs, chat and CRM, with scoped permissions, an audit trail and a person confirming anything irreversible. And Model Context Protocol (MCP) servers make your SaaS usable from your customers' AI assistants, within permissions your customers control. It is for operations, support and finance teams with repetitive multi-step work, and for SaaS companies whose customers ask how to use the product from an assistant.
Scope
One agent or one MCP server, with a defined set of tasks. Mapping the work comes first: which tasks, which tools, which data, and which actions need a person's approval. Each tool is then designed narrowly, with the least access that does the job and a description precise enough that the model uses it correctly.
Permissions, audit logs and human confirmation
The build includes the agent or server, scoped credentials, permission checks in code rather than in the prompt, human confirmation for risky actions, and an audit log of every tool call with its inputs and result. For a public MCP server, authorization follows the protocol's own specification, so your customers grant access through OAuth and can revoke it.
Testing uses an evaluation set of realistic tasks plus deliberate misuse: instructions hidden in a document or email the agent reads, requests to act outside the user's permissions, and chains of harmless steps that add up to a harmful one. OWASP lists excessive agency, an agent with too much functionality, permission or autonomy, among the main risks for LLM applications; the design answers it with narrow tools, scoped credentials and confirmation.
How instructions hidden in a document or an email steer an agent, and the defences that limit the damage, are set out in prompt injection in RAG and agent systems.
What it is not
It is not a fully autonomous agent with unrestricted access to production, and it is not suited to workflows with no clear definition of a correct result. If the workflow is simple and predictable, a plain automation without a model is cheaper and more reliable, and I'll say so.
How it works
How the engagement runs
- Step 01
Map the work
Which tasks, which tools, which data, and which actions need a person's approval.
- Step 02
Design the tools
Narrow, well-described tools with the least access that does the job.
- Step 03
Build and test
The agent or MCP server, tested against realistic tasks and deliberate attempts to misuse it.
- Step 04
Roll out
To a small group first, with logs reviewed, then wider.
Technologies I use for this
- Model Context Protocol
- Anthropic API
- OpenAI API
- TypeScript
- Python
- PostgreSQL
- OAuth 2.0
How this works in your market
How this works in South Korea
For teams in South Korea building for the US or Europe, an MCP server is often the fastest way to make a product reachable from the assistants customers there already use. The work runs in short cycles with a demo at the end of each, and the evaluation set is built from the start so quality doesn't drift after launch. Personal data handled by the agent follows PIPA's consent and transfer rules; confirm with your counsel.
How this works in the European Union
For teams in the European Union, the audit log and the permission model are also the records a GDPR review asks for: who could access which personal data, through which tool, and when. Where data must stay in the EU, the agent and, if needed, the model run inside your EU infrastructure. Which obligations apply is for your counsel to confirm.
Proof
Case studies behind this service
- Case study: Zyrobe · AI wardrobe app
- average time per image, upload to result
- 3–8 s
FAQs
Questions about AI agents and MCP servers
What is MCP?
The Model Context Protocol is an open standard for connecting AI assistants to tools and data. An MCP server describes what your system can do; assistants that support MCP can then use it, within the permissions you set.
Is our data safe with an agent?
Agents get only the tools and data a job needs, through credentials scoped to that job. Sensitive actions need a person to confirm, and every call is logged. Where data can't leave your infrastructure, the model can run inside it.
Can agents take actions, or only answer questions?
Both. Reading is low-risk. Writing, sending and deleting go through explicit confirmation, or run automatically only in narrow, well-tested cases.
How do you test an agent?
With a set of realistic tasks and expected outcomes, plus deliberate attempts to misuse it, run on every change. The audit log from testing shows exactly which tools it called and why.
Which assistants can use an MCP server?
Any client that supports the protocol. Support has spread across major assistants and developer tools, so I test against the clients your customers actually use.
What stops an agent being tricked by a document it reads?
Not the prompt alone. Its tools are narrow, its credentials can't reach beyond the user's own permissions, risky actions need confirmation, and outputs are checked before they're acted on.
How do I make an MCP server safe?
Decide the permissions before the tools. Each tool is narrow, credentials are scoped to the user's own permissions, and for a public server authorization follows the protocol's specification, so customers grant access through OAuth and can revoke it. Risky actions need confirmation, every call is logged, and testing includes deliberate misuse such as instructions hidden in a document the agent reads.
What can an internal AI agent be allowed to do?
As much as the job needs and no more. Reading across your databases, APIs, chat and CRM is low-risk; writing, sending and deleting need a person's confirmation, or run automatically only in narrow, well-tested cases. I don't build fully autonomous agents with unrestricted access to production systems.
Sources
Related writing
- Article: Prompt injection in RAG and agent systems: direct, indirect, and the tests that catch it · 2 November 2026
What prompt injection is, why retrieval systems and agents are most exposed to the indirect kind, which defences actually reduce the risk, and how to test for it on every change.
- Article: A glossary for buyers of engineering work: AI, performance, security and data protection · 2 November 2026
Fifteen terms that come up when you hire for AI features, performance work, security audits or cross-border projects, each defined in two sentences, with why it matters.
Where this work happens
- Working with teams in South Korea · Seoul
A software engineer for Korean teams, working remotely from Mumbai with my morning in your afternoon. It is for startups and scale-ups going global that need AI and product engineering at speed, built to meet US and European privacy expectations from the first release.
- Working with teams in European Union · Berlin · Amsterdam · Dublin
A freelance software engineer for European teams, working remotely from Mumbai with most of your working day in common. It is for product teams in Germany, the Netherlands, Ireland and the Nordics that need senior engineering, including the work behind GDPR, the Accessibility Act and the AI Act.