# Skill: Connect and use MCP servers to give an AI agent real-world tools and data access

> Use this skill when an agent needs to reach outside the chat -- read email, query a database, search the web, or file a ticket -- by plugging in the appropriate MCP server instead of writing a custom integration.

Source: sodigi-learn -- vibecoding/mcp-novye-umeniya - https://sodigi.io/learn/vibecoding/mcp-novye-umeniya

## When to use
- The agent needs live data it cannot generate from memory (email inbox, current search results, database rows).
- A recurring workflow needs an action the agent cannot take without a tool (send a message, create a ticket, run a test suite).
- You are evaluating whether to build a custom MCP server or use an existing one.
- You want to constrain an agent's MCP permissions to the minimum needed for a task.

## Core rules
- MCP is a standard protocol (like USB): one connector shape, hundreds of ready-made servers. Search for an existing server before writing one from scratch.
- Every MCP server exposes up to three primitive types: tools (agent DOES something -- a verb), resources (agent READS data -- a noun, URI-addressed), prompts (ready-made command templates with fill-in parameters).
- A good tool has one narrow job, a clear input schema, and a response that tells the agent what happened and what to do next.
- A mega-tool that does everything confuses the agent about when to call it.
- Local servers connect over stdio (same machine). Remote servers connect over HTTP (Streamable HTTP is the current standard; SSE is legacy).
- Grant the minimum permissions for the task -- if reading email is enough, do not grant delete and send.
- Only install MCP servers you trust -- each server sees your data.
- MCP gives longer arms, not a smarter brain. A vague task will be botched via MCP just as it would be without it.
- Always ask the agent to report tool failures honestly rather than inventing plausible output.

## Procedure
1. Identify what external capability is needed (read email, query DB, search web, etc.).
2. Search for an existing MCP server for that capability before building one.
3. Install and configure the server with minimum necessary permissions.
4. In the prompt, explicitly separate READ actions from WRITE/DELETE actions and require confirmation before the latter.
5. Instruct the agent to report honestly if a tool is unavailable or returns an error.
6. After the task, review what the agent actually did through the tool to verify no unintended actions occurred.

## Ready-to-use prompt
```
You have access to [service] through MCP. Do the following:

1. [READ action only, e.g., "Read only today's emails."] Do not [delete/send/modify] anything without my permission.
2. [Process and summarize what you read -- specific format].
3. For [the most important N items], draft [a response/action] but do NOT execute it -- show me first.
4. If a tool is unavailable or access failed, tell me honestly -- do not invent the contents.
```

## Pitfalls
- Plugging in every available MCP server "to have options" -- each one sees your data; install only what you trust and need.
- Granting full permissions when only read access is required -- follow minimum-privilege; grant read-only unless write is explicitly needed.
- Expecting MCP to make the model smarter -- it extends reach, not intelligence; a bad prompt still produces bad output.
- Using one mega-tool that handles everything -- the agent gets confused about when to call it and what it returned.
- Assuming the agent successfully completed an action -- ask it to confirm, and double-check important operations yourself.
- Writing an MCP server from scratch when a polished ready-made one already exists.
- Using outdated SDK syntax from memory -- always reference the current official MCP documentation.