Skip to main content
Glama

Update Article

update_article

Edit an article's text: title, slug (drafts only), teaser, featured snippet, markdown body, FAQs, meta title/description or featured image alt. Only the fields you send change; HTML, SEO score and AI-phrase flags are recomputed as in the editor. Pass get_article's contentFingerprint as baseFingerprint to refuse the write if the article changed meanwhile. Hosted Next.js blogs serve the edit automatically; for other CMSs call publish_article again when republishNeeded is true. (requires an agent API key)

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": {
      "articleId": "<articleId>"
    },
    "name": "update_article"
  }
}

Input Schema

NameRequiredDescriptionDefault
faqsNoThe full FAQ list (replaces it)
slugNoOnly for unpublished articles
titleNo
teaserNo
articleIdYes
metaTitleNo
baseFingerprintNocontentFingerprint from get_article; the edit is refused if the article changed since
contentMarkdownNoThe full markdown body (replaces it)
featuredSnippetNo
metaDescriptionNo
featuredImageAltNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare write/non-destructive; the description adds substantial context beyond them: partial-update semantics, that HTML/SEO score/AI-phrase flags are recomputed, that the write is refused on fingerprint mismatch, that hosted Next.js blogs serve edits automatically while other CMSs need a republish, and that an agent API key is required. That is exactly the operational knowledge an agent needs before mutating content.

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 editable field list, then behavior, then concurrency, then CMS-specific follow-up — a logical agent-friendly order. Dense parentheticals ('drafts only', 'requires an agent API key') cost some readability, but no sentence is filler.

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 an 11-parameter mutation tool with no output schema, it covers permissions (agent API key), side effects (recomputed HTML/SEO/flags), concurrency protection, and post-write follow-up. It does not describe what the response contains beyond the implied republishNeeded flag, which is the one remaining gap.

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 only 36%, but the description compensates by naming every editable field and adds constraints the schema only gestures at, e.g. slug is for drafts/unpublished articles only. It also clarifies the partial-vs-full distinction (only sent fields change, while body and FAQs replace wholesale), which the schema conveys only via terse '(replaces it)' notes. baseFingerprint's meaning is restated rather than extended, so not a full 5.

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 specific verb+resource ('Edit an article's text') and enumerates exactly which fields are editable, so an agent can distinguish it from generate_article (creation), publish_article (publishing) and get_article (reads) without opening the schema. The scope statement 'Only the fields you send change' further pins down the semantics of the operation.

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?

Gives concrete routing instructions: pull contentFingerprint from get_article and pass it as baseFingerprint for optimistic concurrency, and call publish_article again on non-Next.js CMSs when republishNeeded is true — both name the sibling tool and the condition that triggers it. It does not state when NOT to use this tool (e.g., new articles or draft creation), which keeps it 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources