Skip to main content
Glama

update_content

DestructiveIdempotent

Updates an existing content document (by content_id) in place. Use it to revise a document rather than creating a new one; Marcora keeps a full version history and the user can revert any change from the app. Only the fields you supply change, and at least one must be supplied.

Fields: content (markdown body), name_override, stage, visibility, category_id, project_id, plus change_summary.

content REPLACES the entire body verbatim (there is no patch mode), and this tool consults no Brand Foundation or Reference Library. So when you write or rewrite the body: call get_content to read the current body AND get_relevant_context with include_brand_foundation: true, then send the FULL new body. Skip both when you only change non-body fields.

Side effects to know:

  • stage: "ready" on a document linked to a plan also moves the plan to Complete.

  • name_override locks a custom name permanently; this tool cannot unlock it. Without it, the name follows the first heading.

  • project_id replaces the document's single project association (no way to remove it from all projects here).

  • visibility "team" → "private" revokes team-wide access on the next read.

Pass change_summary on every call: what you changed and why, as skimmable markdown (one line for a small edit; a short bulleted list for several). It is shown in the document's history sidebar.

Needs write access: a non-viewer team member who created the document, or the document is team-visible.

Present link_url exactly as returned.

Name behavior: by default a document's name auto-syncs from the first markdown header in its body. Set name_override to lock a custom name; once locked, the title stays even when the body is edited. Omit name_override to leave the lock state as-is.

Stage: in_progress or ready. Setting stage writes both the stage enum and the is_ready bool in lockstep. The plan side effect on ready is non-blocking on failure.

Visibility: private (only the creator and project members can see it) or team (anyone on the team).

Category: category_id from list_content_categories. Works for all content documents. A category from another team errors.

Project association: if the document is already in a different project, the old association is replaced; if it is already in the supplied project, this is a no-op. Omit project_id to leave the association untouched. Use the Marcora app to remove a document from all projects.

Change summary format: a single line for one small edit (e.g. "Tightened the closing CTA"); for several distinct edits, a short bulleted list where each bullet is a bold 2–5 word lead, a colon, then the detail. Match length to substance. Blank/omitted logs a generic "Content updated via MCP." and the history becomes useless after a few edits.

Authorization: you must be a non-viewer member of the team that owns the document, AND either (a) you created the document, or (b) the document is team-visible. Foreign-team or insufficient-role calls return access denied.

Errors:

  • notfound: content_id doesn't match any content document.

  • inputerror: no mutable field supplied; invalid category_id; invalid project_id; the document is a non-editable document type (e.g. a context-item editor document).

  • accessdenied: you don't have write access to the document.

Links: copy link_url character for character. Never retype, shorten, or rebuild a link or the IDs inside it.

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": {
      "content_id": "<content_id>"
    },
    "name": "update_content"
  }
}

Input Schema

NameRequiredDescriptionDefault
stageNoMark the document in-progress or ready. Omit to leave stage unchanged.
contentNoNew full markdown body. Omit to leave body unchanged. Read existing via get_content first if splicing edits.
content_idYesUUID of the content to update. Get from list_content, get_content, get_generation_status, or get_project.
project_idNoProject UUID to set as this document's project. Replaces any existing project association. Omit to leave project unchanged.
visibilityNoDocument visibility. Omit to leave unchanged.
category_idNoCategory ID from list_content_categories. Omit to leave unchanged.
name_overrideNoCustom document name. Setting this locks the name (won't auto-resync from content header on future edits). Omit unless overriding the auto-derived title.
change_summaryNoWhat changed and why, for the doc's AI-assistant history. Format as skimmable markdown — a bulleted list (bold lead + detail) for multi-part edits.
confirm_private_sourcesNoPass only after the user agrees. A write that would put Only me material this session read into a team-visible document is refused with a confirmation token; repeat the same call with that token here only once the user has said yes. The token releases only the items it names, for that document only, and expires in 5 minutes. Once released, those items stay released for that document, so later writes there will not ask again.

Output Schema

NameRequiredDescriptionDefault
nameYesDocument name (computed from name_override + has_custom_name + content header).
stageNoEnum: in_progress or ready.
contentYesFull document content in markdown.
categoryNoContent category, or null if not categorized.
link_urlNoDirect URL to view this content in Marcora.
content_idYesContent identifier.
visibilityNoEnum: private or team.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / confirm_private_sources / description
      Previous value: -"Pass only after the user agrees. A write that would put Only me material this session read into a team-visible document is refused with a confirmation token; repeat the same call with that token here only once the user has said yes. The token releases only the items it names, for that document and that one write, and expires in 5 minutes."New value: +"Pass only after the user agrees. A write that would put Only me material this session read into a team-visible document is refused with a confirmation token; repeat the same call with that token here only once the user has said yes. The token releases only the items it names, for that document only, and expires in 5 minutes. Once released, those items stay released for that document, so later writes there will not ask again."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Far exceeds the annotations: discloses version history/revertability, the stage:ready → plan Complete side effect and its non-blocking failure mode, that name_override is a permanent lock, that visibility team→private revokes access, and the full write-authorization rule. It also defines the confirm_private_sources token lifecycle (5-minute expiry, per-document release), which no structured field conveys.

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?

Front-loaded and well-sectioned, but redundant: name_override locking is explained in both the side-effects bullets and the dedicated 'Name behavior' paragraph, and the write-authorization rule appears twice ("Needs write access" and "Authorization"). The duplication costs space without adding information.

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 9-parameter destructive mutation with an output schema, it covers everything an agent needs: partial-update contract, side effects, authorization, per-error-code meanings, and the confirm_private_sources flow. No material gap remains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the 3 baseline is exceeded by real added meaning: content REPLACES the body verbatim with no patch mode, stage writes the enum and is_ready in lockstep, name_override locks permanently and omitting it preserves lock state, and cross-team category_id errors. This is semantics the schema alone does not supply.

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?

Opens with a precise verb+resource+identifier: "Updates an existing content document (by `content_id`) in place." It also explicitly contrasts with create_content ("revise a document rather than creating a new one"), so an agent can distinguish it from the sibling without opening either 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 explicit routing rules: call get_content and get_relevant_context with include_brand_foundation before rewriting the body, skip both for non-body edits, and use the Marcora app (not this tool) to remove a document from all projects. When-not-to-use and alternatives are both named.

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