How to Build an MCP Server for Your Business Data (ERP, CRM, Database)

This guide is for developers and technical leads, in India and abroad, who have been asked to let an AI assistant or agent work with company data held in an ERP, CRM or plain SQL database. As of 3 October 2026 it reflects the current Model Context Protocol specification. By the end you will know how to scope the tools, write a minimal server, secure it, and decide what to ship first.

What is an MCP server and why build one for business data

An MCP server is a program that exposes your data and actions as named tools that any MCP-compatible AI application can discover and call, so you write the integration once instead of once per model or vendor. Anthropic introduced the Model Context Protocol in November 2024 and donated it in December 2025 to the Agentic AI Foundation, a fund under the Linux Foundation.

The protocol defines three things a server can offer:

• Tools: functions the model can call, such as get_stock_level or find_customer.
• Resources: data the application can read, such as a price list or a policy document.
• Prompts: reusable templates, such as "summarise this customer's last 90 days".

For business systems, tools do most of the work. The value is control: the model never touches your database directly. It can only ask the server to run functions you wrote, with arguments you validate, under a user you authorised. The full specification lives at modelcontextprotocol.io.

What has changed in the MCP specification in 2025 and 2026

The specification has moved quickly, so check the revision your SDK targets: the July 2026 revision made the protocol stateless, and the November 2025 revision strengthened OAuth-based authorization and added experimental long-running tasks.

Revision	Changes that matter for business servers
2025-11-25	OpenID Connect discovery for authorization servers, incremental scope consent, OAuth Client ID Metadata Documents as the recommended client registration, experimental tasks for long-running work, URL-mode elicitation, guidance on tool names.
2026-07-28	Removed the initialize handshake and protocol-level sessions; every request carries its protocol version and client capabilities. Added a required server/discover method. Moved tasks into an official extension. Deprecated Dynamic Client Registration in favour of Client ID Metadata Documents. Deprecated the Roots, Sampling and Logging features.

The practical effect of the 2026 revision: an MCP server behind a load balancer no longer needs sticky sessions, which makes it easier to deploy like any other stateless API. If you need state across calls, such as a draft order, the server mints its own handle and the model passes it back as an ordinary tool argument. Use an SDK version that supports the revision your hosts use.

How to choose the first tools for an ERP, CRM or database

Start with three to six narrow, read-only tools that answer questions staff already ask every day, because narrow tools are easier for the model to choose correctly and far easier to secure than a general query tool.

A common mistake is a single run_sql tool. It looks flexible but it hands the model your whole schema, makes permission checks almost impossible and invites slow or harmful queries. Write one function per business question instead.

System	Good first tools	Leave for later
Manufacturing ERP	stock_level(item_code), open_orders(customer), job_status(work_order)	create_purchase_order, change_bom
CRM	find_customer(phone_or_name), last_interactions(customer_id, days), pipeline_summary(owner)	update_stage, bulk_email
Accounting	outstanding_balance(party), overdue_invoices(days)	post_journal, issue_credit_note
Helpdesk or orders	order_status(order_id), delivery_eta(order_id)	refund, cancel_order

Give each tool a clear name, a one-line description written for the model, typed arguments and a compact result. The model reads the description to decide when to call the tool, so "Return current stock on hand for one item code" beats "stock function".

How to build a minimal MCP server in Python

A minimal server needs an official SDK, one decorated function per tool, a read-only database connection and a run call; the example below exposes one stock lookup tool over stdio and logs to stderr, not stdout.

The official quickstart for the Python SDK requires Python 3.10 or newer and installs the package with uv add "mcp[cli]". Recent SDK releases use the MCPServer class; older tutorials show a different class name, so follow the version you install. The database here is SQLite opened in read-only mode to keep the example self-contained; for PostgreSQL or MySQL, use a database user with SELECT rights only.

import logging
import sqlite3

from mcp.server import MCPServer

logging.basicConfig(level=logging.INFO)  # logs go to stderr
logger = logging.getLogger(__name__)

mcp = MCPServer('erp-readonly')


def get_conn():
    # mode=ro opens the file read-only
    return sqlite3.connect('file:erp.db?mode=ro', uri=True)


@mcp.tool()
def stock_level(item_code: str) -> str:
    '''Return current stock on hand for one item code.'''
    conn = get_conn()
    try:
        row = conn.execute(
            'SELECT item_name, qty_on_hand, uom FROM stock WHERE item_code = ?',
            (item_code,),
        ).fetchone()
    finally:
        conn.close()
    logger.info('stock_level item_code=%s found=%s', item_code, row is not None)
    if row is None:
        return 'No item found with code ' + item_code
    return '%s: %s %s on hand' % (row[0], row[1], row[2])


if __name__ == '__main__':
    mcp.run(transport='stdio')

