Data Integration

Custom MCP Servers:
Connecting Private Data.

Give Claude controlled access to the context it needs: private databases, internal APIs, documents, tickets, files, and business workflows.

By RankMaster Tech//14 min read
Building a Custom MCP Server for Claude: Connect Your Private Data

Claude becomes much more valuable when it can work with your real business context. A normal chat can answer general questions, but it cannot inspect your private PostgreSQL database, read your internal runbooks, search support tickets, summarize customer accounts, or call your backend APIs unless you connect those systems safely. That is exactly what a custom MCP server for Claude is designed to do.

The Model Context Protocol, or MCP, is an open protocol for connecting LLM applications to external data sources and tools. Anthropic introduced MCP as an open standard for secure two-way connections between AI-powered tools and data sources, and the official MCP specification describes servers exposing resources, prompts, and tools to clients. Anthropic MCP announcement MCP specification

This Claude MCP server tutorial explains how to build a secure bridge between Claude and your proprietary data. It covers Claude Desktop, Desktop Extensions, local vs remote MCP servers, tools, resources, prompts, TypeScript SDK patterns, private database access, deployment strategy, and security controls.

What Is a Claude MCP Server?

A Claude MCP server is a connector that exposes specific context or actions to Claude through MCP. The server might run locally on a developer's laptop, inside Claude Desktop, or remotely on your infrastructure. Claude acts as the MCP client or host, while the MCP server exposes approved capabilities.

A custom server can expose:

  • Private resources: files, docs, database schemas, customer summaries, runbooks, or product knowledge.
  • Tools: search tickets, query a safe API, look up invoices, create support tasks, or summarize account data.
  • Prompts: reusable workflows such as “summarize this account,” “draft a support reply,” or “prepare a weekly product report.”

MCP's official resources documentation says resources let servers share data that provides context to language models, such as files, database schemas, or application-specific information. MCP resources documentation

Why Build a Custom MCP Server Instead of Pasting Data into Claude?

Pasting private data into a chat window does not scale. It is slow, inconsistent, hard to audit, and prone to exposing too much context. A custom MCP server gives Claude a controlled interface to the exact data and actions it needs.

A custom MCP server helps you:

  • Control what Claude can see.
  • Limit which actions Claude can request.
  • Reuse the same integration across many workflows.
  • Keep credentials outside prompts and chat messages.
  • Validate tool arguments before touching business systems.
  • Log access for compliance and debugging.
  • Package private integrations for a team through Desktop Extensions or hosted servers.

The goal is not to give Claude unlimited access. The goal is to give Claude narrow, useful, auditable access.

Claude Desktop, Desktop Extensions, and Remote MCP

Most developers start with local MCP servers connected to Claude Desktop. Anthropic's Claude Desktop support documentation explains local MCP server setup and also notes that Desktop Extensions can package MCP servers for easier installation. Sensitive configuration fields can be marked as sensitive in the manifest, and Claude Desktop encrypts those values using the operating system's secure storage. Claude Desktop local MCP documentation

Anthropic also introduced Desktop Extensions to make MCP server installation easier for Claude Desktop users. These extensions package MCP servers so users can install them with less manual setup. Anthropic Desktop Extensions announcement

For team and enterprise workflows, remote MCP servers are often more practical. Anthropic's Claude API docs describe connecting to remote MCP servers and emphasize reviewing server documentation and ensuring necessary authentication credentials are available. Claude remote MCP server documentation

Local vs Remote MCP Server: Which Should You Choose?

Deployment Type Best For Advantages Risks
Local MCP server Developer productivity, local files, local repos, personal tools. Simple setup, fast iteration, private machine-level context. Harder to centrally manage, update, log, and secure across a team.
Desktop Extension Packaging MCP servers for Claude Desktop users. Easier installation, private team distribution, sensitive config handling. Still runs locally and requires careful packaging and update strategy.
Remote MCP server Team-wide SaaS tools, databases, CRMs, support platforms, shared workflows. Centralized auth, logging, updates, and permissions. Requires stronger transport security, authentication, rate limits, and monitoring.

Understanding MCP Architecture

MCP servers can expose three core capability types: resources, prompts, and tools. The latest official specification lists resources as context and data, prompts as templated messages and workflows, and tools as functions the AI model can execute. MCP specification

For a private-data Claude integration, think about each capability like this:

  • Resources are read context: database schemas, documents, account summaries, product docs, issue metadata.
  • Tools are controlled actions: search docs, query a safe endpoint, create a task, fetch a customer record, generate a report.
  • Prompts are reusable workflows: summarize a support ticket, draft a sales brief, prepare an incident update.

A strong server exposes only the capabilities needed for the workflow. Do not expose your entire database when Claude only needs a customer summary.

Step 1: Define the Private Data Workflow

Start with the job Claude should perform. A vague goal like “connect Claude to our database” is too broad. A safer goal is “let Claude answer support agents' questions about customer account status using a read-only account summary.”

