{"slug": "real-plugins-need-motors-skills-should-teach-tools-not-pretend-to-be-them", "title": "Real Plugins Need Motors: Skills Should Teach Tools, Not Pretend to Be Them", "summary": "A developer argues that AI agent skills and plugins are often conflated, but a folder of instructions is not a tool. The developer proposes a clear architecture: skills teach, plugins package, tools act, MCP exposes, hooks enforce timing, and guards protect. The distinction matters to avoid 'context debt' that consumes a model's attention before it reaches the problem.", "body_md": "[Watch the short video companion](https://www.youtube.com/shorts/pADapMCfTR0)\n\n**Read or comment on the complete paper:** [English edition](https://drive.google.com/file/d/1IB2T0zo4QcDnnzrwfMFdYo9M5hK7Ez7v/view?usp=sharing) | [French edition](https://drive.google.com/file/d/1z5orC_C-2IMGLOp7iVnaCJ2rR6KIXExh/view?usp=sharing)\n\nI spent a long time building AI workflows before admitting something painfully simple: a folder full of instructions is not automatically a tool.\n\nA `SKILL.md`\n\ncan be brilliant. An `AGENTS.md`\n\ncan save a repository. A plugin manifest can package a clean idea. None of them, by themselves, can validate a file, inspect live state, call a service, reject malformed input, or prove that an action happened.\n\nThat distinction matters because agent ecosystems are expanding faster than their vocabulary. We use *skill*, *plugin*, *tool*, *hook*, *resource*, and *MCP server* as if they were interchangeable. They are not.\n\nMy rule after this research is direct:\n\nA skill should teach the agent how to use a capability. A real plugin should make that capability available. When the task requires action, the plugin needs a motor.\n\nThis article became a case study inside my own workshop.\n\nI inspected a memory plugin that was not fake. It already had executable tools, a server surface, tests, and useful routes. Yet its activation instructions pushed Codex toward selecting and dispatching a large agent job before establishing whether memory was needed at all.\n\nNothing was syntactically broken. The architecture was simply asking activation to do too much.\n\nActivating a plugin should make capabilities available. It should not behave like a dispatch order.\n\nThat difference sounds small until the workspace grows. One skill becomes ten. Every correction becomes a permanent rule. Every successful workflow becomes another Markdown file. Soon the model spends the beginning of each task reading the workshop labels instead of touching the work.\n\nI call this **context debt**.\n\nThe debt appears as hesitation, instruction conflicts, stale rules, broad triggers, and repeated searching. The model is not necessarily weaker. We may have consumed its useful attention before it reached the problem.\n\nInstruction is language. Instrumentation is contact with reality.\n\nThis does not make instructions weak. Instructions carry intent, style, constraints, and professional standards. A focused skill can prevent expensive wandering.\n\nThe problem begins when a guide impersonates an instrument.\n\nIf the system cannot run the operation, inspect its result, fail honestly, and show evidence, the skill may still be a useful manual. It is not the motor.\n\nThe cleanest architecture I can defend today looks like this:\n\nA skill is focused guidance. It explains when to use a method, how to operate a tool, what risks matter, and what evidence the result must contain.\n\nA plugin is a distribution unit. It can bundle skills, executable tools, MCP servers, hooks, apps, metadata, and assets. Packaging does not prove that every advertised capability exists.\n\nA tool performs a bounded operation. It has inputs, outputs, failure behavior, and evidence. It may be a script, CLI, validator, API adapter, browser bridge, or server handler.\n\nThe [Model Context Protocol tool boundary](https://modelcontextprotocol.io/specification/draft/server/tools) makes capabilities discoverable and callable through schemas. MCP creates a clean door; engineering still decides what the door opens into.\n\nA hook runs at a lifecycle moment: before an edit, after a tool call, before a commit, or during validation. Hooks should be narrow because hidden automation is still authority.\n\nIf the operation touches an account, API, private file, OAuth session, or write action, a guard must decide what is allowed, under which scope, and with which audit trail.\n\nThe short version is worth remembering:\n\nA skill teaches. A plugin packages. A tool acts. MCP exposes. A hook enforces timing. A guard protects authority.\n\nA motor does not need to be impressive. It needs to be real.\n\nImagine a manuscript validator exposed as a tool. Its contract could be as small as:\n\n```\n{\n  \"operation\": \"validate_manuscript\",\n  \"input\": {\n    \"document\": \"article.md\",\n    \"profile\": \"devto\"\n  },\n  \"result\": {\n    \"status\": \"passed\",\n    \"checks\": 12,\n    \"warnings\": 1,\n    \"artifact\": \"validation-report.json\"\n  }\n}\n```\n\nThe important part is not JSON. The important part is that the operation can be executed, the bad input can be rejected, the output can be inspected, and the result can be reproduced.\n\nA motor can be:\n\nOne tested motor beats ten prompt wrappers.\n\nMCP is important precisely because it separates model reasoning from external capability. But a schema is not a security certificate, and a server name is not evidence of correctness.\n\nA serious MCP tool still needs:\n\nThe official [MCP specification](https://modelcontextprotocol.io/specification/2025-03-26) gives us a protocol boundary. It does not eliminate the engineering work behind that boundary.\n\nThis is why the word *plugin* should never end the inspection. Ask what the plugin actually exposes. Ask which process handles the call. Ask what proves success. Ask what happens when the network fails, the token expires, the input is empty, or the user refuses permission.\n\nThe model should request authority less often than the system uses it.\n\nWhen a task needs an API key, OAuth token, JWT, cookie, or private account, the ideal flow is not:\n\n``` php\nuser secret -> prompt -> model context -> tool call\n```\n\nIt is:\n\n``` php\nmodel intent\n  -> capability request\n  -> authorization guard\n  -> scoped credential use\n  -> bounded tool result\n  -> audit trace\n```\n\nThe model needs to know *what it may request*. It usually does not need to know the secret itself.\n\nOpenAI's documentation on [MCP servers](https://developers.openai.com/plugins/build/mcp-server) and [plugin authentication](https://developers.openai.com/plugins/build/auth) points toward explicit tool and authority boundaries. That direction matters for beginners because unsafe patterns become habits quickly. If the normal tutorial begins by pasting tokens, cookies, headers, and `.env`\n\nvalues into chat, we are teaching the wrong abstraction.\n\nTeach scopes, consent, review, and bounded authority. Keep raw secrets in the systems designed to hold them.\n\nBeginners can mistake structure for capability. A plugin folder looks official, a manifest looks architectural, and a detailed skill sounds operational. The inspection questions should stay simple:\n\nAdvanced users have the opposite problem. We know enough to create structure everywhere. We build skills for tone, agents for domains, hooks for habits, folders for memory, and plugins for workflows. Every layer solves a local pain. Together they can create global congestion.\n\nThe advanced skill is sometimes deletion.\n\nRetire stale guidance. Merge overlapping skills. Tighten triggers. Move long theory into documentation. Separate activation from execution. Keep active instructions short and attached to living tools.\n\nHere is the repair path I now use:\n\nThere is nothing anti-AI about this discipline. It is how we make agent power observable, reviewable, and maintainable.\n\nA real plugin does not need to be huge. It needs to tell the truth.\n\nIt should say what it can do, what it cannot do, what authority it needs, what evidence it returns, and how it fails. If the motor is only a scaffold, return `scaffold_only`\n\n. If an operation did not occur, do not let polished prose imply that it did.\n\nSkills matter. Plugins matter. MCP matters. But none of them become stronger when we blur their roles.\n\nBuild the motor. Break its bad inputs. Inspect the result. Protect the secret. Document the boundary. Keep the human responsible for the consequential decision.\n\nThat is less magical than promising a universal agent plugin. It is also far more powerful, because it works for real.\n\n**What is the smallest plugin motor you have built that produced evidence you could actually verify?**", "url": "https://wpnews.pro/news/real-plugins-need-motors-skills-should-teach-tools-not-pretend-to-be-them", "canonical_source": "https://dev.to/jsb-securedme/real-plugins-need-motors-skills-should-teach-tools-not-pretend-to-be-them-2oc1", "published_at": "2026-07-31 18:23:12+00:00", "updated_at": "2026-07-31 18:34:59.608159+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "developer-tools"], "entities": ["Codex", "Model Context Protocol", "MCP"], "alternates": {"html": "https://wpnews.pro/news/real-plugins-need-motors-skills-should-teach-tools-not-pretend-to-be-them", "markdown": "https://wpnews.pro/news/real-plugins-need-motors-skills-should-teach-tools-not-pretend-to-be-them.md", "text": "https://wpnews.pro/news/real-plugins-need-motors-skills-should-teach-tools-not-pretend-to-be-them.txt", "jsonld": "https://wpnews.pro/news/real-plugins-need-motors-skills-should-teach-tools-not-pretend-to-be-them.jsonld"}}