MCP server development for an enterprise system means building a small, governed service that lets AI agents use a CRM, ticketing tool or ERP through a short list of named tools.
Most of the work is not protocol code. It is three decisions made before coding: which business tasks become tools, whose identity each call runs under, and which calls need a person to approve them.
This guide is for engineering and operations leaders asked to "make our system available to agents." It gives a five-step method, an illustrative worksheet, an effort estimate and a launch checklist.
What an MCP Server Is, and What It Is Not
MCP, the Model Context Protocol, is an open specification for how AI applications discover and call tools on a server. An MCP server sits in front of your existing API. It does not replace that API, its access rules or its audit log.
It also does not make a model more accurate. It is one more integration surface that needs an owner, a version history and a security review, like any other privileged integration.
• Good fit: several agents or AI clients need the same governed access to one system
• Weak fit: one agent needs one call, where a direct API integration is simpler
• Check first: whether the system vendor already maintains an official server you can review
Step 1: List Tasks, Not Endpoints
Generating one tool per REST endpoint is a common mistake. Microsoft's MCP security guidance warns that large, endpoint-shaped tool lists overwhelm models and recommends task-shaped tools instead.
Start from the jobs an agent must finish, such as "find this customer's open tickets." Give each job one tool with:
• A plain, specific name and a description that says when not to use it
• A strict input schema with declared fields only, formats and ranges
• A predictable output and clear errors the agent can act on
If a task needs more than one sentence to describe, it is probably two tools.
Step 2: Classify Every Tool by Its Effect
Label each tool as read, draft, write or irreversible. Draft tools create something a person sends. Write tools change a record. Irreversible tools move money, delete data or send external messages.
Set an approval rule per class and enforce it on the server, not in the prompt. The MCP specification says clients should treat tool annotations, such as a read-only hint, as untrusted unless the server is trusted.
| Effect class | Example | Default approval rule |
|---|---|---|
| Read | search_customer_tickets | None; results scoped to the acting user |
| Draft | draft_customer_reply | A person reviews and sends |
| Write | set_ticket_priority | Allowed within limits; above limits needs a supervisor |
| Irreversible | issue_service_credit | Excluded from version 1, or named approver per call |
Step 3: Decide Identity and Token Handling
For remote servers over HTTP, the MCP authorization specification is based on OAuth 2.1. Clients identify the target server with a resource indicator (RFC 8707), and servers must validate that each token was issued for them.
Servers must not pass client tokens through to downstream APIs. In practice, the MCP server holds its own scoped credential for the backend and maps the acting user to backend permissions.
• Decide: does each call run as the end user, as a service identity, or both?
• Decide: where backend credentials live and how often they rotate
• Decide: which identity provider issues tokens to MCP clients
Step 4: Plan Logging and Change Control
Record each call's tool name and version, caller, argument hash, result and approval ID. Do not log tokens or sensitive inputs. AWS's MCP deployment guidance makes the same point.
Version tool definitions too. OWASP recommends pinning reviewed definitions and re-reviewing them when a description, schema or annotation changes, because a small metadata edit can change how a client behaves. Our guide to AI agent audit trails covers what to keep.
Step 5: Test the Refusals, Not Just the Happy Path
Test what should fail: a user without rights, a missing approval, an oversized argument, a reused token and a prompt that asks the agent to call a tool it should not.
The prompt injection and tool-action guide and our AI agent access controls article list cases worth adding to the test plan.
Worked Example: A Ticketing Server for a Support Agent
Illustrative example: a hypothetical scoping exercise, not a customer project or result. A support team wants a voice or chat agent to work with its ticketing system.
| Tool | Class | Approval rule | In version 1? |
|---|---|---|---|
| search_customer_tickets | Read | None; limited to the verified caller | Yes |
| get_ticket_summary | Read | None | Yes |
| draft_customer_reply | Draft | Agent saves a draft; a person sends | Yes |
| set_ticket_priority | Write | Up to "high"; "urgent" needs a supervisor | Yes |
| issue_service_credit | Irreversible | Excluded | No |
Result: five candidate tasks, four tools in version 1, and only one that changes a record. Credits wait until first-month logs show the other tools behave as expected.
Estimating the Effort
Illustrative example: the planning arithmetic below uses assumed figures, not LuMay quotes or measured project data. Replace each number with your own estimate.
| Work item | Assumed effort | Notes |
|---|---|---|
| Task discovery and worksheet | 3 days | Workshops with system owner and security |
| Tool build, 4 tools at 1.5 days | 6 days | Schemas, error handling, unit tests |
| OAuth and backend credential setup | 3 days | Depends on identity provider readiness |
| Logging, tracing and approvals | 3 days | Reuse existing log pipeline if possible |
| Refusal and integration tests | 3 days | Includes security review fixes |
| Total | 18 engineer-days | Add contingency for legacy APIs |
The largest swing factor is usually the backend API, not MCP. A system without a usable API may need middleware first, as covered in our legacy system integration requirements guide.
Pre-Launch Checklist
• Each tool maps to one named business task and has an owner
• Input schemas reject undeclared fields
• Each tool has an effect class, enforced server-side
• Tokens are audience-checked; none are passed through
• Downstream credentials are scoped to the tools that need them and rotated
• Approvals are tied to the exact arguments a person saw
• Logs exclude secrets; trace IDs connect the agent, server and backend
• Tool definitions are versioned and re-reviewed on change
• Refusal tests pass for every write and irreversible tool
• One tool can be disabled without a redeploy
Limitations
MCP is still evolving. The specification is versioned by date, and client support for newer features varies, so confirm what each client has implemented before relying on it.
Authorization is optional in the specification, so review every server you install, not only the ones you build. An MCP server also cannot fix weak permissions in the backend system; it inherits them.
Our own product (disclosure: LuMay sells this). The LuMay platform's connector layer lists MCP servers as a connector category, alongside CRM, ticketing, email and document connectors, with tool calls traced through OpenTelemetry. This is not a ranking or a recommendation over other options.
Next Step
If you are scoping a server for a specific system, bring your list of agent tasks to LuMay's AI integration services team. We build agent integrations with scoped permissions, audit trails and human approval steps.
Sources
• Model Context Protocol specification: Authorization
• Model Context Protocol specification: Tools
• IETF RFC 8707: Resource Indicators for OAuth 2.0
• OWASP MCP Security Cheat Sheet
