MCP server integration: the server that stands between an agent and your systems

OutsourcingVN is operated by Netbase JSC, which builds and integrates agent and MCP-based systems, so this guide comes from a supplier with an interest in your project. It assumes you have already decided which tools an agent may call and when a person must confirm an action — the AI agent tool permissions guide covers that decision — and now need to build the server that exposes those tools. Where the server's evaluation, red-teaming and release gates need to run as a standing discipline rather than a one-off build, the quality, security and AI assurance service builds and runs them.

Contents

• Why wrap a system in a server instead of calling it directly?
• Where does an MCP server sit between agents and your systems?
• What should a server expose, and what should it keep hidden?
• How do you define the contract: authentication, scopes and versioning?
• What should run on every call: logging and testing?
• A worked scenario: exposing an order system to a support agent
• What has Netbase delivered with agent-connected integrations?
• Which questions should you ask an MCP integration supplier?
• What failure modes should you watch for?
• How this guide is sourced
• Common questions
• Bring the system you want an agent to reach

Why wrap a system in a server instead of calling it directly?

An agent can reach a business system three ways: direct API calls written into the agent itself, a shared library of custom tool-calling code, or a server that exposes a fixed, versioned set of tools and resources over MCP. Direct API calls mean the agent calls the system's own API and decides for itself what to call; custom code wraps that call in a shared library but still runs inside the agent. Both couple every agent to the system's interface and repeat the same authentication and validation logic everywhere — tight coupling a server removes by doing that work once, behind one contract, for any compliant agent to reuse. None of this decides whether the job needs an autonomous agent at all — the AI agent or workflow automation guide covers that question — or whether connecting agents here is worth a bounded experiment first, which the emerging technology adoption guide frames.

Where does an MCP server sit between agents and your systems?

Four approaches sit on a line from tight coupling to governed reuse.

On the left, an agent's own code decides everything: direct API calls reach the business system with no server between them, and custom tool-calling code is still just the agent's code, calling its own API. On the right, a local MCP server adds your own layer between agent and system, reachable through its API, built around the contract described below; that stays yours if it is self-hosted, and adding a new tool means you add a tool to the server, not to every agent that calls it. On a hosted server, you or a partner hold the server code and run it; the data behind it stays yours regardless of who hosts the process. Netbase security practices include secure code review and version control, role-based access control, MFA for admin dashboards, contributors under NDA, and NDAs and DPAs on request, which apply to a server Netbase builds the same way they apply to any other backend. What a buyer gains moving right is governance: one audited contract instead of logic repeated and drifting across every agent.

What should a server expose, and what should it keep hidden?

MCP distinguishes tools, which an agent invokes to take an action or fetch a computed result, from resources, which a server exposes for a client to read, such as a document, a schema or a reference list. The specification expects applications to make clear which tools are exposed and to confirm a sensitive operation before it runs; the AI agent tool permissions guide covers deciding which operations count as sensitive. A server should expose the narrowest tool that does the job — "look up an order by number", not "run this query" — and keep anything the agent does not need, such as administrative endpoints or another tool's credentials, out of its surface entirely rather than gated only by a prompt instruction.

How do you define the contract: authentication, scopes and versioning?

A tool's definition is a contract: its name, a description, and an input and output schema a client can validate against on every call. MCP's authorization specification builds this on OAuth 2.1 for HTTP transports: the server acts as an OAuth resource server, a client requests a token scoped to that one server, and the server must accept only tokens issued for itself rather than forwarding a token it received on to another API. Scopes should match the tool list, not a blanket grant — a tool that reads order status needs a narrower scope than one that creates a return. Version the contract the way any API is versioned: a breaking schema change is a new version or a new tool name, not a silent edit that breaks every agent already calling the old shape. A local, STDIO-based server instead reads its credentials from the environment it runs in, so deciding which credentials that environment can see is itself part of the contract.

A worked scenario: exposing an order system to a support agent

A retailer wants a support agent to look up orders and start a return through an order management system that currently has no API, only an internal admin screen. The scenario is illustrative and describes no client.

The team builds a small MCP server in front of the order system with two tools: get_order_status, scoped to read-only access on the caller's own token, and create_return_request, scoped separately and requiring the agent to show the order number, reason and amount first. The server validates both inputs against a schema, logs every call with the caller's identity, and rejects any call whose token lacks the matching scope. When the order system's API later changes its field names, the contract is versioned: the old tool keeps working against a compatibility shim while agents migrate on their own schedule, rather than every caller breaking the same day.

What has Netbase delivered with agent-connected integrations?

For a client (not named), Netbase built a WhatsApp Business AI chatbot with intent and conversation-flow handling, an LLM API (GPT-4 in the stack) and CRM synchronisation for lead capture, customer data and workflow automation. That CRM synchronisation is the closest published example of what an MCP server formalises: a model-driven assistant reaching into a business system to read and write real records. Netbase has delivered anonymised client AI projects including retrieval-based knowledge assistants, document AI and MLOps pipelines, and works with commercial and open-source AI models chosen per project (model-agnostic); no vendor partnership is implied. Netbase applies the ISO/IEC 42001 AI management system framework to its own AI delivery practice. Delivery runs remote-first from Hanoi in Agile increments with weekly reviews, using AI-assisted engineering under human review, whether the milestone is a chatbot or a server exposing tools to an agent.

Which questions should you ask an MCP integration supplier?

What failure modes should you watch for?

• One token for every tool. Signal: a single credential can call anything the server exposes. Fix: scope tokens to the tool, not the server.
• A schema change ships without a version. Signal: every calling agent breaks the same day. Fix: version the contract and keep the old shape working during migration.
• Tool descriptions trusted at face value. Signal: a server's own claim that a tool is read-only is never checked. Fix: treat every description as untrusted until reviewed.
• No logging on the server itself. Signal: a disputed action traces to the agent's chat log but not to the call the server made. Fix: log the call, the caller and the scope on the server.
• A local server inherits its host's full access. Signal: credentials in the environment reach further than any tool needs. Fix: scope the environment the server runs in, not only the tokens it issues.

How this guide is sourced

The contract and security requirements come from the Model Context Protocol specification's tools, resources and authorization pages, each dated under Sources, and OWASP's supply-chain entry, which applies to a connected third-party server the same way it applies to any other external component. No specific agent application, host or client product is named or endorsed. Statements about Netbase come from attested company facts listed under Sources. The order-system scenario is illustrative. The related published record is the WhatsApp chatbot's CRM synchronisation; MCP server work is offered as a scoped engagement.

Bring the system you want an agent to reach

A first conversation goes furthest with the system you want an agent to reach, the tools it would need, and who should hold the credentials. Submit a project with that scope, or start with an AI Workflow Blueprint if the tool list is not yet decided. OutsourcingVN is Netbase's own outsourcing-services platform.

Related services and solutions