xTiles

xtiles_set_tile_styles

DestructiveIdempotent

Set the color and/or color_size of one or more tiles on an xTiles page (view). Merges into each tile’s existing style — the tile’s icon and any custom workspace color are preserved. Provide at least one of color/color_size per tile; an omitted field is left unchanged. A text page’s tile style is fixed — the call is refused there. Returns the resulting full tile-style state. Tip: call xtiles_get_tile_styles first for tile IDs. Which colours, styles, sizes and positions to use: xtiles://guide/markdown/design.

Input Schema

Name	Required	Description	Default
`tiles`	Yes	Tiles to recolor. Each tile_id must be unique; tiles you omit keep their current color. Setting merges into the existing style — the tile’s icon and any custom workspace color are preserved.
`viewId`	Yes	View ID of an xTiles page. You can also extract it from a page URL — it is the last path segment, whatever the domain, e.g. `https://xtiles.app/6740858058af8a09bf6096e6` → viewId is `6740858058af8a09bf6096e6`. Discover IDs programmatically via `xtiles_list_projects` or `xtiles_get_project_content`.

Output Schema

Name	Required	Description	Default
`tiles`	Yes
`view_id`	Yes
`editable`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 14, 2026

addedOutput schema / properties / editable

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

First observedOct 6, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations cover the safety profile (readOnly=false, destructive=true, idempotent=true, openWorld=true), but the description adds real behavior beyond them: the operation merges rather than replaces (icon and custom workspace color preserved), omission is a no-op per field, and the call is refused on text pages. It also states the return payload is the full resulting tile-style state. Minor tension: destructiveHint=true sits a bit oddly against the emphasis on preservation, but the description never claims a read-only or lossless-free operation, so this is not a contradiction.

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?

Four dense sentences, each carrying distinct information (scope, merge behavior, per-tile requirement, refusal case, ID discovery, design reference). Front-loaded with the operation itself and no repetition of schema enums.

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 mutation tool with a rich enum schema, nested item objects, and an output schema, the description supplies everything an agent still needs: how to obtain IDs, the refusal condition, merge/omit semantics, and the fact that the result is returned. Return-value details are correctly left to the output schema.

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, and the description adds genuine semantics the schema does not encode: 'provide at least one of color/color_size per tile' is a cross-field constraint, and the merge/omit semantics explain what each optional field does when absent. The viewId URL-extraction hint is also useful context.

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: 'Set the `color` and/or `color_size` of one or more tiles on an xTiles page (view).' This cleanly separates it from the read siblings (xtiles_get_tile_styles) and the reset sibling (xtiles_reset_tile_styles), and it names the exact fields it mutates.

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?

Gives concrete preconditions and exclusions: at least one of color/color_size per tile must be supplied, omitted fields are left unchanged, and text-page tiles are refused. It also points to `xtiles_get_tile_styles` for tile IDs and to a design guide resource. It stops short of explicitly contrasting with xtiles_reset_tile_styles, the closest mutating alternative.

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

All xTiles tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?