MCP For Dummies Cheat Sheet

The Model Context Protocol (MCP) is an open standard that lets AI applications connect to outside tools, data sources, and services by way of a common interface. Rather than build a custom integration for every database, file system, or business app an AI assistant needs to reach, developers can plug into any MCP server that already exists or build a new one using the same predictable pattern. This cheat sheet collects the core terms, decisions, and checklists that come up most often when working with MCP, so they're handy whether someone is configuring an initial server or troubleshooting a production deployment.

Core MCP vocabulary

The terms in this list show up throughout any discussion of MCP, so it helps to have quick definitions on hand:

• Client: The component inside the host that maintains a one-to-one connection to a single MCP server and handles the protocol-level back-and-forth.
• Host: The AI application a person interacts with directly, such as a chat client or an IDE assistant. The host manages one or more client connections.
• Prompt: A reusable, parameterized template a server provides to help structure a common request.
• Resource: Data that a server exposes for the AI model to read, such as a file's contents, a database record, or a configuration value.
• Server: A lightweight program that exposes a specific set of capabilities (tools, resources, or prompts) to any client that connects to it.
• Tool: An action a server makes available for the AI model to invoke, such as running a query, sending a message, or creating a file.
• Transport: The communication channel between a client and a server. The two most common are stdio (for local processes) and HTTP with Server-Sent Events (SSE) or Streamable HTTP (for remote servers).

Choosing a transport

This table lists the most common transport (communications channel) methods and specifies where best to use them.

Server setup checklist

Before connecting any new MCP server to a live (production) environment, it helps to confirm that

• The server's source and maintainer are known and reasonably trustworthy.
• Every tool the server exposes has been reviewed for what it can actually do — especially anything that writes, deletes, or sends data.
• Credentials and API keys are stored in environment variables or a secrets manager, never hard-coded in configuration files.
• The server runs with the minimum level of access it needs rather than with broad administrative rights.
• Logging is enabled so that tool calls can be reviewed after the fact.
• A plan exists for rotating credentials and updating the server when new versions are released.

When in doubt about whether a tool is safe to expose, start by connecting it in a read-only or sandboxed (nonproduction) mode, and then widen access after its behavior has been confirmed.

Security quick reference

This table provides guidance on security issues (risks) and the best method to minimize potential security problems.

Common MCP mistakes to avoid

Avoid the most common mistakes when setting up MCP:

• Connecting a server with full database or filesystem access when only read access is needed
• Skipping version pinning, which can let an unreviewed server update introduce new behavior without notice
• Assuming that a tool description is accurate without testing what the tool does
• Running many servers simultaneously without monitoring the combined resource usage
• Treating a working local setup as production-ready without adding authentication, logging, or rate limiting

MCP server inventory

Use this table to track the servers in use for any given project. Fill in the blanks as new servers are added.