Download a free AI agent blueprint by ID. Returns a JSON manifest with all files (SKILL.md, reference docs, implementation guide) ready to write to disk. Same format as the paid Agent Blueprint export.
| Name | Required | Description | Default |
|---|---|---|---|
| blueprintId | Yes | Blueprint ID from list_blueprints |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns a JSON manifest (not a direct file download) and specifies the contents (SKILL.md, reference docs, implementation guide). It also notes the format matches the paid export, which is useful context. It doesn't mention auth or side effects, but for a read-style download tool this is reasonably transparent.
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?
Two sentences, front-loaded with the action and resource, followed by necessary details about the return format and comparison to the paid export. Every word earns its place, no filler.
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?
With a single parameter, no output schema, and a clear sibling, the description fully covers what the tool does and what it returns. The explanation of the JSON manifest contents and the note about the paid export provide sufficient context for an agent to use the tool correctly.
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?
Schema coverage is 100%, and the parameter description already states 'Blueprint ID from list_blueprints'. The tool description adds only 'by ID', which does not meaningfully enhance the semantic understanding beyond what the schema provides. 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 uses a specific verb ('Download') with a clear resource ('free AI agent blueprint by ID'), and explicitly distinguishes itself from the sibling tool list_blueprints by focusing on retrieval rather than listing. The mention of the JSON manifest further clarifies what the tool actually does.
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 clearly implies the tool is used after list_blueprints to obtain a specific blueprint, and the parameter description references 'Blueprint ID from list_blueprints'. However, it does not explicitly state when not to use it or name an alternative, which keeps it from a 5.
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.
The two tools are clearly distinct: one lists available blueprints, the other retrieves a specific blueprint by ID. There is no overlap in purpose.
Both tool names follow a consistent verb_noun pattern (list_blueprints, get_blueprint), making the API predictable and easy to understand.
With only two tools, the server is slightly under the typical well-scoped range, but the scope (listing and retrieving free blueprints) is narrow enough that two tools feel reasonable.
For a catalog of static blueprints, listing and downloading are the essential operations. There are no obvious missing actions like update or delete, as blueprints are read-only resources.