AgentPlaybooks

Get skill

get_skill

Read-onlyIdempotent

Retrieve a skill's full definition—SKILL.md, metadata, and attachment manifest—by playbook and skill ID; optionally include content or all attachment bodies for export.

Instructions

Return the full definition of one skill: SKILL.md content, metadata, and an attachment manifest with filenames and sizes. For only the manifest set include_content=false. Attachment bodies are omitted by default; read one with get_skill_reference, or set include_attachments=true for a complete export. skill_id accepts a UUID or kebab-case name. Declared demonstrations include resolved recording and segment links. Read-only. Use list_skills to discover IDs; list_skill_versions is historical data, not the current definition. Pass playbook_id as the UUID or GUID of the playbook this call should target.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "playbook_id": "<playbook_id>",
      "skill_id": "<skill_id>"
    },
    "name": "get_skill"
  }
}

Input Schema

Name	Required	Description
`skill_id`	Yes	Skill ID or name
`playbook_id`	Yes	UUID or GUID of the target playbook
`include_content`	No	Set false for metadata and attachment manifest only
`include_attachments`	No	Include every attachment body; prefer get_skill_reference for one file

Output Schema

Name	Required	Description	Default
`id`	No
`name`	No
`content`	No
`licence`	No
`priority`	No
`created_at`	No
`description`	No
`playbook_id`	No
`publisher_id`	No
`demonstrations`	No
`skill_attachments`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.1.4Oct 28, 2026

addedInput schema / properties / include_attachments

Added value: +{
+  "default": false,
+  "description": "Include every attachment body; prefer get_skill_reference for one file",
+  "type": "boolean"
+}

addedInput schema / properties / include_content

Added value: +{
+  "default": true,
+  "description": "Set false for metadata and attachment manifest only",
+  "type": "boolean"
+}

First observedv0.1.0Oct 15, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered; the description adds genuinely new behavior: attachment bodies are omitted by default, include_attachments produces a complete export, and demonstrations come back with resolved recording and segment links. The only weakness is that 'Read-only' restates the annotation and no guidance is given on size/rate implications of a full export.

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

Conciseness4/5

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

Front-loaded with the primary return payload, then the modifier flags, then the ID/discovery guidance, so the most important information comes first. Six sentences is dense but nearly all earn their place; only 'Read-only' (redundant with readOnlyHint) and the playbook_id restatement are filler.

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

Completeness5/5

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

An output schema exists, so return-value structure need not be explained, and the description still covers default omission of attachments, the full-export escape hatch, resolved demonstration links, and ID format flexibility. For a 4-parameter read with full schema coverage, nothing an agent needs to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics beyond the schema: skill_id accepts either a UUID or a kebab-case name, and playbook_id is the UUID/GUID of the target playbook. It also clarifies the intent of the two boolean flags (manifest-only vs. complete export) rather than just their defaults.

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?

States a specific verb and resource ('Return the full definition of one skill') and enumerates what that definition comprises: SKILL.md content, metadata, attachment manifest with filenames and sizes. It also explicitly distinguishes itself from list_skills, list_skill_versions, and get_skill_reference, so an agent can select it without reading sibling schemas.

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

Usage Guidelines5/5

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

Gives explicit conditions and alternatives: use include_content=false for manifest only, use get_skill_reference to read a single attachment body, use include_attachments=true for a full export, use list_skills to discover IDs, and notes list_skill_versions is historical rather than current. Every branch point an agent could hit is routed.

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

Deploy Server