Fetch every SKILL.md in one bundle, in a single call. Write each returned skill to .claude/skills//SKILL.md (or the equivalent for the user's agent) and the whole set is installed — no other step is needed. Get the slug from list_bundles.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The bundle slug from list_bundles, e.g. 'bundle:competitor-research'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns SKILL.md files and instructs the agent to write them to disk, which is a helpful behavioral guideline. However, it does not mention whether the fetch is read-only, how errors are handled, or the exact response format, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every clause serves a purpose—fetching, writing, and installing. There is zero redundancy or filler, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one required parameter, no output schema), and the description covers the main flow: fetch, write, install. It gives the installation path and mentions the slug source, which is sufficient for the tool's complexity. It could be more explicit about the return structure, but for a bulk fetch it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the slug parameter with an example ('bundle:competitor-research') at 100% coverage. The description adds slight context by pointing to list_bundles as the source of the slug, but does not add substantial meaning beyond the schema, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Fetch every SKILL.md in one bundle, in a single call', which uses a specific verb (fetch) and resource (bundle of SKILL.md files). It clearly distinguishes from siblings like get_skill (single skill) and list_bundles (lists bundles) by framing this as a bulk fetch operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage flow: get the slug from list_bundles, then call this to fetch and install all skills, noting 'no other step is needed'. It implies when to use (when you want the whole bundle) but does not explicitly contrast with alternatives like get_skill for individual skills, so it lacks an explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Tools are mostly distinct: get_bundle vs get_skill differ by granularity, list_bundles/list_categories/list_models list different entity types, and search_skills is the discovery tool. Minor overlap exists between list_bundles and list_categories as both support browsing, but descriptions clarify their purposes.
All tool names follow a consistent verb_noun snake_case pattern: get_* for fetches, list_* for enumerations, and search_* for querying. The naming is uniform and predictable.
Six tools is well-scoped for a skills catalog server. Each tool serves a clear purpose in the discovery/installation workflow, and the count is within the ideal range.
The tool surface covers the core workflow: search, browse categories/bundles, and fetch content for installation. A minor gap is the lack of a direct 'list all skills' endpoint, but categories and search compensate adequately.
