MCP Server Deployment Runbook Template for ERP Integrations
An MCP server is a small service with large reach, so it deserves the same runbook as any integration that can touch the ERP. This template covers where it runs, how it authenticates, how you know it is healthy and how you back it out.
Fill in
MCP Server Deployment Runbook Template
MCP Server Deployment Runbook
Service: erp-purchasing-mcp Version: 1.2.0 Owner: Integration team Deployment date: 2026-10-28
Environment
Host and runtime: Linux VM app-int-02, Node.js 20 under systemd Transport: Streamable HTTP ERP endpoint: https://erp-test.example.local/api/v2 Secrets: Company secrets manager, path /mcp/purchasing
Pre-deployment checks
| Step | Owner | Done | Notes |
|---|---|---|---|
| Tool register reviewed and approved | |||
| Service account created with least privilege | |||
| Evaluation question set run, results attached | |||
| Network rule allows only agent host to ERP endpoint | |||
| Authentication on the MCP endpoint enabled | |||
| Logging to central store confirmed |
Health and monitoring
Health check: GET /health returns 200 and ERP ping under 2 seconds
Alert on: error rate, latency, unusual call volume, repeated authorization failures and any write tool invoked outside approval.
Rollback
Trigger: Error rate above 5 percent for 10 minutes or any unapproved write detected.
Steps: disable write tools, redeploy previous version, rotate the service account secret if misuse is suspected, notify the data owner.
Sign-off
A starting point to adapt to your platform and change process. Verify transport and authentication options against the MCP specification version your clients use.
Harden my MCP deployment
Optionally request a short review of your hosting, secrets and rollback plan.
Optional. The tool and every export work without this. No spam.
How to use the runbook
Fill in the service, release, host and ERP endpoint, then decide the transport. A local stdio server suits a single developer machine. A shared server for a team normally uses an HTTP transport behind authentication. Complete the pre-deployment table, attach the tool register and evaluation results, and collect sign-off. Export to PDF or Word and store it with the change ticket. Create one runbook per environment.
Network and secrets
Treat the MCP endpoint like any internal API. Require authentication, restrict network access to known client hosts and keep the ERP credential in a secrets manager rather than in configuration files or the client's settings. Rotate the credential on a schedule and whenever a team member with access leaves. If the server runs on premises or air-gapped, document how the model is reached and confirm that no data leaves the boundary.
- No secrets in repositories or client config files
- Authenticate every client, even on the internal network
- Allow-list the server's outbound access to the ERP only
Health, monitoring and rollback
A health check should confirm the server and a cheap round trip to the ERP. Beyond uptime, monitor what is specific to agents: spikes in call volume, repeated authorization failures, long-running queries and any write tool invoked outside the approval path. Define the rollback trigger before go-live and make the first rollback step disabling write tools, since that removes the most risk fastest.
Common mistakes
Teams often deploy the same server and credentials from test to production, run the server as an administrator, or leave the endpoint open because it is only inside the VPN. Another is failing to version tool definitions, so a changed description silently changes agent behavior. Treat tool descriptions as code and release them with version numbers.
Frequently Asked Questions
Should an MCP server run locally or centrally?
Local stdio servers suit individual developer use. For shared ERP access, run one central server with authentication, central logging and controlled credentials so access can be revoked in one place.
How do I authenticate clients to the server?
Use the authentication method supported by your MCP clients and your identity provider, commonly OAuth based flows for HTTP servers. Verify the details against the MCP specification version in use rather than relying on shared static tokens.
What should trigger a rollback?
Define it in advance: a sustained error rate, an unapproved write, unexpected data exposure or evaluation failures after a change. Disabling write tools is a fast first step.
Do tool description changes need a release?
Yes. Descriptions steer the model, so a wording change can change which tool gets called. Version them, run the evaluation set and release them like code.
Netray deploys private agent and MCP layers on premises and in sovereign cloud with human approval on writes. If you want help hardening your own deployment, talk to us.
Related Tools
MCP Tool Catalog and Risk Worksheet
Register each MCP tool your agent exposes, the ERP object it touches and a computed risk score, then export to Excel.
Developer ToolsAI Agent ERP Access Request Form Template
A fill-in form that records which ERP roles, objects and limits an AI agent service account needs, with approval signatures.
Compliance & ContractsAI Agent Incident Response Runbook Template
A fill-in incident report for AI agent mistakes in the ERP: timeline, containment, root cause, data affected and corrective actions.
Developer ToolsMCP Tool Schema Token Cost Calculator
Estimate the tokens and monthly cost of tool definitions sent on each request, and how caching or fewer tools changes it.
More Developer Tools tools
See all- SAP Sales Order ABAP SELECT Generator (VBAK, VBAP, VBFA)
- SAP Sales Order Create BAPI ABAP Generator (BAPI_SALESORDER_CREATEFROMDAT2)
- SAP ABAP Open Items SELECT Generator
- SAP ACDOCA SQL Query Generator
- SAP QM Inspection Lot ABAP SELECT Generator
- SAP Quality Notification Pareto SQL Query Generator
- SAP QM Usage Decision BAPI Skeleton
- ABAP Custom Exception Class Generator
- ABAP Unit Test Class Generator