MCP untuk operator SaaS: investigasi pelanggan tanpa mengirim semua data ke AI

Artikel ini menyesuaikan MCP untuk operasi SaaS dengan batas data pelanggan, tool read-only, dan review manusia.

SaaS operators do not need to expose the whole customer database to an AI agent just to investigate one support ticket. The better first step is a narrow MCP research surface: a few allowed fields, read-only tools, explicit denied tools, human review gates, and an audit log.

This article adapts Model Context Protocol to SaaS support and operations. MCP is an open protocol for connecting LLM applications with external data sources and tools. The official specification describes hosts, clients, and servers, and server features such as Resources, Prompts, and Tools. The dangerous part for SaaS is not the protocol itself; it is exposing broad customer data and write-capable tools before the investigation boundary is clear.

Primary sources: MCP Specification, MCP Security Best Practices, Anthropic’s MCP connector, and Introducing the Model Context Protocol. Related local reading: MCP server guide and SaaS Cosmos DB support history schema.

Poin utama

• MCP for SaaS should begin with a narrow customer-data boundary, not full customer access.
• Share tenant_id, ticket_id, event_type, created_at, redacted_summary, and plan_band.
• Block customer names, emails, phones, billing data, full messages, access tokens, and contract amounts.
• Start with read-only tools such as search_support_events, read_status_page, and list_recent_deploys.
• Humans keep refunds, legal language, security incidents, customer replies, production writes, and delete actions.

Di mana riset MCP SaaS rusak

A support ticket investigation often touches too many systems: the ticket tool, admin console, billing provider, email provider, status page, recent deploys, database events, and sales notes. Under pressure, it is tempting to connect all of them through MCP and ask the model to search everything.

That is where the risk starts. MCP servers can expose resources, prompts, and tools. Tools are functions the model can call. A read-only event search tool is useful. A tool named export_all_customers, update_invoice, delete_user, or send_customer_email changes the risk entirely.

The MCP security best practices call out risks such as confused deputy issues, token passthrough, SSRF, session hijacking, and scope minimization. For a SaaS operator, the plain-language question is simple: whose authority is the tool using, what customer boundary is enforced, and can the result include another tenant’s data?

Alur: dari tiket ke kandidat penyebab

The practical SaaS workflow is ticket review, redaction, event search, recent-change review, cause candidate, human review, and either customer reply or engineering handoff. MCP fits event search, status checks, deploy checks, FAQ candidate extraction, and cause-table drafting.

It should not own refunds, contract exceptions, customer replies, production writes, or deletion. Those decisions carry business responsibility. Let the model produce a table; let people decide the action.

Step	Safe MCP Input	Human Review
Ticket review	ticket_id, category, redacted_summary	name, email, full message
Event search	tenant_id, event_type, created_at	raw logs, tokens, IP details
Billing check	plan_band, invoice_status	card data, contract amount, refunds
Incident check	status page, recent deploys	incident declaration, compensation
Reply prep	reply_note, missing_info	customer-facing wording

This table changes the prompt. Instead of “research this customer,” ask “using only the redacted ticket fields and read-only events, produce cause candidates and human review points.”

Ruang Claude Code dan ruang manusia

Claude Code can draft the MCP tool design, allowlist, denylist, audit log fields, and investigation prompt. In the first pass, expose only read-only tools such as search_support_events, read_status_page, and list_recent_deploys.

Keep write-capable tools outside the model’s reach: update_invoice, delete_user, export_all_customers, send_customer_email, rotate_customer_secret. If you later need write tools, add explicit approval and a rollback path.

Humans decide refunds, contracts, billing exceptions, legal language, security incidents, public incident updates, and production writes. Claude may identify a likely cause. It does not decide what the company owes the customer.

3 use case

Use case 1: Investigate a failed invoice email

• Input: ticket_id, tenant_id, invoice_status, email_event_type, redacted_summary, created_at.
• Output: delivery-failure candidates, recent changes, missing_info, owner queue, reply notes.
• Human review: email address, contract amount, refund, resend decision, and customer reply.

Do not connect the whole email provider and billing provider on day one. Start with read-only event lookup. Let the model say what to inspect; let people decide money and messaging.

Use case 2: Compare possible incident tickets with deploy history

• Input: ticket_id, tenant_id, product_area, event_type, created_at, recent_deploys, status_page.
• Output: matching change candidates, affected area, engineering questions, incident candidate note.
• Human review: incident declaration, public wording, impact scope, compensation, important customers.

MCP is useful for lining up timestamps. It is risky when the model declares an outage alone. Use it to prepare the meeting, not replace the incident owner.

Use case 3: Extract FAQ candidates from support history