Good first workflows include:

  • Search internal documentation and return source links.
  • Summarize a customer account without exposing payment secrets.
  • Read support ticket history and draft a response.
  • Inspect a PostgreSQL schema for a developer assistant.
  • Retrieve open incidents for an operations team.
  • Generate weekly product updates from approved internal records.

Avoid starting with high-risk tools such as deleting records, issuing refunds, changing permissions, sending emails, or deploying infrastructure.

Step 2: Choose the TypeScript SDK

The official TypeScript SDK repository says the Model Context Protocol lets applications provide context for LLMs in a standardized way and separates context-providing concerns from the actual LLM interaction. The SDK implementation runs on Node.js, Bun, and Deno. MCP TypeScript SDK

TypeScript is a strong choice when your private systems already use Node.js, Next.js, Express, NestJS, Prisma, Supabase, Stripe, or internal TypeScript services. It also makes it easier to share validation schemas, API clients, and business logic between your app and MCP server.

Use TypeScript when:

  • Your SaaS backend is already JavaScript or TypeScript.
  • You want strict schemas for tool inputs and outputs.
  • You need to call existing REST APIs or SDKs.
  • You want to package the server for developer workflows.
  • Your team is more comfortable deploying Node.js services.

Step 3: Design Tools Safely

MCP tools let Claude call executable functions. Tools are powerful, so they should be narrow and predictable. The MCP tools documentation says tools are executable capabilities exposed by servers that language models can invoke to interact with external systems. MCP tools documentation

A risky tool:

run_sql(query: string)

A safer set of tools:

get_customer_summary(customerId: string)
search_support_tickets(customerId: string, status?: "open" | "closed")
list_recent_invoices(customerId: string, limit: number)
draft_support_reply(ticketId: string)

The second design gives Claude useful access without letting it execute arbitrary SQL. Your backend can validate every argument, limit result size, mask sensitive fields, and log each call.

Step 4: Expose Private Data as Resources

Resources are useful when Claude needs context but not action. Examples include a project readme, database schema summary, policy document, runbook, or product FAQ.

For private data, expose resources carefully:

  • Use stable resource URIs.
  • Return only necessary fields.
  • Mask secrets and personal data.
  • Apply user-level authorization before returning content.
  • Limit large documents or paginate content.
  • Add source metadata so Claude can cite or reference where information came from.

For example, a database schema resource might include table names, safe column descriptions, and relationships, but not raw user records.

Step 5: Add Reusable Prompts

MCP prompts let servers define reusable prompt templates and workflows. The official prompts documentation says prompts allow servers to provide structured messages and instructions for interacting with language models, and clients can discover and retrieve available prompts. MCP prompts documentation

Useful Claude MCP prompts might include:

  • Summarize customer account: pulls account data and turns it into a support-ready brief.
  • Draft support reply: uses ticket context and docs to prepare a response.
  • Prepare sales research brief: combines CRM notes and public account information.
  • Explain database schema: helps developers understand tables and relationships.
  • Incident update: creates a status update from logs, tickets, and runbooks.

Prompts help standardize workflows so every user does not have to invent the perfect instruction manually.

Step 6: Connect a PostgreSQL Database Safely

Connecting Claude to PostgreSQL can be useful, but it must be handled carefully. The safest design is a read-only database user plus narrow tool functions. Avoid arbitrary SQL execution unless you are in a trusted development environment and fully understand the risk.

Recommended database safeguards:

  • Create a dedicated read-only database role.
  • Use row-level or tenant-level access controls where needed.
  • Expose named tools instead of raw query execution.
  • Validate every input with a schema.
  • Limit rows returned per call.
  • Mask sensitive fields such as tokens, passwords, payment data, and private notes.
  • Log every query-like tool call.
  • Use staging data while developing the server.

A safe customer-support tool might return account status, plan name, open tickets, and recent activity, while excluding private billing details and authentication data.

Step 7: Connect Internal APIs

Many private-data MCP servers should call internal APIs rather than connect directly to databases. This is often safer because your existing API already enforces business rules, permissions, and validation.

Good API-backed tools include:

  • lookup_account: calls your customer API.
  • search_docs: queries your documentation search service.
  • create_support_task: creates an internal task after validation.
  • get_deployment_status: reads deployment metadata.
  • list_user_permissions: returns safe permission summaries.

This pattern keeps the MCP server thin. It becomes an AI-friendly interface over APIs you already trust.

Step 8: Configure Claude Desktop

After building a local MCP server, configure Claude Desktop to start it. The exact configuration depends on your operating system and packaging style, but the general flow is:

  1. Build or install your MCP server locally.
  2. Add the server command to Claude Desktop's MCP configuration.
  3. Store API keys or database credentials as sensitive configuration, not hardcoded source values.
  4. Restart Claude Desktop.
  5. Confirm Claude can discover the server's tools, resources, and prompts.
  6. Test safe read-only workflows before enabling write actions.

