Yesterday was listening to an interview with Pi.dev creator, a " minimal terminal coding harness" that doesn't support MCP but 'Skills' and 'Extensions'. The three - MCP, Skills and Extensions start to blur for me....
The five dimensions are clean but honestly the decision most teams actually struggle with isnt understanding the difference. Its knowing when the overhead of MCP is justified vs when a skill file does the job for a fraction of the complexity.
The rule of thumb that seems to work in practice is: if the data changes between invocations, you need MCP because the agent needs live access. If the knowledge is stable enough that you could write it down once and have it be right for weeks, a skill file is simpler, cheaper, and doesnt require a separate runtime that can fail independently of the agent.
The interesting edge case is when you need both. A skill that tells the agent how to think about a problem, combined with an MCP connection that gives it live data to think about. Thats where most production setups end up eventually and almost nobody designs for it from the start. They bolt on whichever one they didnt pick first and wonder why the architecture feels messy.
Framework is useful, but the hidden cost nobody mentions is debugging surface area — every MCP server is a separate process with its own logs and auth. My rule of thumb: start with a skill, only graduate to MCP when you actually need live state or an external runtime.
Just a clear definition/comparison I needed.
Yesterday was listening to an interview with Pi.dev creator, a " minimal terminal coding harness" that doesn't support MCP but 'Skills' and 'Extensions'. The three - MCP, Skills and Extensions start to blur for me....
The five dimensions are clean but honestly the decision most teams actually struggle with isnt understanding the difference. Its knowing when the overhead of MCP is justified vs when a skill file does the job for a fraction of the complexity.
The rule of thumb that seems to work in practice is: if the data changes between invocations, you need MCP because the agent needs live access. If the knowledge is stable enough that you could write it down once and have it be right for weeks, a skill file is simpler, cheaper, and doesnt require a separate runtime that can fail independently of the agent.
The interesting edge case is when you need both. A skill that tells the agent how to think about a problem, combined with an MCP connection that gives it live data to think about. Thats where most production setups end up eventually and almost nobody designs for it from the start. They bolt on whichever one they didnt pick first and wonder why the architecture feels messy.
Super helpful!
Framework is useful, but the hidden cost nobody mentions is debugging surface area — every MCP server is a separate process with its own logs and auth. My rule of thumb: start with a skill, only graduate to MCP when you actually need live state or an external runtime.
really clear explanation. love it.
Rightful comparison could have been among steering, hooks and skills.