PCD (Portable Context Deck)

Create PCD Skill

create_pcd_skill

Create a reusable working method when the user wants a procedure preserved for future use. Use update_pcd_skill to revise an existing method.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Skill name — lowercase, underscores/hyphens, max 48 chars. Unique per deck; if shared, unique across the container.
`action`	No	Default 'write'. 'validate': pre-send check — name format/cap (48), description shape, signal_emission — WITHOUT writing; returns { valid, missing_required[], over_cap: [{field, len, cap}], not_checked? }. Uniqueness and deck resolution still run at write time.
`shared`	No	If true, skill is visible to vertical neighbours at boot. Container-context shared → specialized-contexts inherit. Specialized-context shared → container-context inherits. Default false.
`contract`	No	Help mode — return the complete contract with no operation performed.
`deck_handle`	Yes	Handle of the deck this skill belongs to — must be a container-context or specialized-context deck
`description`	Yes	Structured metadata for indexing and LLM dispatch
`container_id`	Yes	Container ID
`raw_markdown`	No	Full instruction body the LLM reads when the skill is invoked. May reference declared resources via {{ref:Name}} syntax. Omit to create a stub.
`signal_emission`	No	Optional. Declares the signal this skill emits. The client AI fires write_signal at the declared point — run_pcd_skill surfaces it as an explicit emit_contract; the worker never auto-fires.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 7, 2026

changedInput schema / properties / description / properties / triggers / description

Previous value: -"PCD tool names this skill is relevant AFTER, e.g. [\"write_knowledge\"]. When a declared tool runs in this container, its response carries a one-line _meta.skill_hint naming this skill — so encoded method surfaces at the moment of use instead of being improvised past. Exact tool-name equality, no prose matching: when_to_use stays the human/AI-facing half, triggers is the mechanical half. Advisory only — never blocks, never auto-runs, fires once per skill in normal operation. Omit for no nudge (the default)."New value: +"PCD tool names this skill is relevant AFTER, e.g. [\"write_knowledge\"]. When a declared tool runs in this container, its response carries a one-line _meta.skill_hint naming this skill — so encoded method surfaces at the moment of use instead of being improvised past. Explicit operation identities preserve legacy declarations; consolidated umbrella names match their operation family. No prose matching: when_to_use stays the human/AI-facing half, triggers is the mechanical half. Advisory only — never blocks, never auto-runs, fires once per skill in normal operation. Omit for no nudge (the default)."

Changed3 schema fields changedSep 7, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

changedInput schema / properties / contract / description

Previous value: -"Help mode — pass true to receive this tool's full _meta.contract (all variants) with NO operation performed."New value: +"Help mode — return the complete contract with no operation performed."

addedInput schema / properties / description / properties / status

Added value: +{
+  "description": "Omit for active. Retired skills are hidden from discovery and hints; named reads return reference-only retirement guidance. Versioned with the description.",
+  "enum": [
+    "active",
+    "retired"
+  ],
+  "type": "string"
+}

First observedSep 7, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already establish that the tool is not read-only and not destructive, so the description does not need to restate that. The prose adds persistence-oriented framing ('preserved for future use') but does not surface the validate mode's no-write behavior, the contract help mode, or signal-emission semantics; those are left to the parameter schema. No contradiction with the annotations.

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 sentences, no filler: the first front-loads the purpose and the second handles the sibling distinction. Every clause earns its place.

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?

With nine parameters and several nested objects, this is a complex tool, but the schema descriptions are exhaustive and the annotations cover the safety profile. The remaining gap is that the prose does not summarize the special write/validate/contract modes or return behavior, which an agent only discovers by reading the parameter schema in full.

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 description coverage is 100%, so the structured schema carries the meaning of all nine parameters and nested objects. The prose adds no parameter-specific detail beyond the 'preserved method' framing, which maps loosely to raw_markdown/description but does not materially improve semantic understanding.

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?

The description opens with a specific action and object — 'Create a reusable working method' — and ties it to a concrete user intent: 'when the user wants a procedure preserved for future use.' It also distinguishes itself from the closest sibling by adding 'Use update_pcd_skill to revise an existing method,' so an agent can tell creation from revision at a glance.

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?

It gives an explicit trigger condition for using this tool ('when the user wants a procedure preserved for future use') and an explicit alternative for the overlapping case ('Use update_pcd_skill to revise an existing method'). This is sufficient routing guidance even without opening the schema.

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

All PCD (Portable Context Deck) tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?