MCP for the non-engineer: connect Claude or Cursor to your tools

MCP — the Model Context Protocol — is an open protocol for connecting AI applications to context and tools. Its value is a common protocol surface, not guaranteed portability or safety; clients can support different transports and features, and every server adds code and credentials to the trust boundary. Start from the current official MCP documentation rather than vendor-history claims in an article.

You do not need to be an engineer to benefit. You need to understand what MCP is, which servers exist for your use case, and how to install and configure them. This is the non-engineer’s guide.

What MCP actually is

MCP is a standard for how AI assistants connect to tools. Before MCP, every AI tool had its own integration system — ChatGPT had Plugins, then Custom GPT actions; Claude had its own, separate way; every framework had its own approach. The result was that “I want my AI to read my Gmail” required different work depending on which AI tool you used.

MCP solves this by defining a single protocol — the open Model Context Protocol, stewarded by Anthropic and adopted across vendors. An MCP server is a small program that exposes a tool’s capabilities (read calendar events, send Slack messages, search Notion). An MCP client is any AI assistant that knows how to speak the protocol — Claude, ChatGPT, Cursor, and many others.

When a client and server implement compatible protocol capabilities and transports, the integration can be reused. Authentication, feature support, elicitation, roots, sampling, and approval UX can still differ; test the actual pair.

A loose analogy is a standard connector. Do not stretch it: sharing a protocol does not mean any server works with any client, just as a physical connector alone does not establish driver, permission, or device compatibility.

What you can do with MCP today

The MCP Registry is a discovery starting point. Availability and publisher status change, and a listing is not an endorsement. Search by the capability you need, then verify the exact publisher, repository, release, permissions, and transport. Common categories include:

Productivity:

• Gmail, Outlook, Google Calendar, Microsoft Calendar
• Notion, Obsidian, Roam Research, Logseq
• Slack, Discord, Teams
• Linear, Jira, Asana, Trello, Monday
• Google Drive, Dropbox, OneDrive, S3

Development:

• GitHub, GitLab, Bitbucket
• Cursor’s filesystem, terminal, browser
• Docker, Kubernetes
• Cloud and infrastructure APIs (permission model depends on the server and credential)
• Postgres, MySQL, MongoDB (often read-only)

Web:

• Brave Search, Google Search, Tavily, Exa
• Browser automation (Playwright, Puppeteer-based)
• Site-specific scrapers

Data:

• Sheets, Airtable
• Various databases via custom connectors
• BI tools (Metabase, Cube)

Specialised:

• Stripe, QuickBooks (for finance)
• Salesforce, HubSpot (CRM)
• Calendly, Cal.com (scheduling)
• Twilio (SMS)

Do not assume a named product has a maintained or official server. If the vendor does not link it from first-party documentation, label it community software and review it accordingly.

Setting up your first MCP server

Let’s walk through a practical setup using the official filesystem reference server and Claude Desktop. It is deliberately local and easy to revoke; vendor-specific Gmail servers vary in publisher, OAuth surface, maintenance, and trustworthiness.

Step 1: Verify the client. This procedure uses Claude Desktop because the official MCP quickstart documents its local configuration. For any other client, confirm current MCP transport, configuration, approval, and plan support in that client’s first-party docs before adapting the example.

Step 2: Start from a first-party guide or registry entry. Use the official local-server quickstart and MCP Registry. A listing is discovery, not a security endorsement: confirm the publisher, repository, release history, requested permissions, and exact package before installing.

Step 3: Create a dedicated test directory. Do not grant the server your home folder. On macOS or Linux:

mkdir -p "$HOME/mcp-sandbox"

Put two non-sensitive text files there. The official server is launched by the client with npx; no placeholder package or invented Gmail integration is required.

Step 4: Configure the client. Each AI client has a place to configure MCP servers. In Claude Desktop, it’s the claude_desktop_config.json file in your Claude config directory (on macOS, ~/Library/Application Support/Claude/). The configuration typically looks like:

{
  "mcpServers": {
    "filesystem-sandbox": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/ABSOLUTE/PATH/TO/mcp-sandbox"]
    }
  }
}

Replace the path with the exact absolute directory you created. The official quickstart warns that the server runs with your user-account permissions; MCP roots communicate intended scope but are not an operating-system sandbox. Use OS permissions or a container/VM for a stronger boundary (MCP client concepts).

Step 5: Restart the client and test the boundary. The MCP server should start automatically. Confirm the server indicator appears, read one sandbox file with approval, create one disposable file with approval, and then ask for a file outside the allowed directory. The final request must be denied or unavailable.

You can now ask things like:

List the files in my MCP sandbox and summarize meeting-notes.txt.

Create summary.md in the sandbox. Show the proposed write and wait for my approval.

Do not proceed to email, calendar, CRM, database, or shell servers until this read/write/deny test behaves as expected.

An evaluation shortlist for a productivity stack

After the filesystem boundary test passes, list the smallest capabilities you need. Possible candidates — only when a current first-party or reviewed server exists — include:

1. Email search or draft-only access — no send tool during evaluation.
2. Calendar free/busy or event reads — no create/update until approval semantics are tested.
3. Knowledge-base retrieval — verify source ACLs are preserved.
4. Issue tracker reads or draft creation — restrict project and mutation scope.
5. Web search — preserve canonical source URLs and treat retrieved pages as untrusted input.

Setup time varies with OAuth review, publisher quality, network policy, and client support. Add one server at a time and keep a revocation note for each credential.

Capabilities to test, not promises:

