Agents, tools and MCP

An "agent" is a model that does not just answer: it loops. It reads, decides, acts, observes the result, and decides again. What makes the loop possible is tools, and the standard way to give a model tools is MCP.

The agent loop

1. The model reads the current state (your request, the plan, the context).
2. It chooses an action: call a tool, write a file, run a command, ask you something.
3. The tool runs and the result comes back.
4. The model sees the result and repeats, until the task is done or it asks for help.

This loop is what turns "a chatbot" into "something that can actually change your machine." It is powerful and, without guardrails, dangerous.

Tools

A tool is any capability you expose to the model: read a file, search the web, query a database, run a shell command, call an API. Each tool has a description and a schema, and the model calls it like a function. The quality of an agent is mostly the quality of its tools and how well they are described.

MCP (Model Context Protocol)

MCP is a standard for describing tools so any agent can use any MCP server. Instead of wiring each integration by hand, you point your agent at an MCP server and it discovers the tools. vram.wiki itself exposes one: read the catalog, read a setup, or (authenticated) prepare a proposal for review.

The two lessons

1. Agents are loops, not magic. They fail by looping badly: getting stuck, repeating, or doing the wrong thing confidently. Plan and scoping matter more than the model.
2. Tools are the attack surface. Every tool you give an agent is something it can misuse. The next lesson is about keeping that safe.

For most people, the practical path is: pick an existing harness with good tools, understand its loop, then add your own tools as you learn where it fails. The catalog records the real combinations people run: which harness, which model, which tools.