Skip to main content
Glama

Create a theme

create_theme

On one site of the account, named in site. A new theme under its own name, started from a bundled or installed one (list_themes): a copy of that theme as last edited — held changes included — with its own history, and not the site's theme until activate_theme makes it so. The answer names the tree it copied and lists every file the copy inherited, so you know what to keep, rewrite or delete_theme_file. Names are lowercase letters, digits and hyphens. A copy of a bundled theme, or of a copy of one, follows that theme's releases (follows): list_themes shows its update, and plan_theme_update and update_theme bring it in over the copy's own changes.

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": {
      "site": "<site>",
      "name": "<name>",
      "from": "<from>"
    },
    "name": "create_theme"
  }
}

Input Schema

NameRequiredDescriptionDefault
fromYesThe theme to start from, like ink
nameYesThe new theme's name, like dune
siteYesThe site to work on, as list_sites names it

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior3/5

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

Given annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true and idempotentHint=false, the description adds real context: the copy includes held (unpublished) changes, gets its own history, does not become the live theme, and sticks to the source theme's release track when the source is bundled. That is meaningful beyond the annotations, but it doesn't say whether a name collision fails or overwrites, nor whether the source theme must be installed first. Solid add, with gaps on failure semantics for a non-idempotent mutation.

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

Conciseness3/5

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

Roughly 100 words for a three-parameter tool, loaded into two very long sentences with nested clauses and sentence fragments. Every claim has value, but the grammar ('A new theme under its own name, started from a bundled or installed one') forces re-reading, so it is not front-loaded cleanly.

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?

There is no output schema, yet the description explains the return value (names the copied tree and enumerates inherited files) and the downstream lifecycle (follows releases, update path). For a create-and-copy tool this covers what an agent needs to act and plan follow-up calls.

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 parameters are already documented, but the description adds value the schema lacks: the name's character constraint (lowercase letters, digits, hyphens) which is not encoded as a pattern, and the from semantics (bundled or installed theme, discovered via list_themes). The site parameter is only restated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: create a new theme on a named site, copied from a bundled or installed theme (pointing at list_themes as the source). It is distinguishable from build_theme, update_theme and activate_theme. The elliptical sentence fragments ('On one site of the account, named in site. A new theme under its own name...') make the core action slightly harder to parse than it needs to be.

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?

It clearly frames when this tool applies versus alternatives: the copy is not the site's theme until activate_theme makes it so, and it flags list_themes as the way to find a source and delete_theme_file for cleanup. It also explains the follow-releases case (list_themes update field, plan_theme_update, update_theme). It stops short of explicit 'use this instead of X when...' phrasing, but the routing is inferable and accurate.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources