Skip to main content
Glama

Pixly

by app.pixly

replace_sky

Replace a grey, overcast or blown-out sky in an exterior listing photo with a natural clear blue sky, matching the light and keeping the building, trees and reflections unchanged. Costs credits from the user's Pixly balance.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
skyNoSky style. 'auto' lets the tool pick what suits the photo's light.auto
sunNoSun glow: auto (a glow for sunset/sunrise styles, none otherwise), on (place it with sunX/sunY), off.auto
sunXNoWith sun=on: glow position from the left edge, 0..1.
sunYNoWith sun=on: glow position from the top edge, 0..1 (kept in the top 60%).
r2PathNoR2 object path from an upload ticket (POST /api/v1/uploads) — the alternative to imageUrl when the photo is a local file.
imageUrlNoPublic https URL of the source photo, or a data: URI. Either imageUrl or r2Path is required.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

The description discloses a meaningful side effect beyond the annotations: 'Costs credits from the user's Pixly balance.' It also promises non-destructive behavior by keeping building, trees, and reflections unchanged, and mentions that it matches the light. This gives the agent a clear model of the edit's behavior and side effects.

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 long, front-loaded with the core operation, and includes only necessary additional context about credit costs. Every sentence earns its place with no filler or redundancy.

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, combined with the fully documented schema, covers the main usage scenario, input alternatives, and the critical credit-cost side effect. It does not describe return values or job semantics, but no output schema exists and the core invocation details are clear enough for an agent to proceed.

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 description coverage is 100%, with every parameter already documented in the input schema, including the sky enum, sun controls, and the imageUrl/r2Path alternatives. The description itself adds no parameter-specific detail, so the baseline score of 3 is appropriate.

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 opens with 'Replace a grey, overcast or blown-out sky in an exterior listing photo with a natural clear blue sky', which names a specific verb, object, and input condition. It also states what will be preserved and that the result matches the photo's light, making the tool's identity unmistakable and naturally distinct from siblings like day_to_night or enhance_photo.

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?

It clearly states when the tool is appropriate: for grey, overcast, or blown-out skies in exterior listing photos. It does not explicitly name alternatives or exclusion criteria, but the conditions given are specific enough to guide selection.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation4/5

Each tool targets a distinct workflow: uploads, job/credit management, single-effect photo edits, staging, and video generation. The only mild ambiguity is between declutter_photo and remove_furniture, but the descriptions explicitly contrast them, so an agent can usually pick correctly.

Naming Consistency4/5

Most tools follow a clear verb_noun snake_case pattern like create_upload_ticket, replace_sky, and remove_furniture. A few names are noun phrases rather than verbs—day_to_night, virtual_staging, before_after_reel—but they are still readable and do not break the overall convention badly.

Tool Count5/5

At 15 tools, the server is at the upper edge of the ideal range, but every tool maps to a distinct real-estate photo/video workflow: uploading, credits, job polling, staging, editing, and reveal videos. Nothing feels redundant or unnecessary.

Completeness4/5

The core Pixly workflow is well covered: bring images in via upload, run generation/editing tools, poll jobs, and list results. Minor gaps like job cancellation or generic restyle control exist, but agents can complete the primary photo and video workflows end to end.

Resources