easysociable-mcp

Create authoring draft

create_template_draft

Initialize a Page Template draft to author custom slide layouts, layers, and slot contracts. Returns a draftId and authoringStudioUrl for real-time visual canvas editing.

Instructions

Initialize a new Page Template draft for authoring with custom layout, layers, and slot contracts. Use when authoring a new slide template from scratch. Do NOT use to edit an existing draft (use update_template_draft) or browse public templates (use list_templates). Requires workspace owner authorization. Returns created TemplateDraft record with draftId and interactive authoringStudioUrl for real-time visual canvas editing.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Human-readable title for the template draft.
`theme`	No	Default theme overrides (palette, typography tokens).
`source`	No	Optional initial canvas source tree.
`authoringSource`	No	Template AST structure including layer hierarchy and visual slots.
`selectionMetadata`	No	Aspect ratio and categorization metadata (platforms, layout family, intent).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	No	Unique draft ID.
`authoringStudioUrl`	No	Direct browser link to Studio visual canvas editor.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.17Oct 5, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "authoringStudioUrl": {
+      "description": "Direct browser link to Studio visual canvas editor.",
+      "type": "string"
+    },
+    "id": {
+      "description": "Unique draft ID.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changed5 schema fields changedv0.1.16Oct 5, 2026

addedInput schema / properties / authoringSource / description

Added value: +"Template AST structure including layer hierarchy and visual slots."

addedInput schema / properties / name / description

Added value: +"Human-readable title for the template draft."

addedInput schema / properties / selectionMetadata / description

Added value: +"Aspect ratio and categorization metadata (platforms, layout family, intent)."

addedInput schema / properties / source / description

Added value: +"Optional initial canvas source tree."

addedInput schema / properties / theme / description

Added value: +"Default theme overrides (palette, typography tokens)."

First observedv0.1.13Oct 5, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), so the description only needs to add context. It does: 'Requires workspace owner authorization' is a real precondition not present in structured fields, and it discloses the created record shape and the interactive authoringStudioUrl side effect. It does not, however, note the non-idempotent duplicate-creation behavior beyond what the annotation implies.

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?

Four sentences ordered purpose → usage → exclusions → auth → return, each carrying distinct information with no repetition. Nothing is padded and the purpose is front-loaded.

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?

For a non-idempotent creation tool with nested object params, full schema coverage, and an output schema, the description covers the missing pieces: the authorization requirement and the side effect of producing an authoring URL. An agent has everything needed to invoke it correctly.

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 schema already documents all five parameters. The description only loosely gestures at them ('custom layout, layers, and slot contracts') and adds no format or syntax guidance beyond what the schema provides. Baseline 3 applies.

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+resource ('Initialize a new Page Template draft for authoring') and scopes it with the concrete features (custom layout, layers, slot contracts). It explicitly distinguishes itself from update_template_draft and list_templates, so an agent can route correctly without opening any schema.

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 an explicit trigger ('when authoring a new slide template from scratch') plus two named exclusions with the sibling to use instead ('Do NOT use to edit... use update_template_draft', 'browse public templates... use list_templates'). This is the full when/when-not/alternative pattern.

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