help(): The Missing MCP Primitive

The biggest draw of MCP is its universal adoption. At this point in time, any agent will let you plug in MCP servers, so if you want to expose your application or library to agents, MCP is a natural choice, and you can add an MCP server to your agent of choice with a config of half a dozen lines, or a one-line command.

However, all MCP exposes is a collection of tools, with schemas and descriptions. What if the value of your application is only fully realized by non-trivial workflows that call multiple tools in a particular sequence?

The natural answer to this is skills. Skills are basically prompt chunks that do exactly that, describe complex workflows that show how to use your tools together to achieve complex goals. But skills, unlike MCP, aren’t really a standard. How do you distribute them, along with the MCP server, to minimize the installation friction?

Worst option: stuff the skills into your tool descriptions. This will make them available to anyone who connected to your MCP server all right, but they won’t thank you for it. The reason is that this will eat into their context window, before they have used a single tool.

Next option is to frame them formally as skills. This allows you to leverage for example skills.sh to distribute them to different agents, but that doesn’t answer the question of how to bundle the MCP server along with them, so your potential user will have to install the two separately, a horrible experience.

There is the “plugin” format by Anthropic, which allows you to distribute skills and MCP server configs together as a zip file (or a repo with a particular folder structure), but it’s Anthropic-only; and even then, while you can just drag and drop .mcpb files, installing a plugin requires a series of far-from-obvious clicks in Claude Cowork.

So what do you do? In SLayer, we’ve taken inspiration in CLI interfaces, and added a help() tool to the MCP server. Calling it without arguments gives basic instructions and the list of other available pages, which the agent can then retrieve if it needs them.

This gives us the best of both worlds, the MCP server is the only thing that needs setting up, it doesn’t spam the context, yet makes all the skill information available when needed.

Did you run into this problem? Did you find a better way to solve it?