TL;DR: A prompt tells the model what to do. A tool gives the application an operation it can execute when a permitted request arrives. A skill packages instructions and resources for a recurring job. Loading a skill changes the working context; it does not retrain the model or authorize an action.
One refund, three different objects
A fictional support assistant receives: “Check order 58213 and prepare a refund for the missing item.” The prompt is the request plus standing instructions. A lookup_order tool fetches the current order. A refund-review skill explains which evidence to collect and how to present a proposal. A separate issue_refund tool changes the payment record only after the application's checks pass.
| Object | Example | What the PM must specify |
|---|---|---|
| Prompt | Prepare a refund proposal with its source evidence | Intended outcome and ambiguity handling |
| Tool | lookup_order(order_id) | Inputs, side effects, authorization and return contract |
| Skill | Refund-review procedure with a policy checklist | Trigger, version, owner and review process |
| Runtime | Application that loads instructions and dispatches calls | Enforced permissions, limits and execution records |
A skill may call several tools. A tool may be used without a skill. The runtime can also perform deterministic steps without asking a model to choose them.
What loads at runtime
As of October 2026, the Agent Skills format uses a directory with SKILL.md and optional resources. Its documented loading pattern exposes brief metadata first, then loads instructions when relevant, with additional files or scripts used as needed. The specification defines the packaging; individual clients decide how they support and execute it.
Follow the flow, one stage at a time.
Illustrated sequence; animation speed does not represent processing time.Read diagram description
Discover skill metadata, match the task, load instructions, load relevant resources, propose a tool call, validate and authorize it, execute permitted code and check the result. Runtime loading does not update model weights or grant permission.
The model's weights remain unchanged during that loading sequence. A script inside the package runs only if the host provides an execution facility and permits the request. Review that code as code. Installing a useful-looking procedure is not evidence that its network access or file operations are safe.
A tool description is part of the interface
“Handles orders” leaves the caller guessing. A better contract says: lookup_order reads the current delivery and item status for one order belonging to the signed-in customer. It makes no changes. It returns source timestamps and a structured not-found result. Use prepare_refund for a proposal; this lookup never issues money.
The model-facing definition needs a distinct name, a description of when it applies, and an input schema with required fields, types and units. The application also needs a response schema, errors, side-effect policy and timeout behavior. A well-formed call can still target the wrong order, so schema validation does not replace authorization.
For an illustrative amount field, prefer an integer amount_minor with an explicit currency over a free-text “refund amount.” The server must check the requested amount against the refundable balance and bind approval to the exact order and amount. Never infer the currency from the user's location.
Measure the failure you changed
Suppose a teaching set contains 60 support requests. The old descriptions cause 12 wrong-tool selections; revised descriptions cause five. That is a fall from 20% to about 8.3% on this set. It does not establish safe refunds: inspect those five errors, test unauthorized order IDs and measure completed tasks on fresh requests.
Test the skill trigger too. A skill that is excellent after loading but never selected cannot help. A skill selected for every conversation can crowd out relevant context. Keep versioned positive and negative trigger examples, including requests that must stop for clarification.
Where MCP fits
MCP supplies a connection contract between an AI application and servers offering capabilities. A skill can explain how to use an MCP-exposed tool, but it is not the protocol and does not replace the underlying API. Compare a direct API integration with MCP on the actual clients you must support, authentication, error semantics and maintenance. A single internal lookup may need no new protocol layer.
The PM decision is to own the procedure and permission boundaries separately. Practise the tool-call sequence, diagnose confusing tool catalogs, then use the execution envelope to specify the checks the model cannot waive.