Skills, MCP tools and rules: three ways to give an agent capabilities

🧰 Three kinds of capability

A rule is an instruction that always applies: "never stage everything", "numbers need an artifact". It limits behaviour and does nothing by itself. It should reach every executor, including cheap ones and scripts.

A skill is a packaged way of doing a job: a folder with instructions the agent loads when the task matches. A skill may tell the agent to run commands or change files. It can carry authority, such as being our own required method, or only advise.

A tool is a function the agent calls through a protocol such as MCP. It has a name, parameters and a return value. A tool does things: read a database, search documents, write a record.

The distinctions matter because each fails differently. A bad rule is ignored, a bad skill misleads, and a bad tool acts.

📒 One register for all three

We declare our skills in one registry file. Each entry has a domain, an authority (our own canon or outside advice), a risk class, the lowest executor level that may use it, whether it needs a person, and whether it acts or only states a rule. A test fails when a skill folder exists without an entry, or an entry without a folder.

On 3 November 2026, 21:53 UTC the registry held 32 entries: 14 canon and 18 advisory; 24 that act and 8 that only state rules.

Our MCP server is a separate surface with its own control. On the same day its code defined 21 tool functions. The one that writes to the knowledge base runs only when a deliberate setting is on, and each call is recorded in an audit database with its status and duration.

🔗 How they fit together

A rule can tell an agent to use a skill. A skill can tell an agent to call a tool. A tool can return text that tries to give the agent a new rule. Treat that last path as hostile, as we do with any outside text.

The register is where the chain becomes visible. If a skill calls a tool that writes to a remote system, the skill's risk class must say so, and it must require a person.

🛠️ Practice: inventory your capabilities

1. List your rules: files that are loaded into every session.
2. List your skills: folders of instructions. Give each a domain, an authority and a risk class.
3. List your tools: every function your agents can call. Mark which read, which write and which reach outside.
4. Put the three lists in one register, with a column for kind.
5. Write a test that compares the register with what exists on disk or in the server, in both directions.
6. For every entry that acts on a remote system, set "needs a person" and a minimum executor level.
7. Add an audit record to every tool call: name, arguments, result status, duration.

✅ Check yourself

• Add a new skill folder without an entry. The test fails and names it.
• Add a tool to the server without listing it. A reviewer or a test notices.
• Pick any entry and say what the worst case is, who approves, and which executor may run it.
• Find the audit record for a tool call made yesterday.

🚧 When this does NOT work

• Entries that are out of date. A register nobody updates describes a system that no longer exists. Tie the test to the build.
• Counting tools by code. A tool defined dynamically will not be found by a text count. Use the server's own list.
• Rules that are never read. A rule in a file the agent never loads has no effect. Test that it is in the start context.
• Outside skills. Third-party skills can ask for powerful actions. Mark them advisory and never mandatory.
• Risk classes that are too coarse. Four classes are a start. Add detail where decisions turn on it.

📊 Evidence

➡️ Next

Write down who may use what in An AI usage policy and register a small team can enforce, and see how MCP works in What is MCP?.

Sources

• An AI usage policy and register a small team can enforce: the register.
• What is MCP? Servers, clients and safe connections: MCP basics.
• AGENTS.md and rules files: rules.
• MCP server security checklist: checks.