Skip to main content
Glama

Scaffold a classic theme

create_classic_theme

Generate a classic PHP theme with Tailwind utility classes to produce readable, diffable templates and reusable design tokens, delivered as a draft.

Instructions

Scaffold a complete classic PHP theme styled with Tailwind, as a draft. Classic templates with utility classes are far more reliable to generate and to review than nested block markup — the output is readable, diffable and predictable. The scaffold includes style.css, functions.php, header/footer, index, single, page, archive, 404, search, comments, a theme.css holding the design tokens (colors, fonts, radii) that every template reuses, and a Tailwind CDN setup wired to those tokens.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesTheme display name, e.g. "Northwind".
slugNoTheme directory name. Derived from the name if omitted.
authorNoAuthor name written into the style.css header.wpxmcp
tokensNoDesign tokens written into theme.css as CSS custom properties and reused across every template.
site_idNoWhich configured WordPress site to act on. Optional — with a single site configured it is used automatically; with several, the default site is used unless you name one. Run list_sites for valid ids.
as_draftNoCreate it as an editable draft rather than a directly installed theme. Keep true.
descriptionNoTheme description for style.css.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv2.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / author / description
      Previous value: -"User ID of the author."New value: +"Author name written into the style.css header."
    • removedInput schema / properties / tokens / additionalProperties
      Removed value: -false
  2. First observedv1.0.0

TDQS

A4.1/5.0
Behavior4/5

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

Beyond the generic annotations (readOnly=false, destructive=false), the description discloses that the theme is created as a draft and enumerates the exact files generated, including style.css, functions.php, templates, theme.css, and Tailwind CDN setup. It does not mention return values or post-creation publication steps, but the safety profile is already covered by 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?

The description is dense and well-structured: a one-sentence summary, a brief rationale, then a concrete list of generated files. Every sentence earns its place with no filler or repetition.

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

Completeness3/5

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

The description covers what the tool creates and the draft nature, but with no output schema it does not explain what the tool returns or how to follow up (e.g., publishing or activating the draft). The rich input schema compensates for invocation clarity, but the missing return/post-condition information leaves a gap for chaining operations.

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 every parameter including the nested token object has individual descriptions. The tool description itself only adds the context that tokens are written into theme.css as CSS custom properties, which is useful but not necessary for understanding the parameters.

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 verb and resource: 'Scaffold a complete classic PHP theme styled with Tailwind, as a draft.' It clearly differentiates this from block-based theme creation by emphasizing classic templates with utility classes versus nested block markup, which is useful against siblings like create_draft_theme.

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?

The description gives clear context for when to choose classic templates over block markup, calling the output 'readable, diffable and predictable.' It does not explicitly name alternative sibling tools such as create_draft_theme or state when not to use this tool, so it falls just short of a 5.

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

Deploy Server

Other Tools