MCP Clients, Servers, and Tools

Why it matters: The Model Context Protocol is becoming the standard way to plug AI apps into files, databases, and SaaS tools. A server you connect can read your data or take actions, so knowing the roles and trust boundaries is a core professional skill.

By the end you can:

• Name the host, client, and server roles
• Distinguish tools, resources, and prompts
• Read a tool definition and spot risky capabilities
• Apply a pre-connection review checklist

Learn (15 min)

1. What MCP standardizes (5 min)

MCP is an open protocol that lets AI applications connect to external capabilities in a consistent way. It standardizes how they talk; it does not make a server safe or grant permissions by itself.

• Host: the AI application the user works in.
• Client: the connector inside the host that talks to one server.
• Server: a program that exposes capabilities, running locally or remotely.

2. Three primitives (5 min)

A tool is described by a name, a description, and an input schema:

{
  "name": "send_email",
  "description": "Send an email from the shared support mailbox",
  "inputSchema": {
    "type": "object",
    "properties": {
      "to": { "type": "string" },
      "subject": { "type": "string" },
      "body": { "type": "string" }
    },
    "required": ["to", "subject", "body"]
  }
}

The model reads the description and schema to decide when and how to call it, which means descriptions are also an attack surface (Lesson 10).

3. Trust and authorization (5 min)

Before connecting a server, check who built it, where its code runs, what it can reach, how credentials are stored, and what it logs. Apply least privilege: read-only where possible, narrow scopes, a test account first. Require confirmation for consequential actions (sending, paying, deleting). Validate inputs and outputs, and treat server output as untrusted data. The host and server implement consent and security; the protocol is not a security review.

Apply (15 min)

Worked example (3 min). A server offers search_contacts and send_email. Review: publisher verified and code inspected; test mailbox only; contacts limited to one list; send_email requires user approval each time and cannot add CC/BCC without review; credentials in the host's secret store; logs exclude message bodies; a documented way to disconnect and revoke.

Lab (7 min): Review a tool list.

1. Find any MCP server's tool list (a public example server is fine) or invent three tools.
2. For each tool, label read/write, data touched, and worst-case misuse.
3. Decide: allow, allow with confirmation, or block.
4. Write two sentences on what you'd verify about the server's publisher.

Deliverable: A table: tool | read/write | worst case | decision. You're done when: Every write tool has a confirmation or restriction.

Check yourself (5 min)

1. What are the three roles?
2. Tool vs. resource?
3. Scenario: A server asks for access to your entire Drive to "read one spreadsheet." What do you do?
4. Why is a tool description a security concern?
5. Does connecting a server mean it's been approved as safe?

Reference

Common mistakes

Cheat sheet: Host contains client → client connects to server → server exposes tools, resources, prompts. Review every permission; confirm side effects.

Key terms: MCP host, client, server, tool, resource, prompt, least privilege.

Interview prompts: Explain MCP to a non-technical manager. How would you vet a third-party server?

Go deeper: MCP Architecture · Tools · Resources · Security Best Practices

Next: Lesson 9 — agents that chain tool calls.