PixelGlass

Update the publication

update_publication

Idempotent

On one site of the account, named in site. Changes what the onboarding walk and Settings › General set: the title, the description, the languages it publishes in with the default one, and the logo. When the default changes and the old default leaves the languages, its posts and pages move to the new default and keep their addresses (moved_posts in the answer). The description is one line; bold, italic and a link are kept. The logo is a library address from upload_media; an empty one removes it. Also the home page (Settings › Design): a published page shown at the site's root in place of the latest posts, each language showing its own translation; the latest posts below it or not; and an address of its own for the posts list. And the social links: the publication's profile on each network, shown in the site's footer; only the networks named change, and an empty address removes one. Readers see the change at once.

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": {
      "site": "<site>"
    },
    "name": "update_publication"
  }
}

Input Schema

Name	Required	Description
`logo`	No	The publication's mark: a library address from upload_media, or empty to remove it
`site`	Yes	The site to work on, as list_sites names it
`title`	No	The publication's name
`home_page`	No	The slug of a published page in the default language, shown at the root; empty for the latest posts
`languages`	No	Every language it publishes in, as tags (en, ko, pt-BR)
`home_posts`	No	Whether the latest posts show below the home page
`posts_path`	No	One word, like blog: the posts list's own address (/blog); empty for none
`description`	No	One line that says what the publication is
`social_links`	No	The profile on each network to change: a handle such as @name, or an address such as https://x.com/name; empty to remove one
`default_language`	No	The language of its plain addresses; joins languages if it is not there

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 10, 2026
- addedInput schema / properties / social_links / properties / kakaotalk
```
Added value: +{
+  "description": "https://pf.kakao.com/_name",
+  "type": "string"
+}
```
First observedNov 9, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare the safety profile (readOnly=false, destructive=false, idempotent=true, openWorld=true); the description goes well beyond that. It discloses the cascade when default_language changes and the old default leaves (posts and pages move, keep addresses, reported as moved_posts in the answer), that social links are partially updated so only named networks change, that empty strings remove values, and that readers see changes immediately.

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?

Nearly every clause earns its place and the scoping constraint (one site, named in site) is front-loaded, but the body is a single dense paragraph beginning with a sentence fragment, which makes it harder to scan than a grouped or bulleted form. Content is efficient; presentation is slightly muddy.

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 10-parameter tool with a nested social_links object and no output schema, the description still covers all three setting groups, the removal convention, the cascade side effect, and even mentions the moved_posts field in the response. An agent has what it needs to call this correctly and to anticipate the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3, but the description adds genuine meaning the schema does not carry: the semantic consequence of changing default_language, the partial-update rule for social_links, formatting retention in description, the per-language translation behavior of home_page, and the source of logo values. These are behavioral semantics, not restatements of field docs.

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 names a specific verb and resource and then enumerates exactly which settings are in scope: title, description, languages with default, logo, home page, home posts, posts path, and social links. It also names the sibling dependency (upload_media) for the logo address, so an agent can distinguish this from read-side tools like get_publication.

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?

Usage context is clear: this is the tool for changing publication-level settings on one site, and it explicitly sends the agent to upload_media for the logo address. It stops short of explicit when-not guidance (e.g. use get_publication to read current values before editing), so it earns a 4 rather than a 5.

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

All PixelGlass tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?