Build a data-only MCP app for private knowledge

Real workflow example

A company wants ChatGPT to answer questions about internal policies, customer implementation notes, and project history. The risky version exposes a broad searchDatabase tool that accepts any query and returns full records. It is powerful, but it is also hard to audit and easy to misuse.

The safer version is a data-only MCP app with narrow tools: search policy excerpts, fetch customer context for the current authorized customer, list open implementation blockers, or retrieve a specific source by ID. Each tool validates identity, checks authorization, minimizes returned fields, and logs access.

Implementation approach

Choose one private knowledge task first. "Search everything" is too broad. A practical first tool might be searchSupportPolicies or listCustomerImplementationRisks.

Define inputs that constrain scope by user, organization, project, and query. The model should not provide trusted role or organization values. The server should derive those from session state, then apply filters before fetching data.

Return structured, minimal results. Include IDs, titles, safe excerpts, source type, updated date, and a URL or handle that lets the product open the full record through normal permissions.

Code or config snippet

type PrivateKnowledgeResult = {
  id: string;
  title: string;
  sourceType: "policy" | "project_note" | "customer_record";
  updatedAt: string;
  excerpt: string;
  sourceUrl?: string;
};

async function searchPrivateKnowledge(input: { query: string }, session: Session) {
  const membership = await requireWorkspaceMembership(session.userId);

  return db.knowledge.findMany({
    where: {
      workspaceId: membership.workspaceId,
      visibility: { in: membership.allowedVisibility },
      text: { contains: input.query },
    },
    select: {
      id: true,
      title: true,
      sourceType: true,
      updatedAt: true,
      excerpt: true,
      sourceUrl: true,
    },
    take: 5,
  });
}

Mistakes to avoid

• Do not trust organization, role, or user ID values supplied by the model.
• Do not return full private records when excerpts are enough.
• Do not skip audit logs because the tool is read-only.
• Do not expose data the user could not access in the normal product.
• Do not build one broad tool when several narrow tools would be easier to secure.

Ready checklist

• Tool scope maps to one clear knowledge task.
• Server derives user and organization from trusted session state.
• Authorization runs before database access.
• Returned fields are minimized and structured.
• Source IDs and update dates are included.
• Safe access logs are recorded without secrets or raw sensitive payloads.

Practical tip

Review tool outputs from the perspective of the least-privileged user who can call the tool. If that user should not see a field in the product UI, the MCP tool should not return it either.