Skip to main content
Glama

Create Content

create_content

Create a new content item from a template, specifying required fields like title, slug, and data, then publish it live.

Instructions

Create a new content item. Requires a template_id, title, slug, and the data fields defined by the template.

Workflow:

  1. Call list_templates to find the right template and its field names.

  2. Create the content with data matching those fields.

  3. Call publish_content to make it live (or set published=true here to do both in one step).

Set use_header=true, use_footer=true, use_theme=true for pages that should use the site layout. Always include version_comment to make history readable.

Content data fields support rich markup features:

  • [[Wikilinks]] and [[Page Title|display text]] — link to other pages by title or path; auto-update when paths change

  • [[include:snippet-name]] — embed a named snippet inline (reusable callouts, CTAs, disclaimers)

  • #hashtags — mention #tagname anywhere to automatically tag the page

  • Markdown fields (type "markdown") — GitHub Flavored Markdown converted to HTML at publish time Templates can use {{.lc_toc}} in their HTML layout to inject an auto-generated table of contents.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesTemplate field values,required
holdNoPut the page on hold: it cannot be published (directly, in bulk, on a schedule or by merging a fork) until hold is cleared. Cannot be combined with published=true
slugYesURL slug for the content,required
tagsNoTags for lc:query index pages (e.g. ['AI & Machine Intelligence', 'Generative AI'])
titleYesContent title,required
upsertNoIf true, update existing content at the same path instead of returning a duplicate key error
noindexNoHide this page from search engines and AI (noindex; excluded from sitemap, llms.txt, feeds, IndexNow)
categoryNoContent category for collections
og_imageNoOpen Graph image URL
raw_modeNoUse raw HTML mode
publishedNoPublish immediately
use_themeNoApply site theme/layout
author_urlNoAuthor profile URL
use_footerNoInclude site footer
use_headerNoInclude site header
author_nameNoAuthor name for structured data and feeds (defaults to the site author)
folder_pathNoFolder path (e.g., /blog)
template_idYesTemplate ID (MongoDB ObjectID),required
version_commentNoOptional comment describing this version
meta_descriptionNoSEO meta description

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv7.3.4
    • addedInput schema / properties / author_name
      Added value: +{
      +  "description": "Author name for structured data and feeds (defaults to the site author)",
      +  "type": "string"
      +}
    • addedInput schema / properties / author_url
      Added value: +{
      +  "description": "Author profile URL",
      +  "type": "string"
      +}
    • addedInput schema / properties / hold
      Added value: +{
      +  "description": "Put the page on hold: it cannot be published (directly, in bulk, on a schedule or by merging a fork) until hold is cleared. Cannot be combined with published=true",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / noindex
      Added value: +{
      +  "description": "Hide this page from search engines and AI (noindex; excluded from sitemap, llms.txt, feeds, IndexNow)",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / upsert
      Added value: +{
      +  "description": "If true, update existing content at the same path instead of returning a duplicate key error",
      +  "type": "boolean"
      +}
  2. First observedv4.2.0

TDQS

A4/5.0
Behavior4/5

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

Annotations only declare openWorldHint=false and destructiveHint=false; the description adds substantial behavioral context beyond them, including publish-time Markdown conversion, wikilink auto-updating on path changes, snippet inclusion, hashtag-based tagging, and {{.lc_toc}} injection. It omits permission/auth requirements and side effects like index/feed regeneration, so it is strong but not complete.

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

Conciseness4/5

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

Front-loaded with the core action and required inputs, then a numbered workflow, then flag guidance. The bulleted markup feature list is longer than strictly necessary for tool selection, but each item describes how the data parameter is interpreted, so it is largely load-bearing.

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?

For a 20-parameter create tool with full schema coverage and no output schema, the description covers the required flow, layout flags, and content-data conventions. It is silent on several optional params (hold, upsert, noindex, og_image, folder_path) and on duplicate-slug failure behavior, but the schema carries those.

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 the baseline is 3, but the description adds real meaning: it explains that data must match template field names (discoverable via list_templates), that use_header/use_footer/use_theme apply the site layout, that version_comment should always be set for readable history, and that published=true overlaps with publish_content.

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?

States a specific verb and resource ('Create a new content item') and immediately names the required inputs, so it is clearly separable from create_template, create_collection, and create_snippet. It does not explicitly distinguish itself from single-item vs. bulk creation (bulk_create_content) or import paths, which keeps it below a 5.

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?

Provides an explicit three-step workflow (list_templates -> create -> publish_content) and states the alternative condition for combining steps with published=true. It does not say when NOT to use this tool (e.g., for many items use bulk_create_content, or for edits use update_content), so guidance is clear but not exhaustive.

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