MCP Server Launch Checklist (Governed Tools Edition)

Goal: ship an MCP server that exposes useful tools to assistants while staying safe under retries, hallucinations, and security review.

1) Scope the first release
- Pick one system of record (Jira, ServiceNow, Salesforce, Confluence/SharePoint/Notion) and one job-to-be-done.
- Start read-only unless the business case absolutely requires writes.
- Write down the exact objects/fields you will allow (example: “Jira issues in project ENG, summary/description/status only”).

2) Identity and access
- Use least-privilege scopes for every connector.
- Decide: per-user OAuth vs service account. Prefer per-user for accountability when feasible.
- Add tenant isolation from day one (separate credentials, separate storage namespaces, separate logs).
- Plan for enterprise basics: OIDC/SAML SSO, SCIM provisioning, token rotation.

3) Tool design (contract)
- Separate read tools from write tools.
- Make writes idempotent (accept Idempotency-Key and guarantee safe retries).
- Validate every input field server-side; never rely on the model to “do the right thing.”
- Return stable identifiers and source references (document IDs, ticket keys, record URLs).

4) Safety guardrails for writes
- Implement a two-step flow for high-impact actions: prepare -> commit.
- Add allowlists (projects, domains, customer segments) and explicit deny rules.
- Add impact caps (rate limits, maximum batch sizes, restricted fields).
- Require confirmations for irreversible actions (refunds, emails, deletes).

5) Logging and audit
- Log every tool call with: user identity, timestamp, tool name, parameters (redacted), and result IDs.
- Add correlation IDs for tracing across systems.
- Provide an exportable audit trail suitable for security/compliance review.

6) Threat model the inputs
- Assume prompt injection is normal if you ingest emails, web pages, tickets, or docs.
- Treat untrusted text as data, not instructions. Enforce policies in code.
- Sanitize and redact secrets/PII where possible before returning results.

7) Reliability and operability
- Add timeouts, retries (careful with writes), and circuit breakers.
- Implement structured errors that clients can handle.
- Add basic monitoring: error rates, latency, connector health.

8) Rollout plan
- Pilot with a small group and narrow permissions.
- Ship a “break glass” kill switch to disable write tools instantly.
- Document exactly what the server can and cannot do.

Launch gate: if you can’t explain the permission model and produce an audit log for a single tool call, you’re not ready to ship writes.