HelpCenter.io

Change Custom CSS

helpcenter_update_template_css

DestructiveIdempotent

Change one custom CSS block: replace its CSS, rename it, switch it on or off, or move it in the order. Fields left out keep their value.

It edits the help center's design DRAFT (its v2 template): the draft the dashboard's Template Editor opens, with a live preview. Nothing reaches visitors until helpcenter_publish_template — after editing, give the customer the Template Editor link from the result to review, and publish only when they ask. v2 help centers only (a classic one answers template_migration_required). Ids come from helpcenter_get_template.

Read the block first (helpcenter_get_template, section 'custom_css' with its id). Switching a block off (enabled:false) shows the design without it and keeps it to switch back on. A theme's blocks are the customer's too, edited in the dashboard (Advanced → Custom CSS): to change how a theme looks, prefer a block of your own (helpcenter_add_template_css), which comes later and wins. This is the guide's update_css operation.

Args:

id (string): the block.
css, label, enabled, index (optional): what to change.
etag (string, optional): from your last read or edit; refuses (stale_draft) if the draft changed since.

Returns: what each entry did (new ids), warnings worth relaying, and the draft status with its new etag.

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": {
      "id": "<id>"
    },
    "name": "helpcenter_update_template_css"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Id of a custom CSS block, as the draft reports it.
`css`	No	The new CSS, replacing the block's.
`etag`	No	Optimistic lock: the draft etag from your last read, or the one your last edit returned. When given, the call is refused (stale_draft) if someone changed the draft since — so you never build on a state you have not seen. Omit to apply to the current draft.
`index`	No	Move the block to this 0-based position among the CSS blocks.
`label`	No	A name for the block, e.g. 'Cards · hover lift'.
`enabled`	No	false switches the block off without deleting it.
`site_id`	No	Which help center to act on: an id from helpcenter_list_sites. Needed when this connection reaches more than one help center; omit it when it reaches one. Applies to this call only — pass it on every call of a task, and ask the user which help center they mean if their request does not say.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare destructive=true, idempotent=true, openWorld=true, but the description goes well beyond them: edits land in the unpublished draft, nothing reaches visitors until helpcenter_publish_template, disabling preserves the block, the stale_draft refusal on etag mismatch, and the template_migration_required error for classic help centers. That is exactly the behavioral context an agent needs before mutating shared design state.

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?

Front-loaded with the core action, then scoped into draft/publish semantics, prerequisites, and return values in a readable progression. It is dense and slightly long — the theme-blocks paragraph could be tightened — but nearly every sentence carries operational information an agent would otherwise have to guess.

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 7-parameter mutation with no output schema, the description covers scope (draft only), prerequisites (read first, site_id from list_sites), failure modes (stale_draft, template_migration_required), reversibility (enabled:false keeps the block), and a summary of what the return contains. Nothing material is left for the agent to infer.

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 parameters are already documented, but the description adds the crucial partial-update contract — 'Fields left out keep their value' — which is PATCH semantics absent from the schema. It also restates the etag provenance and the stale_draft failure mode in task-flow terms. Slight redundancy with the schema keeps this from a 5.

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 — 'Change one custom CSS block' — and enumerates the four mutations it performs (replace CSS, rename, enable/disable, reorder). This cleanly separates it from helpcenter_add_template_css and helpcenter_remove_template_css, which an agent can rule out without opening their schemas.

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 when-to-use and when-not-to guidance: read the block first via helpcenter_get_template, prefer adding your own block over editing a theme's blocks, publish only when the customer asks, and only for v2 help centers. The alternative paths are named with concrete tool names rather than implied.

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

All HelpCenter.io 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?