Skip to main content
Glama
hybriden

Paperboy CMS

Official
by hybriden
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

update_type_template

Idempotent

Replace a stored type template's definition. Built-in templates are read-only (copy with create_type_template); existing content types need re-apply via instantiate_type_template.

Instructions

Replace a stored type template's definition (name and kind are immutable; built-in templates are read-only — copy one under a new name with create_type_template instead). Content types already instantiated from it are NOT changed; re-apply with instantiate_type_template {updateExisting:true}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesThe stored template's name.
siteNoSite slug or id to act in (multisite). Omit to use this server's default site. Call list_sites to see what exists — an empty tree or search usually means the wrong site, not missing content.
definitionYesThe full updated ContentTypeDef (same shape as create_content_type).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.3
    • addedInput schema / properties / definition / description
      Added value: +"The full updated ContentTypeDef (same shape as create_content_type)."
    • addedInput schema / properties / name / description
      Added value: +"The stored template's name."
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing that name and kind are immutable, that built-ins are read-only, and critically that already-instantiated content types are NOT changed. This downstream-effect warning is exactly the context that destructiveHint=false alone cannot convey, and it is consistent with that hint.

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, front-loaded with the action, then the immutability constraint and the downstream-effect guidance. Every clause (immutability, read-only built-ins, instantiated content) earns its place with no 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?

For a mutation tool with annotations present and no output schema, the definition covers the essential behavioral facts: what is replaced, what is immutable, what is unaffected downstream, and how to propagate. Nothing an agent needs to call it safely 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 description coverage is 100%, so the baseline is 3, but the description adds real semantic constraints: which fields are immutable and that definition is the full replacement ContentTypeDef. That meaningfully restricts how 'name' and 'definition' may be used beyond the schema's own text.

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: replacing a stored type template's definition. It immediately distinguishes itself from create_type_template (copying built-ins) and instantiate_type_template (re-applying to content), so an agent can route correctly without opening a 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?

Explicitly gives the when-not condition (built-in templates are read-only, copy instead via create_type_template) and names the follow-up alternative (instantiate_type_template {updateExisting:true}) for propagating changes. Both the exclusion and the chaining path are stated, not inferred.

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