--- title: "Prompt, skill, tool, MCP, and agent: what each one does" summary: "A simple guide to instructions, procedures, tools, integrations, and agents — and how context, plans, and loops connect them." slug: "prompt-skill-tool-mcp-agent" language: "en" publishedAt: "2026-10-06" updatedAt: null tags: - "agents" - "context" - "tools" - "good-practices" translationOf: "pt/prompt-skill-tool-mcp-agent" translationStatus: "current" --- A prompt gives direction. A skill organizes a reusable procedure. A tool makes an operation possible. MCP standardizes integration. An agent decides the next steps and coordinates execution. These five sentences are a starting point. But each term has a different role in working with AI. Understanding the difference helps you write better requests, choose resources, and investigate why a task failed. ## Prompt: the direction of the request A prompt guides the model on what to do, which limits to respect, and what response to deliver. It can include a question, instructions, examples, and completion criteria. ```txt Stage: diagnosis. Investigate why the copy-code button fails on mobile. Do not change files. Report the likely cause and the evidence you found. ``` The request defines a task and its boundary. A prompt can also explain how to do something. What distinguishes a skill is how the procedure is organized and reused. A clear instruction helps. It does not guarantee a correct interpretation or result. ## Skill: a procedure that can be reused A skill brings together knowledge and instructions for a type of task. In the Agent Skills format, it contains a `SKILL.md` file and can include scripts, references, and document templates. An accessibility review skill, for example, can guide checks for focus, contrast, semantics, and keyboard navigation. The procedure can be applied across projects. Each project's context is still necessary. Recurring tasks are a good reason to create a skill. But it can also help with a one-off task that requires specialized knowledge. The skill guides the work. When it needs to read files, run scripts, or query data, it depends on the available tools. [Reference: Agent Skills](https://agentskills.io/home). ## Tool: the available operation A tool makes a concrete operation possible. Read a file. Consult a page. Edit code. Run a test. Not every operation changes something. A search is also tool use. The model can request a tool call. The system running the model processes that call, subject to the available permissions, and returns the result. That result becomes information for the next decision. Asking for a test in a prompt does not prove it ran. The evidence lies in its execution and the returned result. ## MCP: the communication standard MCP stands for Model Context Protocol. It is a protocol that standardizes communication between AI applications and servers that provide capabilities and context. These servers can offer: - **tools:** executable functions; - **resources:** data and content that provide context; - **prompts:** reusable interaction templates. A repository integration can offer a tool to look up issues, a resource containing documentation, and a template to guide a review. MCP defines how these capabilities are discovered and accessed. The application and the agent decide when to use them. Tools can also be integrated directly, without MCP. [Reference: MCP architecture](https://modelcontextprotocol.io/docs/learn/architecture). ## Agent: decisions during execution An agent is a system that uses a model to carry out a task: choose next steps, use tools, and evaluate results. The model is a component of that system. It interprets inputs and generates responses or tool requests. The agent combines that capability with the execution environment. The agent can consult files, notice missing information, run a check, and change direction based on the result. It works within the available instructions and permissions. Skills and MCP can extend its capabilities. They are not requirements for every agent. The definition of an agent varies across products. In this article, the central point is making dynamic decisions about how to proceed. [Reference: Building effective agents](https://www.anthropic.com/engineering/building-effective-agents). ## Loop: act and observe before continuing The loop is the execution cycle: ```txt Understand the current state → decide the next step → perform an action → observe the result → decide whether to continue, adjust, or stop ``` A test fails. The agent examines the error, adjusts the implementation, and tests again. This is not about repeating the same request indefinitely. Each result needs to inform the next decision. The cycle should have a stopping condition: the objective is met, the attempt limit is reached, or human intervention is needed. A loop alone does not define an agent. Programs with fixed steps can also repeat operations. ## Plan and workflow: the sequence of work A plan records proposed steps, their dependencies, and the expected validations. A workflow organizes how those steps connect. A predefined workflow can always follow the same sequence. An agent can choose the next step as it encounters new evidence. The two can work together. An editorial workflow can specify writing, review, translation, and publication. During review, the agent decides which references it needs to consult. The plan can live in a document. `PLANS.md` is a convention adopted in this project, not a mandatory filename for AI systems. ## Context, README, and AGENTS.md Context is the information available to the model at that moment. It includes the request, relevant instructions, consulted files, accessible history, and tool results. A file's presence in the repository does not mean its contents are available in that model call. Two documents help organize this context: - **`README.md`:** introduces the project and explains how to start using or developing it. [Reference: GitHub Docs](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes). - **`AGENTS.md`:** records project guidance for coding agents, such as conventions, commands, and validations. [Reference: AGENTS.md](https://agents.md/). A README can also help an agent. People can also read AGENTS.md. The distinction lies in each document's focus. Project rules go in AGENTS.md. A procedure that can be reused across projects can go in a skill. Task-specific instructions go in the prompt. For more on this topic, read [Context Is Infrastructure in Vibe Coding](/en/posts/context-is-infrastructure-in-vibe-coding/). ## An example: fixing code copying First, a prompt asks only for a diagnosis of the button that fails on mobile. The agent consults the project rules, reads the component with a tool, and observes its behavior. An accessibility skill can help if it is relevant to the investigation. Once the diagnosis has been reviewed, another stage defines the plan. A new request then authorizes the implementation of a scoped fix. Tools edit the file and run checks. The agent uses the results to decide whether the fix is ready or needs adjustment. That is the loop. If an issue needs to be consulted through an MCP integration, the protocol standardizes that access. If local files are enough, the task can proceed with local tools. At the end, the agent records what changed, which checks passed, and what remains uncertain. Each stage has a verifiable output. That boundary is also discussed in [A Task Is Not a Project](/en/posts/a-task-is-not-a-project/). ## Use each piece when it helps Not every request needs a skill. Not every tool needs MCP. Not every task needs an agent with multiple steps. Start with the objective. Provide relevant context. Choose the necessary resources. Verify the result. Knowing the terms is only useful when it improves those decisions.