• Input: redacted_summary, category, product_area, resolution_tag, ticket_count.
• Output: FAQ candidates, gaps in help docs, wording to review, inquiry-reduction hypothesis.
• Human review: customer-specific details, contract terms, legal language, publishable scope.

FAQ work does not require full messages at first. Redacted summaries and resolution tags often reveal enough repeated patterns.

Prompt siap salin

Act as the MCP research boundary designer for a SaaS operator.
The goal is to investigate support tickets without sending all customer data to the model.

Inputs:
- ticket_id
- tenant_id
- event_type
- created_at
- redacted_summary
- proposed MCP server
- existing tool list

Return:
1. fields allowed for MCP
2. fields blocked from MCP
3. read-only tools to allowlist
4. write/export/delete/send tools to denylist
5. human review gates: refund, contract, security, incident update, customer reply, production write
6. audit log fields: who, when, tool, tenant_id, ticket_id, result_id
7. one change to make in the next 30 minutes

Constraints:
- Do not pass customer_name, email, phone, billing_card, full_message, access_token, or contract_amount
- Do not assume token passthrough is acceptable
- Do not expose write tools in the first version
- Send unclear decisions to human review

Kode pemeriksaan

const mcpResearchPlan = {
  task: "investigate failed invoice email",
  allowedFields: ["tenant_id", "ticket_id", "event_type", "created_at", "redacted_summary", "plan_band"],
  blockedFields: ["customer_name", "email", "phone", "billing_card", "full_message", "access_token", "contract_amount"],
  allowedTools: ["search_support_events", "read_status_page", "list_recent_deploys"],
  blockedTools: ["export_all_customers", "update_invoice", "delete_user", "send_customer_email"],
  humanReview: ["refund", "legal wording", "security incident", "customer reply", "production write"],
  auditLog: ["who", "when", "tool", "tenant_id", "ticket_id", "result_id"]
};

const requiredBlocked = ["email", "full_message", "access_token", "billing_card"];
const requiredAllowedTools = ["search_support_events"];
const requiredHuman = ["refund", "security incident", "production write"];
const requiredAudit = ["who", "tool", "tenant_id", "ticket_id"];

const findings = [
  ...requiredBlocked
    .filter((field) => !mcpResearchPlan.blockedFields.includes(field))
    .map((field) => ({ type: "blocked field missing", field })),
  ...requiredAllowedTools
    .filter((tool) => !mcpResearchPlan.allowedTools.includes(tool))
    .map((tool) => ({ type: "needed read-only tool missing", tool })),
  ...requiredHuman
    .filter((item) => !mcpResearchPlan.humanReview.includes(item))
    .map((item) => ({ type: "human review missing", item })),
  ...requiredAudit
    .filter((field) => !mcpResearchPlan.auditLog.includes(field))
    .map((field) => ({ type: "audit field missing", field }))
];

console.table(findings);
if (findings.length > 0) process.exitCode = 1;

Pitfall: jebakan umum

Cause: putting export_all_customers in the MCP server. Fix: start with read-only search tools and denylist export, delete, update, and send tools.

Cause: passing SaaS access tokens through the MCP server. Fix: avoid token passthrough and validate audience, scope, client, and audit records at the server boundary.

Cause: searching without tenant_id. Fix: require tenant_id in every read tool and include tenant_id and ticket_id in each result.

Cause: exposing every tool because the connector supports it. Fix: allowlist only the tools needed for this investigation.

Cause: leaving audit evidence only in the AI chat. Fix: keep who, when, tool, tenant_id, ticket_id, and result_id in your own application logs.

FAQ

Q. Do I need to connect the full customer database to use MCP? A. No. Start with read-only tools and a narrow event surface.

Q. What are resources, prompts, and tools in plain language? A. Resources are material to read, prompts are workflow templates, and tools are functions the model can call.

Q. Can I paste a real customer ticket into Claude Code? A. Use a redacted summary first. The ticket id, tenant id, event type, and category are often enough.

Q. Are allowlists and denylists enough? A. They are a good start, but SaaS-side tenant checks, RBAC, audit logs, and write limits still matter.

Jalur konsultasi

For SaaS teams, MCP design is not only a server implementation task. It combines tenant boundaries, customer-data classification, tool allowlists, audit logs, refunds, incidents, and support workflow design. Use training and consultation when you want this mapped around your real support and billing systems.

Yang saya verifikasi

I checked the MCP specification, MCP security best practices, Anthropic’s MCP connector docs, the launch post, the JavaScript boundary check, frontmatter, links, code fences, and CTA. The next concrete step is to split your MCP tool list into read-only, write, export, delete, and send columns.