Skip to main content
Glama

Get bundle

get_bundle
Read-onlyIdempotent

Returns one bundle's ordered steps: skill name, what each step takes in and hands on, and its web link. Full instructions for a step come from get_skill.

Input Schema

NameRequiredDescriptionDefault
idYesBundle id from list_bundles, e.g. standard-website

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add return-shape context, which it does: ordered steps with skill name, inputs/outputs, and links. Minor gaps remain around behavior for unknown bundle ids and whether any bundle-level metadata beyond steps is included.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences: the first front-loads what is returned and the shape of each step, the second handles the hand-off to get_skill. No filler, nothing redundant with the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read tool with no output schema, the description covers the return shape and the sibling hand-off well. It stops short of noting edge behavior (invalid/unknown id) or any bundle-level fields, which keeps it just below fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single id parameter is documented with a max length and an example ('standard-website' from list_bundles), so the schema carries the load. The description adds nothing about the id format or constraints beyond what the schema already states — baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb and resource ('Returns one bundle's ordered steps') plus a precise description of the payload: skill name, inputs/outputs per step, and web link. It also differentiates itself from get_skill by stating that full step instructions live there, so an agent can distinguish the two without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Full instructions for a step come from get_skill' explicitly routes the agent to the sibling for deeper detail, and the schema notes the id comes from list_bundles. However, there is no statement of when this tool is preferable to alternatives (e.g., list_skills or search_skills) or any exclusion condition.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.