Skip to main content
Glama

Update Space

update_space

Change a wiki space's name, slug, or description; updating the slug also changes the space's URLs. Requires admin rights in that space.

Instructions

Change a space's name, slug or description. Changing the slug changes the space's URLs. Needs admin rights in the space.

Input Schema

NameRequiredDescriptionDefault
nameNoNew name; left out keeps it.
slugNoNew short name for URLs, letters and digits; left out keeps it.
space_idYesSpace id from list_spaces.
descriptionNoShort description.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations cover the safety profile (not read-only, not destructive, closed-world). The description adds context beyond that: the operation is scoped to a single space, needs admin rights, and the slug change has a downstream effect on URLs. It does not mention whether omitted fields are preserved (the schema does) or what happens to existing links after a slug change.

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?

Three short sentences, front-loaded with the operation, followed by the highest-risk side effect and the permission requirement. No 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?

Output schema exists so return values need no explanation, and the description covers scope, permission, and the main side effect for a mutation tool. Gaps are minor: link-breakage behavior on slug change and whether the change is reversible/audited.

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 fields are already documented; the description still adds value by flagging the URL consequence of slug edits, which the schema pattern constraint does not convey. It does not clarify that omitting a field leaves it unchanged, but that is covered in the schema defaults.

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 (change) and resource (space) plus the exact fields affected (name, slug, description), which cleanly separates it from create_space or page-level update tools. It stops short of explicitly naming the sibling that handles membership or page edits, but the operation itself is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The requirement of admin rights in the space is a useful precondition, but there is no statement of when to choose this over alternatives (e.g. create_space for new spaces, move_page_to_space for relocating content) or when not to call it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.