• Conversational email triage that knows your calendar.
• Meeting prep that pulls notes from Notion and recent emails from Gmail.
• Propose a meeting with the same group as a prior meeting, then require a human to verify attendees, time, timezone, and title before creation.
• Issue creation in Linear from a conversation.
• Real-time research with citations.

The trust shift is more important: the client can now retrieve private context or propose actions through server credentials. Update the data-flow diagram, risk register, and revocation procedure for every server.

Security and permissions

MCP servers are running on your machine and have whatever access you give them to your accounts. This is powerful and means you should think about it.

Use scoped credentials. When you create OAuth credentials or API keys, scope them to the minimum needed. “Read calendar, write events” is much narrower than “full Google access.”

Audit the servers you install. If source is available, review the exact tagged code and dependency lockfile; if it is not, treat that as additional supply-chain uncertainty. Popularity, an open-source licence, or repository visibility is not a security assessment.

Don’t treat a catalogue as vetting. Prefer a server linked by the service vendor or protocol project, but still verify package identity, repository, release provenance, dependency risk, credential scope, and maintenance. A familiar maintainer name is not a security review.

Be careful with shell access servers. Some MCP servers expose terminal command execution to the AI. Useful for some workflows; a major security risk if you’re not careful. The AI can execute arbitrary commands on your machine if you give it that capability.

Treat MCP servers as extensions of your AI’s trust surface. What the AI can read, see, or act on through the server is whatever it would do directly. Plan accordingly.

What MCP is bad at (in 2026)

A few real limitations:

Discovery is not assurance. The official registry helps find packages, but it does not prove a server is suitable for your data or deployment.

Quality variation. Server implementations differ in maintenance, testing, authentication, error handling, and operational support. Verify the exact release against your acceptance criteria.

Documentation may be incomplete. Enumerate the tools the live server exposes and compare them with its documentation; do not assume a README lists the full permission surface.

Cross-client variability. Clients can differ in transports, supported protocol features, configuration, approval UX, logging, and enterprise policy. Verify the current client/server pair rather than ranking products from this article.

Lifecycle and long-running work. Confirm cancellation, progress, reconnect, timeout, and duplicate-request behaviour for your client/server versions; a successful one-shot tool call does not validate a long-running workflow.

These constraints are reasons to begin with a disposable, non-sensitive test and a written acceptance checklist.

When to write your own MCP server

Write a custom server when no reviewed server provides the narrow contract you need, or when you must own the authentication, validation, audit, and deployment boundary. Typical cases include:

• An internal tool your company built.
• A SaaS product without a public MCP server.
• A legacy system with only a custom API.
• A specific workflow that combines multiple tools in a custom way.

The protocol handler may be small, but production work includes authentication, input/output schemas, authorisation, rate limits, secrets, audit logs, deployment, upgrades, adversarial tests, and incident ownership. Estimate from the required controls, not a line count.

A custom server is justified only when expected reuse exceeds its ongoing security and maintenance cost. Prototype against non-sensitive data; complete engineering and security review before real accounts.

We have a dedicated article on building MCP servers in TypeScript.

MCP vs Zapier / n8n: when to use which

A common question: if I have Zapier or n8n, do I need MCP?

The answer is “they’re complementary, used differently.”

Use MCP when:

• A supported client needs a standard tool/context interface.
• The server can expose a narrow schema and permission scope.
• You have tested the client’s approval, cancellation, logging, and transport behaviour.

Use Zapier / n8n when:

• You want a workflow that runs autonomously on a trigger.
• The workflow is explicit, repetitive, observable, and needs connectors, state, retries, or human gates.
• Operators need to inspect and recover each step.

These are tendencies, not exclusive categories: MCP servers can be called from automation, and workflow platforms can include interactive approval.

n8n currently documents MCP client and server capabilities in its MCP documentation. Verify the exact node/version, authentication, exposed workflow set, and client compatibility; building a workflow once does not guarantee it is safe or portable to every MCP client.

A few practical patterns

Conversational triage with MCP. Start with one read-only source and a non-sensitive test set. Verify retrieved item IDs, omissions, source links, and denial outside scope before combining sources.

Meeting prep with MCP. With approved read scopes, request a brief that cites the calendar event and each email/note used. Check attendee identity, access control, stale notes, and missing evidence; do not let a generated brief silently become the meeting record.

Research with grounded sources. Require canonical URLs and distinguish retrieved facts from model inference. A search tool does not guarantee complete retrieval, accurate citations, or permission to republish source text.

Code with filesystem or terminal tools. Treat each as execution under the server process’s real OS permissions unless independently sandboxed. Start with a disposable repository, deny secrets and parent directories, approve mutations, and verify the rollback path.

A small habit that compounds

When you repeatedly copy data between an AI conversation and another tool, record the use case. Then ask whether an MCP server, a native connector, a deterministic workflow, or leaving the step manual gives the best permission and review boundary.

Do not estimate setup from package installation alone. Publisher review, credentials, enterprise policy, boundary tests, monitoring, upgrades, and revocation are part of the work. An “invisible” bridge is a liability if nobody owns it.

Start with one disposable server

MCP is one integration option for connecting AI applications to context and tools. It should earn its place against native connectors and explicit workflows.

Non-engineers can follow a first-party setup, but someone still owns security and operations. Setup and maintenance effort depend on the accounts and actions exposed.

Complete the filesystem exercise first. Keep only the server whose allowed read, allowed write, outside-root denial, restart, and revocation tests pass. Add a real account only after that review.