Skip to main content
Glama

Publish or unpublish a page

publish_page
DestructiveIdempotent

Put a page on the open web and get a link the user can send to someone, or take it back down by passing publish: false. With access: "passcode" the link opens only for somebody who also types the passcode this returns - use it whenever the user wants the page shared but not open to anyone who finds the link. A connected app can only do this for pages it wrote itself; a page the user made in the app has to be published by them. Published pages are not indexed by search engines unless their owner separately allows it in the app, and taking a page down clears that consent rather than remembering it.

Input Schema

NameRequiredDescriptionDefault
accessNoOptional. "passcode" puts the page on the web behind a six-character passcode, returned in the result, which the user sends along with the link. "anyone" opens it to anyone with the link. Omit to keep the page at the level it has - a page behind a passcode is never opened up unless you send "anyone", and only do that when the user asks.
projectNoThe repository or project this artifact belongs to, such as the repository's name. Send the same one every time. A key is unique within its project, and a new page is filed in the project's own folder. Leave it out only for work that belongs to no project.
publishYesTrue puts it on the web, false takes it down.
documentIdNoThe page to publish or unpublish.
externalIdNoThe key the page was filed under, if you do not have its id.
newPasscodeNoOptional. True replaces the passcode with a new one, so the old one stops working everywhere. Only for a page behind a passcode.

Output Schema

NameRequiredDescriptionDefault
urlYesWhere the owner reads it, signed in.
iconNoThe emoji beside the title.
coverNoThe banner across the top of the page, by name. "uploaded" when it is a picture the owner put there.
titleYes
accessNoWho can open the shareable link: anyone who has it, or only somebody who also has the passcode.
createdNo
passcodeNoThe passcode the link needs, when access is passcode. Give it to the user exactly as written, alongside the link.
warningsNo
publicUrlNoThe shareable link, when the page is published.
documentIdYes
isPublishedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / project
      Added value: +{
      +  "description": "The repository or project this artifact belongs to, such as the repository's name. Send the same one every time. A key is unique within its project, and a new page is filed in the project's own folder. Leave it out only for work that belongs to no project.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing that unpublishing clears search-index consent rather than remembering it, that published pages are not indexed unless the owner separately allows it, and that the passcode is returned in the result. These are real behavioral consequences an agent could not infer from destructiveHint/openWorldHint alone.

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?

The core action and its inverse are front-loaded in the first sentence, and every sentence carries information. It is a single dense paragraph with long nested clauses and a fairly niche trailing note on indexing, which costs a little readability.

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 6-parameter mutation tool with an output schema, the description covers the permission constraint, access-mode semantics, the passcode-in-result behavior, and the reversibility/consent implications of unpublishing. An agent has everything needed to decide and invoke 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 100%, so baseline is 3, but the description adds decision-level meaning the schema lacks: passcode is intended for share-but-not-public scenarios, and access should not be raised to "anyone" unless the user asks. The remaining semantics (externalId, project, newPasscode) are left almost entirely to the schema.

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?

States a specific verb and resource plus the outcome ("Put a page on the open web and get a link") and covers the inverse operation ("take it back down by passing publish: false"). It is clearly distinguishable from siblings like write_page/edit_page since this is about web exposure and access control, not content mutation.

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 decision guidance for the access parameter ("use it whenever the user wants the page shared but not open to anyone who finds the link") and an explicit when-not constraint ("A connected app can only do this for pages it wrote itself"). It also states a guardrail against silent escalation of access levels, covering both when and when-not to act.

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