A single MCP connection exposes an entire set of external tools, and the agent decides which one to call. The diagram below shows the agent connected to an MCP server that provides access to scraping, databases, and documents — and the research workflow that comes from it.
Illustrative diagram — conceptual recreation of the MCP architecture, not a real screenshot.
🔌 What is MCP (Model Context Protocol)
MCP (Model Context Protocol) is a protocol that lets an single connection exposes many tools and actions. Once the agent and MCP server connect, the agent knows all the available tools and decides on its own which one to call, when, and with what parameters. The analogy: it’s like Gmail exposing the “send,” “draft,” and “search emails” actions—the agent figures out which one to use.
💡 The core idea
Instead of coding an integration for each tool, you connect an MCP server and get an entire set of capabilities at once. The agent starts to “see” these tools and orchestrate them without you saying which one to call.
- •A connection: exposes several actions at once.
- •Autonomy: the agent chooses the tool and the parameters.
- •Pattern: the same protocol works for many services.
Connection pattern.
One server, multiple tools.
Chooses which one to call.
Gmail: send/draft/read.
🗂️ Where to find MCP servers
MCP servers are in dedicated directories (like mcp.so) and also show up in GitHub search for “MCP server” plus the service name. Knowing where to look — and which category your need falls into — speeds up choosing the right tool for the task.
Scrape and read web pages. Example used in this track: Firecrawl.
Read and write data. Examples: Postgres, Supabase.
Access files and notes. Examples: Google Drive, Notion.
Send messages and emails. Examples: Slack, Gmail.
🎯 Practical tip
Before installing, think about the category: “Do I need scraping, a database, documents, or communication?” This narrows the search and avoids installing servers you won't use (and that consume context).
mcp.so and similar tools.
Search “MCP server” + service.
Scraping/databases/docs/community.
Only what the task asks for.
📦 Install an MCP Server
To install it, you give the agent the installation command from the provider's documentation; it generates the file .mcp.json with the server entry and a key placeholder. Then, you sign up with the provider, get the API key, and enter it manually in the configuration file—never pasted into the chat.
Installation walkthrough
Copy the command from the documentation
In the provider's docs (e.g., Firecrawl → Integrations → MCP → code assistant section), copy the installation command.
Let the agent generate the .mcp.json
Ask it to install using that command; it creates the .mcp.json with the server config and the key placeholder.
Insert the key manually
Sign up with the provider, copy your API key, and paste it yourself into the config file — outside the chat.
⚠️ Attention: the API key
- ✗Never paste the key into the chat or let the agent insert it.
- ✗Enter it manually in the configuration file — it's safer.
- ✗Treat the key like access to a credit card: if it leaks, anyone can spend.
From the provider’s documentation.
Generated by the agent.
Never in the chat.
Sign-up + API key.
🩺 Check and Diagnose
After installing, verify with the command /mcp: it lists the installed servers and the status of each one. If a newly installed server doesn’t appear, the most common cause isn't a failed installation — you just need to restart the assistant so it can register the new components.
✓ Do it
- ✓Run
/mcpto see the servers and their status. - ✓Restart the assistant if the server doesn’t appear.
- ✓Confirm the connection before you start using the tool.
✗ Don’t
- ✗Thinking the installation failed without restarting first.
- ✗Reinstall from scratch out of impatience.
- ✗Use the tool without confirming that its status is "connected."
🎯 Practical tip
“Didn’t show up? Restart it.” This reflex solves most cases of an invisible server and saves hours of unnecessary troubleshooting.
Lists servers + status.
Records new servers.
Connected or not.
Forgot to restart.
🔎 Research workflow with Firecrawl
With the MCP in place, you can build an end-to-end research workflow: you provide a theme, the agent searches the web with Firecrawl, synthesizes the findings and generates a structured document. All while reusing the WAT framework and a WAT CLAUDE.md as the master configuration read at every session.
Plan → Build → Run
Plan — describe the workflow
In Plan Mode, describe: choose a topic, research the web, find relevant and current information, compile it into a structured brief, and generate a document in the temporary folder via Firecrawl. Answer the questions (output format, number of sources).
Build — generate workflows + tools
The agent generates the .env, Firecrawl’s .mcp.json, the Markdown → document conversion tool, and the research workflow.
Run — trigger with a theme
Clear the context and start with a specific topic. The agent reads the workflow, runs searches in Firecrawl, synthesizes the results, and turns them into a document.
🎯 What the workflow specifies
A good research workflow specifies triggers, inputs, steps, a source target (e.g., 3-5 focused searches), error handling, and criteria for evaluating each source — so the output is consistent and reliable.
The workflow entry point.
Searches the web.
Compiles a brief.
Search target.
📄 Output Pipeline
The output pipeline separates formatting content: the agent first produces a markdown and then converts it into a document file using a generated conversion tool. This makes the output flexible—the same content can be turned into different formats—and easy to audit.
tema → busca Firecrawl → síntese → brief.md (conteúdo, markdown) → ferramenta de conversão → brief.docx (formato, documento)
⚠️ Attention: keeping the two files in sync
- ✗Updating the Markdown doesn’t always update the final document.
- ✗When asking for a change, explicitly ask it to update both.
- ✗Don’t rely only on how the Markdown looks—open the generated document.
🎯 Practical tip
When changing the formatting (e.g., switching the sources section from a table to a list), ask it to propagate the change to the markdown e to the document. Otherwise, you fix one and the other becomes outdated.
The content comes first.
Generated tool.
The final format.
Update both.
♻️ Iteration & self-healing
The first run rarely comes out perfect—and that’s okay. Quality comes from the iteration loop: you give specific feedback ("I like the structure, but reformat the sources as a list") and, if something breaks, ask the the AI itself to fix (self-healing). The more specific the feedback, the better the result.
✓ Feedback that works
- ✓“Reformat the table sources section as a list.”
- ✓“The tone is too formal; make it more direct.”
- ✓“Did it break? Check the error and fix yourself.”
✗ Feedback That Stalls Progress
- ✗“It’s bad.” (without saying what or where)
- ✗“Redo everything.” (throws away what was already good)
- ✗Give up at the first error instead of asking for a fix.
🔁 The self-healing loop
If the workflow fails, copy the error and send it back to the AI, asking it to fix it. Remember to ask for the fix to be applied to the workflow and the tool, not just the result—so the next run starts out right.
The first run isn’t the final one.
Say what and where.
Ask it to fix itself.
Fix in the workflow.
🧠 Quick check
Where should you enter the API key for a newly installed MCP server?
📌 Module Summary
Next Module:
2.3 — Skills, Artifact Generation & Tokens