Skip to main content
Glama

color_background

Replaces an image background with a solid hex or RGB(A) color and saves the edited result to a local file.

Instructions

Replace the background with a solid color.

Input Schema

NameRequiredDescriptionDefault
colorYesColor as hex ('#FF8C00', '#FF8C0080') or RGB(A) ('255, 140, 0' or '255, 140, 0, 255').
image_pathYesPath to a local JPG, PNG, WEBP, BMP or GIF image (1 KB to 10 MB).
output_pathNoWhere to save the result. Defaults to '<name>_<operation>.<ext>' next to the input image.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

B3.2/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description adds only the bare transformation semantics and says nothing about how alpha/transparency in the source image is handled, whether the subject is segmented first, or whether any input file is touched — the details that actually matter for a background-replacement operation.

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?

A single front-loaded sentence with zero filler. It is efficient, but the length is also the source of the definition's thinness rather than a sign of completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and the input schema is fully annotated, so return values and parameters need no explanation. Still, for an image mutation tool the description leaves open how the subject/background separation happens and whether transparency is preserved — relevant gaps given no destructive/segmentation context is supplied elsewhere.

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%, so color formats, accepted image types, and the output_path default are all documented in the schema. The description adds no parameter meaning beyond that, which is the correct baseline when the schema does the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

A specific verb+resource ('Replace the background') with a qualifier ('solid color') that distinguishes it from blur_background and gradient_background without naming them. An agent can pick it apart from siblings on the fill type alone, though it never states that it also differs by not removing the subject first.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The adjective 'solid' implicitly signals when this is the right choice over gradient_background or blur_background, but there is no explicit when-to-use statement, no prerequisites, and no named alternatives. Usage is inferable rather than stated.

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