Three details matter. First, the query uses a parameter placeholder, never string concatenation, so a crafted item code cannot change the SQL. Second, nothing is printed to stdout: on a stdio server, stdout carries the protocol messages and a stray print breaks the connection. Third, the result is short text the model can quote, not a raw table dump.

Testing before you connect a model

Use the MCP Inspector or your SDK's test client to call each tool directly with good and bad inputs: a valid code, an unknown code, an empty string, a code with quotes in it. Then connect a desktop AI host that supports MCP, ask natural questions and watch which tools it picks. If it picks the wrong tool, fix the description before you fix anything else.

How to secure an MCP server: OAuth, permissions and audit logs

Treat a remote MCP server like any public API: authenticate every user through the OAuth 2.1 based flow in the specification, enforce permissions inside each tool, validate arguments, rate-limit calls and keep an append-only audit log.

1. Transport choice. Stdio is fine for one developer on one machine. For a team, run the server over the Streamable HTTP transport behind HTTPS.
2. Authorization. The MCP server acts as an OAuth resource server. Users sign in through your identity provider and the host presents a short-lived access token. Validate the token audience on every request and never pass the user's token through to downstream APIs.
3. Per-user permissions inside tools. The sales executive for Saurashtra should not see Pune customers just because the model asked. Filter by the user's role in the query itself.
4. Argument validation. Check types, lengths and allowed values before running anything. Reject, do not guess.
5. Audit log. Record user, tool, arguments, result size, time and outcome for every call. This is the first thing an auditor or a worried owner will ask for.
6. Rate limits and timeouts. An agent in a loop can call a tool hundreds of times a minute. Cap it.

Prompt injection is the other half of security: text inside a customer email or a product description can try to instruct the model. Our AI agent security checklist covers that side in detail.

When to add write tools such as purchase orders or CRM updates

Add write tools only after the read-only tools have run cleanly for several weeks, and start with writes that are reversible, low in value and confirmed by a human before they commit.

A good pattern is propose then commit. The tool draft_purchase_order returns a draft with an ID and a summary; nothing is saved to the live ERP. A second step, which a person approves in your app or on WhatsApp, commits the draft. The model can prepare work at speed while a person keeps the final say. Under the 2026 specification the draft ID is simply a handle your server issues and the model passes back.

Keep financial actions, price changes, stock adjustments and anything that sends a message to a customer behind approval permanently. Our guide to AI agents inside ERP lists which manufacturing actions suit automation and which do not.

What we have seen building MCP servers for Indian businesses

On JK Tech Hub projects in Rajkot and elsewhere in Gujarat, the protocol itself is rarely the hard part; most of the effort goes into cleaning item masters, agreeing tool names with staff and deciding who may see which data.

• A casting unit in Metoda GIDC wanted the owner to ask "how many pump housings are pending for dispatch this week" from his phone. The ERP held the answer, but item names were inconsistent across three years of data. Two weeks of master cleanup came before the first useful tool.
• A distributor with a field sales team asked for customer balance and last order lookups. The first version exposed all customers to all reps; the fix was a per-user territory filter inside each tool, not a prompt instruction.
• An export firm serving UK buyers needed an audit trail before its compliance team would approve anything. We log every tool call with user and arguments, and that log became the reason the project was approved.

The pattern holds: tool design and data quality decide the outcome far more than which model sits on top.

How much it costs and how long it takes to build an MCP server

A read-only MCP server over one system usually takes one to two weeks and costs ₹1.5 lakh to ₹4 lakh in India, while a multi-system server with OAuth, write tools, approvals and audit dashboards takes four to eight weeks.

Scope	Typical timeline	Typical India budget
Read-only, one system, 3 to 6 tools, stdio or internal HTTP	1 to 2 weeks	₹1.5 lakh to ₹4 lakh
Read-only, two or three systems, OAuth, per-user permissions	3 to 5 weeks	₹4 lakh to ₹8 lakh
Read and write with approval flow, audit dashboard, monitoring	5 to 8 weeks	₹6 lakh to ₹12 lakh

Model usage is billed separately by your AI provider and depends on volume. Clients in the US, UK, UAE, Australia and Europe get the same scoping and a fixed quote in their currency. For a wider view of running costs, see LLM integration cost and architecture.

How to decide what to build first

Build first where a frequent, read-only question costs staff real time every day, the data already sits in one system, and a wrong answer is easy to spot and cheap to correct.

Write down the ten questions your team asks most often about stock, orders, customers or payments. Pick the three that one system can answer. Build those as tools, put them in front of five real users for two weeks, and read the audit log. Expand only when the log shows people using the tools and getting correct answers. If you later need several agents to coordinate, read MCP vs A2A before adding a second protocol.

Related reading and next step

• AI agent development services
• MCP vs A2A: which protocol your project needs
• AI agent development cost in 2026
• LLM integration guide for enterprises

For a fixed quote on an MCP server for your ERP, CRM or database, share your systems and top questions through the contact page or on WhatsApp at +91 7265004040.