Skip to main content
Glama

Update mini site block

update_mini_site_block
DestructiveIdempotent

Patch one existing block on a bio page — change a link title or URL, a product price, an event date, opening hours, or the display order. Only the fields you pass are changed; everything else is left alone. The block type cannot be changed (remove it and add a new one instead). The response returns the block AS STORED, so any value the server rejected is visibly absent: updated lists only the fields that actually changed, and any requested field the server did not keep comes back under ignored — check it before telling the user a change was applied. To un-stage a block from a release rollout, pass phase:"always" — that clears the staging (there is no other way to remove it). Use get_mini_site first to get the blockId.

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": {
      "blockId": "<blockId>"
    },
    "name": "update_mini_site_block"
  }
}

Input Schema

NameRequiredDescriptionDefault
altNo
urlNo
daysNo
modeNo
textNo
labelNo
limitNo
linksNo
orderNo
phaseNo
priceNo
titleNo
imagesNo
siteIdNo
blockIdYes
captionNo
endDateNo
feedUrlNo
headingNo
embedUrlNo
faqItemsNo
imageUrlNo
locationNo
providerNo
richTextNo
timezoneNo
startDateNo
artworkUrlNo
buttonLabelNo
descriptionNo
releaseDateNo
visibleFromNo
thumbnailUrlNo
visibleUntilNo
postReleaseLinksNo

Output Schema

NameRequiredDescriptionDefault
blockYes
ignoredNo
updatedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedOutput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover safety (destructiveHint=true, idempotentHint=true), but the description adds substantial context beyond them: patch semantics (unpassed fields untouched), the fact that the response returns the block 'AS STORED', and that rejected values surface under `ignored` and must be checked before reporting success. It also discloses that phase:"always" is the only way to clear staging — a behavioral fact available nowhere in the annotations or schema.

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?

Effectively sized for a 35-param patch tool: leads with what it does and the patch guarantee, then the immutability constraint, then the response-verification warning, then the special-case and prerequisite. Every sentence carries a distinct, actionable fact with no filler.

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?

Given an output schema exists, the description needn't spell out return values, yet it still explains the `updated`/`ignored` semantics that matter for trust in the result. The remaining gap is field-to-block-type mapping across 35 parameters, which an agent must infer from the four examples given.

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

Parameters3/5

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

With 35 parameters and 0% schema description coverage, this description compensates only partially — it explains patch semantics, the phase:"always" special case, and hints which fields belong to which block type, which is genuinely beyond the schema. But the vast majority of parameters (days, mode, feedUrl, faqItems, postReleaseLinks, visibleFrom/visibleUntil, siteId vs blockId, images) are undocumented in both the schema and the description.

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 ('Patch one existing block on a bio page') and enumerates concrete editable values (link title, product price, event date, opening hours, display order), so an agent knows exactly what class of change this tool makes. It also draws the boundary against the sibling pair ('The block type cannot be changed (remove it and add a new one instead)'), differentiating it from add_mini_site_block and remove_mini_site_block.

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 an explicit prerequisite ('Use get_mini_site first to get the blockId'), an explicit when-not with the alternative ('block type cannot be changed — remove it and add a new one'), and a non-obvious when-to-use for a specific scenario (phase:"always" to un-stage from a release rollout). All three of the routing decisions an agent would otherwise have to guess are 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.

Resources