If you distribute the server to a team, consider packaging it as a Desktop Extension or hosting it as a remote MCP server with centralized authentication and logging.

Step 9: Add Logging and Audit Trails

Private-data access should always be auditable. If Claude uses a tool to fetch a customer account, your team should know who requested it, when it happened, what tool was called, what arguments were passed, and whether the action succeeded.

Log:

  • User or workspace identity.
  • Tool name.
  • Arguments after sensitive redaction.
  • Result metadata, not necessarily full sensitive output.
  • Errors and timeouts.
  • Approval events for write actions.
  • Unusual access patterns.

Logs help with debugging, compliance, incident review, and user trust.

Step 10: Secure the Server Before Production

A Claude MCP server for private data should be treated like privileged infrastructure. It can expose sensitive information if permissions are too broad or tool definitions are careless.

  • Least privilege: use dedicated credentials with only required access.
  • Read-only first: prove value before enabling write tools.
  • Tool allowlists: expose only approved actions.
  • Input validation: validate every argument before calling databases or APIs.
  • Output filtering: redact secrets, tokens, private notes, and sensitive identifiers.
  • Human approval: require review for emails, deletes, refunds, permission changes, or production writes.
  • Environment separation: keep development, staging, and production configs separate.
  • Monitoring: track errors, latency, usage volume, and denied access attempts.

MCP's power comes from giving AI tools access to real systems. That power is only useful when the access is controlled.

Common Mistakes to Avoid

Mistake 1: Exposing all private data at once

Start with one workflow and one data source. Broad access makes testing, security review, and debugging much harder.

Mistake 2: Building a raw SQL assistant

Raw SQL access is tempting but risky. Use narrow tools and read-only roles unless you are building a trusted developer-only workflow.

Mistake 3: Ignoring prompt injection inside private content

Documents, tickets, and user-generated records can contain malicious instructions. Treat retrieved content as data, not as system-level instructions.

Mistake 4: No approval layer for write actions

Claude can draft actions, but a human should approve high-risk operations such as sending customer messages, deleting records, issuing refunds, or changing permissions.

Mistake 5: No team deployment strategy

A local server is fine for one developer. A team needs versioning, documentation, permissions, updates, and audit logs.

Production Checklist

  • Correct metadata, server name, and version are documented.
  • Tools are narrow, named, and schema-validated.
  • Resources return only approved fields.
  • Prompts are reusable and workflow-specific.
  • Database access uses read-only roles where possible.
  • Secrets are stored securely, not hardcoded.
  • Logs capture tool calls and errors.
  • Human approval exists for high-risk actions.
  • Claude Desktop setup is tested on target operating systems.
  • Remote deployment has authentication and transport security.
  • Output filtering removes sensitive data.
  • Prompt-injection scenarios are tested.
  • Team installation and update process is documented.

Final Takeaway

A custom MCP server is the safest way to connect Claude to private business data when generic chat is not enough. It gives Claude structured access to exactly the context and actions your workflow requires.

The best Claude MCP servers are focused, narrow, auditable, and secure. They expose specific tools instead of entire systems, use resources for contextual data, package prompts for repeatable workflows, and protect private data with least privilege and logging.

If you are building a Claude integration for a serious business workflow, start small: one server, one data source, one read-only workflow. Then expand carefully after the security model, logs, and user experience are proven.

Build Claude MCP Servers with Gadzooks Solutions

Gadzooks Solutions builds custom MCP servers for Claude Desktop, Claude API workflows, private databases, internal SaaS platforms, CRMs, support tools, analytics systems, documentation libraries, and developer workflows.

We design tool schemas, connect APIs, secure credentials, add logging, package local MCP servers, prepare Desktop Extensions, deploy remote MCP servers, and create private-data workflows that are useful without being risky.

Frequently Asked Questions

Can Claude Desktop connect to my private database?

Yes, through a local MCP server or packaged Desktop Extension. For production use, connect through narrow tools, read-only credentials, input validation, and output filtering instead of giving Claude broad database access.

Should I build my MCP server locally or remotely?

Use local MCP servers for developer workflows and personal tools. Use remote MCP servers when multiple team members need shared access, centralized permissions, updates, and logs.

What is the best first Claude MCP project?

A read-only documentation search, customer summary, or database schema helper is a safe first project. Avoid write actions until the team has logging, permissions, and approval flows in place.

Can I distribute a private MCP server to my team?

Yes. Claude Desktop supports private distribution of Desktop Extension packages, and remote MCP servers can also be used for team-wide integrations if authentication and access control are properly designed.

Can Gadzooks build this for my business?

Yes. Gadzooks Solutions can design and build Claude MCP servers for private data, internal APIs, SaaS tools, dashboards, CRMs, support systems, and developer workflows.

Sources