Skip to main content
Glama

Save a component style

save_component_style
DestructiveIdempotent

[Admin] Write one named style for a block type as a DRAFT in its own file, components/<block_type>/.css; the company's other CSS files are never changed. The page editor then offers it on every block of that type. Every selector starts from the guide's root plus the style class. styleName on blocks (update_portal_configuration) applies it; it goes live only with publish_portal_stylesheet (files: [file_id]). remove: true deletes a style's file; the guide lists which pages use it, and their blocks go back to the standard look once the stylesheet is published.

Every argument in full, with examples: get_tool_reference.

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": {
      "portal": "<portal>",
      "block_type": "<block_type>",
      "name": "<name>"
    },
    "name": "save_component_style"
  }
}

Input Schema

NameRequiredDescriptionDefault
cssNoThe rules. Every selector must include .jm-site and the style class, starting from the `root` the guide gives plus the class: `.jm-site .jm-block--hero.jm-style-dark-band h1 { ... }`. Required unless remove is true.
nameYesWhat the editor calls the style. Saving the same block type and name again replaces it.
portalYes`interview` (career and interview portal) or `consumer` (coaching portal). Only the interview portal has brands.
removeNotrue deletes the style and its file. Blocks that use it (the guide lists the pages) keep the name and show the standard look once the stylesheet is published.
brand_idNoA sub-brand, from the brands document of get_portal_configuration.
llm_modelNoYour model id, e.g. "claude-opus-4-8"; "unknown" if unsure. For analytics.
block_typeYesThe kind of block the style is for. The editor offers it only on blocks of this type.
descriptionNoOne line on what the style is for, kept as a comment above it.
merchant_idNoOptional company. Admins and sub-merchant operators only; other callers always use their token's company.
conversation_idNoThe conversation_id this server returned earlier in this conversation, unchanged, including after later user messages. Omit it if you have none. Recorded for the server developer's analytics.

Output Schema

NameRequiredDescriptionDefault
fileYes
liveYes
nameYes
classYes
pagesNo
actionYes
file_idYes
warningsYes
block_typeYes
style_nameYes
_mcp_instructionsNoServer-issued metadata for this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / css / description
      Previous value: -"The rules. Every selector must include .jm-site and the style class, starting from the `root` the guide gives plus the class: `.jm-site .jm-block--hero.jm-style-dark-band h1 { ... Required unless remove is true."New value: +"The rules. Every selector must include .jm-site and the style class, starting from the `root` the guide gives plus the class: `.jm-site .jm-block--hero.jm-style-dark-band h1 { ... }`. Required unless remove is true."
  2. Changed20 schema fields changed
    • removedInput schema / properties / block_type / example
      Removed value: -"hero"
    • changedInput schema / properties / brand_id / description
      Previous value: -"A sub-brand, from the brands document of get_portal_configuration. Leave it out for the main brand, the company's own, whose styles every sub-brand page also offers."New value: +"A sub-brand, from the brands document of get_portal_configuration."
    • changedInput schema / properties / css / description
      Previous value: -"The rules. Every selector must include .jm-site and the style class, starting from the `root` the guide gives plus the class: `.jm-site .jm-block--hero.jm-style-dark-band h1 { ... }`. @media, @supports and @container are fine; @import, @font-face and \"<\" are not. Required unless remove is true."New value: +"The rules. Every selector must include .jm-site and the style class, starting from the `root` the guide gives plus the class: `.jm-site .jm-block--hero.jm-style-dark-band h1 { ... Required unless remove is true."
    • addedInput schema / properties / llm_model
      Added value: +{
      +  "description": "Your model id, e.g. \"claude-opus-4-8\"; \"unknown\" if unsure. For analytics.",
      +  "type": "string"
      +}
    • changedInput schema / properties / name / description
      Previous value: -"What the editor calls the style. Saving the same block type and name again replaces it. Its file is components/<block_type>/<the name as a slug>.css."New value: +"What the editor calls the style. Saving the same block type and name again replaces it."
    • removedInput schema / properties / name / example
      Removed value: -"Dark band"
    • removedInput schema / properties / portal / example
      Removed value: -"interview"
    • removedOutput schema / properties / class / example
      Removed value: -"jm-style-dark-band"
    • removedOutput schema / properties / file / example
      Removed value: -"components/hero/dark-band.css"
    • removedOutput schema / properties / file_id / description
      Removed value: -"Pass it in `files` to publish_portal_stylesheet to publish this file alone. Null after a removal, which deletes the file."
    • removedOutput schema / properties / live / description
      Removed value: -"Always false: this is a draft until the stylesheet is published."
    • removedOutput schema / properties / pages / description
      Removed value: -"After a removal: the pages that used the style, whose blocks now show the standard look."
    • removedOutput schema / properties / pages / items / properties / brand_id / description
      Removed value: -"Its sub-brand; null for the main brand."
    • removedOutput schema / properties / pages / items / properties / draft / description
      Removed value: -"The draft uses the style."
    • removedOutput schema / properties / pages / items / properties / id / description
      Removed value: -"The page."
    • removedOutput schema / properties / pages / items / properties / published / description
      Removed value: -"The published page uses the style."
    • removedOutput schema / properties / pages / items / properties / slug / description
      Removed value: -"Its address; built-in pages start with \"_\", the home page is empty."
    • removedOutput schema / properties / pages / items / properties / slug / example
      Removed value: -"life-at-sea"
    • removedOutput schema / properties / pages / items / properties / title / description
      Removed value: -"Its title in the first language."
    • removedOutput schema / properties / style_name / description
      Removed value: -"The value to set as `styleName` on a block in page content."
  3. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds the crucial blast radius: only the style's own file changes, "the company's other CSS files are never changed," and nothing reaches users until a separate publish. It also discloses the consequence of removal (blocks revert to standard look) and that re-saving the same block_type+name replaces the prior style.

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 [Admin] scope and the draft-file guarantee, then the lifecycle, with zero filler sentences. It is dense — several clauses packed into one paragraph — but nothing is redundant, and the closing pointer to get_tool_reference is an efficient way to offload argument detail.

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?

For a destructive, multi-portal, admin-only writer with ten parameters and an output schema, the description covers the draft lifecycle, deletion effects, and non-interference with other files. It leaves authorization nuances (beyond the [Admin] tag) and merchant_id/brand_id scoping to the schema, which is acceptable given full coverage there.

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 the baseline is 3; the description still adds meaning by tying name to the file path and to the styleName field on blocks, noting css is required unless remove is true, and pointing to the guide for the selector root. The bulk of per-argument detail is delegated to get_tool_reference rather than inline.

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?

Names a specific verb and resource ("Write one named style for a block type as a DRAFT") and pins the exact artifact written: components/<block_type>/<style>.css. It is clearly separable from generate_component_styles (generation) and publish_portal_stylesheet (going live), both of which appear as distinct steps in the text.

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?

The draft-to-live pipeline is spelled out: save here, attach via styleName in update_portal_configuration, then publish with publish_portal_stylesheet, and remove: true to delete. It does not explicitly say when to prefer generate_component_styles over authoring by hand, so the sibling routing is implied rather than stated.

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.