Skip to main content
Glama

Take site or page offline

unpublish
DestructiveIdempotent

Take the whole site offline (its address 404s for visitors), or with page_slug just one page. Drafts are kept, so it can be published again. This changes what visitors see — only when the owner explicitly asks to take something down, and never to make room for another site's publish.

Input Schema

NameRequiredDescriptionDefault
localeNoLocale of the page variant. Defaults to 'en'.
site_idYes
page_slugNoTake ONLY this page offline (e.g. '/about'): its live URL 404s and it leaves the menu, its draft is kept, the rest of the site stays live. Omit to take the WHOLE site offline.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds genuinely new behavioral facts beyond them: visitor-facing 404 on the address, page leaves the menu, the rest of the site stays live, and drafts are retained for republishing. It doesn't discuss permission/auth requirements or how to undo (the undo sibling exists), which keeps it from a 5.

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 tight sentences, each earning its place: scope, reversibility, then the guardrail on when to use it. The core scope is front-loaded and nothing is padding.

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?

No output schema exists, and annotations carry the safety profile (destructive, idempotent, open-world). The description supplies the visitor-facing effect, reversibility, and the usage guardrail, so an agent has everything needed to call it correctly.

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 67% and the schema's own page_slug description is rich. The description nonetheless adds the key semantic split (page_slug = one page, omit = whole site) in its own words, reinforcing correct invocation. The locale parameter is left entirely to the schema, preventing full credit.

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?

Specific verb+resource+scope: 'Take the whole site offline... or with page_slug just one page.' An agent can instantly distinguish this from delete_site/delete_page because the description says drafts are kept and it can be published again. No ambiguity about what is being taken offline.

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?

Explicit when and when-not: only when the owner explicitly asks to take something down, and 'never to make room for another site's publish.' That exclusion is valuable routing guidance. It stops short of naming the alternative tool (e.g. delete_site vs unpublish) explicitly, so not quite 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