Skip to main content
Glama

Rename entry or change its slug

update_entry
Destructive

Update a collection entry's metadata only (name and/or slug). Partial update: provided fields are changed, omitted fields are preserved. This does NOT change the entry's content fields (use save_entry_content for those; the built-in name and slug keys are refused there). A slug must be lowercase letters, numbers and hyphens, and free in the collection. For an entry with a page the new slug is a PENDING address (get_entry shows it as draftSlug): the page keeps its current address until the next publish_entry, which moves it and, by default, redirects the old address. Passing the current address back cancels the pending move. For an entry without a page the slug changes immediately. On a collection whose name and slug are the built-in types, the name is live data: listings on the published site show a new name without a publish. An older collection may keep them as plain text fields inside content, which is what its listings show; when that copy still matches the old value it is updated too, in the draft, so listings show it after the next publish_entry (the result says so in contentCopy). A copy that differs is left alone and the result says to change it with save_entry_content.

Input Schema

NameRequiredDescriptionDefault
nameNoUpdated entry name
slugNoUpdated URL slug (lowercase letters, numbers and hyphens). Pending until publish when the entry has a page.
entryIdYesThe entry ID
projectIdYesThe project ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say destructive/openWorld/not-readOnly; the description adds far more: partial-update preservation, pending slug behavior for paginated entries, redirect-by-default on publish, cancellation of pending moves by passing the current address, immediate slug change for entries without pages, and the two collection types (built-in vs text copy) with contentCopy reporting. These are non-obvious behavioral consequences beyond structured fields.

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?

Purpose and the key exclusion (save_entry_content) are front-loaded. The single dense paragraph is verbose—particularly the older-collection contentCopy nuance—and could be bulleted for scanability, but nearly every sentence carries necessary state/behavior 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 mutation tool with no output schema and 100% param coverage, the description fills the remaining behavioral gaps (pending vs immediate slug, redirects, contentCopy result field, collection-type differences). An agent has what it needs to call and interpret the result.

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 schema already defines all four parameters and even notes the slug pending behavior. The description nonetheless adds non-obvious semantics—passing the current address cancels a pending move, and name behaves as live data on built-in collections while being draft-content on older ones. This adds meaning beyond the schema, though some of it overlaps what the schema describes.

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?

The description opens with a specific verb and resource: 'Update a collection entry's metadata only (name and/or slug).' It immediately carves out the boundary against save_entry_content ('This does NOT change the entry's content fields'). An agent can identify the tool's scope without inspecting siblings.

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?

It explicitly names the alternative for content edits ('use save_entry_content for those; the built-in name and slug keys are refused there') and states the separate publish_entry step required for slug changes. Use vs. use-not conditions are both provided, satisfying the top criteria.

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.