Model Context Protocol

MCP server development

The layer that lets an AI agent use your systems in a controlled way: a few clear tools, permissions by role, validated inputs and every call logged.

An AI agent becomes useful when it can read the right data and take the right actions in the company's systems. The Model Context Protocol (MCP) is the open standard that defines how an agent discovers and uses tools and resources. shardana.ai develops custom MCP servers that expose to compatible clients only what should be exposed, with permissions, validation and logs.

The MCP server is often the least visible part of an AI project, but it is the one that decides how reliable and safe the agent can be.

What is an MCP server?

An MCP server is a software component that exposes tools and resources to an AI agent according to the Model Context Protocol. Tools are actions the agent can request, such as searching for an order or creating a ticket. Resources are content it can read, such as documents or customer records. The protocol describes in a uniform way what exists, which parameters are needed and what is returned, so the same server can be used by different clients without repeated integrations. The server stays under your control: it decides which tools to publish, who can call them and how to record usage. In practice it is the boundary layer between the language model and the real systems, and for this reason its design matters as much as the agent's. A well-built server is small, documented, testable and designed to stop the agent when needed.

When do you need an MCP server and when is an API enough?

You need an MCP server when an AI agent must work with real systems and you want a single place to define permissions, validation and logs, reusable by several agents and clients. If you have a single assistant and a single integration, a direct call to the system's APIs may be enough and costs less. MCP pays off when the tools are many, when agents may change over time or when you want the person who governs the system, not the person who writes the prompt, to decide what the agent can do. Compared with a plugin tied to a single product, an MCP server does not lock you in to a vendor. Compared with a raw API, it adds descriptions readable by the model and a deliberately narrow surface. The table summarizes the differences, and in the first discussion we check which path makes sense for your case.

CriterionDirect APIProduct pluginMCP server
Who uses itYour codeA single assistant or productAny MCP-compatible client
Description for the modelTo be written in the promptDefined by the vendorIncluded in the server, for each tool
Permissions and logsTo be built case by caseDepend on the vendorCentralized in the server
Reuse with several agentsLowNoneHigh
When it fitsOne integration, one agentProduct already adoptedSeveral tools, several agents, governance

How does an MCP server work between agent and company systems?

The MCP server sits between the agent and the company systems and translates the model's requests into controlled operations. When the agent connects, the server presents it with the list of available tools, with name, description and parameters. If the agent decides to use one, it sends the request to the server, which verifies identity and permissions, checks that the parameters respect the schema, runs the operation on the target system and returns the result. Every step can be logged. The agent does not know credentials, internal addresses or database structures: it only sees what the server decides to expose. For this reason it is better to design small tools with a precise task, instead of a single tool that does everything. If a tool is wrong or too broad, it is fixed in the server without touching the agent, and the diagram shows where this layer sits.

AI agentMCP serverpermissions · validation · logsCRMERPDocuments
The MCP server sits between the agent and company systems: the agent only sees the tools exposed.

What does an MCP tool look like, in practice?

An MCP tool is a function with a name, a description and an input schema, which the server runs after checking permissions. The example shows a TypeScript server with a single read-only tool that returns the status of an order. The parameter is validated before touching the management system: an order number in the wrong format never reaches the system. The tool checks the user's scope, queries the management system and writes an audit record with the tool called, the parameter and the client. If permissions are missing it answers with a clear error instead of trying. It is illustrative code, not a client's project, but it reflects how we set up every tool: narrow inputs, minimal actions, predictable outcome and a trace of what happened. Write actions follow the same pattern and, when needed, add a human approval step.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const server = new McpServer({ name: "order-management", version: "1.0.0" });

// Illustrative example: a single read-only tool with validated input.
server.tool(
  "order_status",
  "Returns the status and expected delivery date of an order",
  { orderNumber: z.string().regex(/^ORD-\d{6}$/) },
  async ({ orderNumber }, { authInfo }) => {
    if (!authInfo?.scopes.includes("orders:read")) {
      return { isError: true, content: [{ type: "text", text: "Permission denied" }] };
    }
    const order = await erp.findOrder(orderNumber);
    audit.log({ tool: "order_status", orderNumber, user: authInfo.clientId });
    return { content: [{ type: "text", text: JSON.stringify(order) }] };
  },
);

Illustrative example of an MCP server with a read-only tool, permissions and audit.

How do we make an MCP server secure?

The security of an MCP server is built on a few principles applied rigorously. The first is least privilege: each tool receives only the permissions it needs, and read tools are kept separate from write tools. The second is validation: every parameter is checked for type, format and range before reaching a system. The third is identity: calls are tied to a user or a client, with credentials managed by the server and never exposed to the model. Then come rate limits, tracking of every request and the thresholds beyond which an action requires a person's approval, for example payments, deletions or messages sent to customers. It should also be considered that the content the agent reads may contain hostile instructions: for this reason data and actions stay separate and sensitive actions never depend on the received text alone. No measure is enough on its own, so we apply them together.

How much does an MCP server cost and how long does it take?

Cost and duration depend on how many systems you want to connect and which actions the agent must be able to take. A server with a few read-only tools on an already documented API requires far less work than one that writes to a management system with no API, with approvals and privacy requirements. The quality of the systems' documentation, the authentication model and the number of clients to support also weigh. After development, modest recurring costs remain, such as hosting, monitoring and updating the tools when the connected systems change. For this reason we do not publish a single price list: after the first discussion you receive a written proposal with phases, deliverables and costs. Starting from a first server with two or three tools is often the quickest way to measure the value before extending the scope. The durations in the table are indicative and are confirmed after the analysis.

PhaseWhat happensIndicative duration
First discussionSystems, data and actions the agent must be able to useOne meeting
Analysis and scopeList of tools, permissions, risks, success criteriaAbout one week
First serverTwo or three tools on a real case, with tests and logs1-3 weeks
Extension and integrationMore tools, authentication, approvals, documentation2-4 weeks
Release and maintenanceProduction, monitoring, tool updatesOngoing

With what experience do we develop MCP servers?

The founder, Maurizio Brioschi, has more than 25 years of experience in software engineering, backend development and systems architecture. In MCP server work this foundation matters, because a server is above all a well-designed API: clear contracts, authentication, error handling, testing and observability. The reference stack includes PHP, Laravel, MySQL, Node.js and TypeScript, with API-based integrations. On the AI side the studio works on language models, RAG, agentic workflows and MCP servers. We do not publish client cases we cannot document: in the first discussion we go into the technical choices for your systems, starting from the available APIs, from the points where tighter permissions are needed and from the actions that are better left to a person's approval, and when a project has the client's consent we will tell it with verifiable timelines, stack and metrics.

Frequently asked questions

What is an MCP server?
It is a component that exposes tools and resources to AI clients or agents compatible with the Model Context Protocol, allowing them to read context or carry out controlled actions.
When is it worth developing an MCP server?
When an AI agent must work with real systems, APIs, data or company procedures and you need an orderly layer of permissions, logs and maintenance, reusable by several agents.
Does an MCP server only work with a specific model?
No. MCP is an open protocol: the same server can be used by any compatible client, regardless of the language model behind it.
Can the agent modify the data in my systems?
Only if the server exposes write tools. Actions are limited by role and, when they touch sensitive data, can require a person's approval.
Is it also useful for non-technical companies?
Yes, if the company uses software and data that must be connected to an AI assistant. The complexity stays in the server, while the experience for the people using it can remain simple.
How much does an MCP server cost?
It depends on the systems to connect, the actions allowed and the security requirements. After the first discussion you receive a written proposal with phases, deliverables and costs.

Related services

Tell us about the systems to connect

Describe the tools you use, the data the agent should access and the actions it might take. We will reply with a first assessment and, if it makes sense, with a proposal for a first server on a concrete case.