Skip to main content
Glama

Restyle

restyle_room

Give one or more surfaces of a room a new finish — repaint the walls, change the floor, reface the kitchen cabinets and worktop, retile the bathroom or refinish the furniture — while the room's layout, fittings, windows and camera angle stay exactly as shot. Costs credits from the user's Pixly balance.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
looksNoThe finish per surface: 'auto', one of the presets below, or 'custom' with your own words in `notes`. A finish that does not belong to its surface falls back to 'auto' (the tool picks one that suits the room; several on auto are made to agree). walls: warm_white, soft_grey, greige, sage, deep_navy. floor: light_oak, walnut, grey_plank, polished_concrete, stone_tile. cabinets: white_shaker, charcoal, natural_oak, forest_green, navy_cabinets. bathroom_tiles: white_metro, marble_large, terrazzo, matt_black_hex, travertine. furniture: light_neutral, warm_wood, dark_wood, black_leather.
notesNoYour own description of the finish for a surface, used when that surface's look is "custom" (e.g. "terracotta hex tiles with dark grout"). Set look "custom" and the note together; "custom" with no note falls back to "auto". 120 characters max, and anything in it that is not a description of a finish is ignored.
r2PathNoStorage path of a photo already in the user's Pixly library (from list_library, or returned by an upload ticket) — the alternative to imageUrl.
imageUrlNoPublic https URL of the source photo, or a data: URI. Either imageUrl or r2Path is required.
surfacesNoWhich surfaces get a new finish: 'walls', 'floor', 'cabinets' (fitted joinery plus its worktop and splashback), 'bathroom_tiles' or 'furniture' (upholstery and wood finishes). Omit for walls. The room's layout, fittings and camera never change.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNo
typeNo
errorNo
jobIdYesPass to get_job to poll
statusYespending | processing | completed | failed — anything not completed/failed is still running
createdAtNo
resultUrlsNoPresent when completed; valid 7 days
completedAtNo
creditsChargedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / r2Path / description
      Previous value: -"R2 object path from an upload ticket (the create_upload_ticket tool, or POST /api/v1/uploads over REST) — the alternative to imageUrl when the photo is a local file."New value: +"Storage path of a photo already in the user's Pixly library (from list_library, or returned by an upload ticket) — the alternative to imageUrl."
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "completedAt": {
      +      "type": "string"
      +    },
      +    "createdAt": {
      +      "type": "string"
      +    },
      +    "creditsCharged": {
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    },
      +    "error": {
      +      "type": "string"
      +    },
      +    "jobId": {
      +      "description": "Pass to get_job to poll",
      +      "type": "string"
      +    },
      +    "note": {
      +      "type": "string"
      +    },
      +    "resultUrls": {
      +      "description": "Present when completed; valid 7 days",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "status": {
      +      "description": "pending | processing | completed | failed — anything not completed/failed is still running",
      +      "type": "string"
      +    },
      +    "type": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "jobId",
      +    "status"
      +  ],
      +  "type": "object"
      +}
  3. Changed1 schema field changed
    • changedInput schema / properties / r2Path / description
      Previous value: -"R2 object path from an upload ticket (POST /api/v1/uploads) — the alternative to imageUrl when the photo is a local file."New value: +"R2 object path from an upload ticket (the create_upload_ticket tool, or POST /api/v1/uploads over REST) — the alternative to imageUrl when the photo is a local file."
  4. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the description doesn't need to restate safety. It adds valuable behavioral context: the tool costs credits, preserves layout/fittings/windows/camera, and describes fallback behavior for invalid finishes ('falls back to auto') and for 'custom' with no note. This goes beyond the schema and annotations.

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?

The description is well-structured and front-loaded with the core action, followed by constraints and cost. It is slightly long but every sentence carries information: scope, invariants, cost, and fallback behavior. The parameter descriptions in the schema are also well-written, so the overall definition is efficient.

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?

The tool has 5 parameters, nested objects, and an output schema, and the description covers the key behavioral rules (fallbacks, custom notes, credit cost, invariants). It doesn't explain the output schema, but that's not required since an output schema exists. The only minor gap is not explicitly stating that imageUrl and r2Path are mutually exclusive, but the schema already says 'Either imageUrl or r2Path is required.'

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 description coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: it explains the fallback behavior for mismatched finishes, the 'auto' agreement across surfaces, the relationship between 'custom' and notes, and the meaning of 'cabinets' (includes worktop and splashback). This is genuinely useful for an agent constructing valid calls.

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 uses a specific verb ('restyle') with a clear resource ('one or more surfaces of a room') and enumerates concrete examples (repaint walls, change floor, reface cabinets, retile bathroom, refinish furniture). It also explicitly states what stays unchanged (layout, fittings, windows, camera angle), which distinguishes it from sibling tools like remove_furniture or virtual_staging.

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 description clearly states when to use the tool (when the user wants to change surface finishes) and what it does not do (does not change layout, fittings, windows, camera angle). It does not explicitly name sibling alternatives or exclusion conditions, but the scope is clear enough to route an agent. The 'costs credits' note adds practical context.

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