Skip to main content
Glama

Pixly

by app.pixly
OverviewDiscussionsAdmin

Exterior Makeover

makeover_exterior

Design the garden of an exterior listing photo as one coherent scheme — planting, a terrace or deck, a pool, a pergola, a fire pit, a fence, lighting — in a chosen style, at the right scale and perspective, while the house, its roof, the driveway, the sun direction and the neighbours stay exactly as shot. One run builds the whole scheme. Costs credits from the user's Pixly balance.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoYour own words about the garden you want (e.g. "a small kidney-shaped pool with a stone surround and lavender everywhere"). 160 characters max; anything in it that is not a description of the garden is ignored.
scopeNo'full' (the default) redesigns the whole yard in the style; 'add' keeps the existing garden and builds the chosen elements into it. The house, the driveway and the neighbours never change either way.
styleNoThe design language of the whole scheme: 'modern_minimal', 'mediterranean', 'classic_english', 'natural_lowwater', 'tropical_resort', 'farmhouse', or 'auto' (the default — chosen to suit the house's architecture and the climate in the photo).
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.
includeNoWhich elements the scheme includes, any number: 'planting' (beds, hedges, a feature tree), 'patio_dining' (a paved terrace with a dining set), 'deck_lounge' (a deck with loungers or a low sofa), 'pool', 'pergola', 'fire_pit', 'fence_gate' (a boundary treatment with a gate), 'lighting'. Omit or send an empty list (the default) to let the tool design what the lot wants. One run composes them all into one garden, each sized to the plot.
imageUrlNoPublic https URL of the source photo, or a data: URI. Either imageUrl or r2Path is required.

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.2/5.0
Behavior4/5

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

The description adds behavioral context beyond the annotations: it states the tool costs credits from the user's Pixly balance and that the house, roof, driveway, sun direction, and neighbors remain unchanged. This complements the openWorldHint (adds elements) and destructiveHint false (non-destructive) annotations, providing clarity on scope and cost without contradicting them.

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?

The description is two sentences, with the first sentence front-loading the core purpose and scope. It lists elements efficiently, then states constraints and cost. Every clause adds meaning with no fluff, making it appropriately concise and well-structured.

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 description covers the tool's purpose, scope, constraints, cost, and the one-run composition behavior. The schema provides detailed parameter semantics, and the presence of an output schema means return format is documented elsewhere. It is complete enough for an agent to understand when and how to use the tool, though it could briefly mention the requirement of an exterior photo (though that is implied by the title and description).

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?

Schema coverage is 100%, so all six parameters are thoroughly documented in the schema, including enums and descriptions. The description does not add parameter-specific semantics beyond what the schema provides; it gives a high-level overview that ties parameters together, but the schema already explains key behaviors like 'One run composes them all into one garden' in the include parameter. Thus the description adds little beyond the baseline.

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 clearly states the tool designs the garden of an exterior listing photo as one coherent scheme, listing specific elements (planting, terrace, pool, etc.) and explicitly noting what stays unchanged (house, roof, driveway, sun direction, neighbors). This distinguishes it from sibling tools that alter other aspects, and the phrase 'One run builds the whole scheme' clarifies its comprehensive scope.

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 conveys it is for garden design, implying use when the user wants a full or partial garden makeover, and mentions the credit cost. However, it does not explicitly name alternatives or state when not to use it, relying on the agent to infer from the tool's name and purpose. It provides clear context but lacks explicit exclusions or comparisons to siblings.

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

All Pixly toolsInspect
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