Skip to main content
Glama
Sign In

streetshirts

by com.streetshirts
OverviewDiscussionsAdmin

Shape an image

set_image_mask
Destructive

Apply an editable circle, ellipse, rounded rectangle, heart, star, hexagon, diamond, arch, shield or organic shape to an exact image. Pass elementId, areaId and imageMask:{shape:'circle'}. Existing Crop, filters and background treatment are retained. Optional normalized content framing preserves image aspect. Preview and saved print artwork use the same shape.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "subject": "<subject>",
      "sessionToken": "<sessionToken>",
      "requestId": "<requestId>"
    },
    "name": "set_image_mask"
  }
}

Input Schema

NameRequiredDescriptionDefault
optionsNoExisting arguments; advanced fields/aliases remain accepted. Supplied design patches can overwrite session content; preview/rendering can fetch public image URLs in those designs. Catalogue/session results include the full designArgumentSchema.
subjectYesThe exact subject returned by start_design_session.
requestIdYesGenerate a UUID for a new action. Reuse it only for retrying/polling that same action and payload. A new user edit needs a new UUID.
sessionTokenYesThe private expiring capability returned by start_design_session. Do not publish it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and non-idempotent, so the bar is lower, yet the description adds real value: it discloses that Crop, filters and background treatment survive the operation, that the shape is editable (i.e. reversible via remove_image_mask), and that preview equals saved print output. It does not address permissions, batch behavior when elementIds is supplied, or failure modes.

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?

Four tight sentences, each carrying distinct information: capability, call shape, state retention, framing, and preview parity. The shape enumeration is long but earns its place as enum disambiguation; there is no filler or hedging.

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 destructive, open-world mutation with a nested optional object and no output schema, the description covers what changes, what is preserved, and how preview relates to final artwork. Remaining identifiers (subject, sessionToken, requestId) are fully documented in the schema, so nothing an agent needs to call this correctly is missing.

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 the baseline is 3. The description adds modest meaning by showing the imageMask:{shape:'circle'} nesting and by explaining that the optional content object is 'normalized content framing' that 'preserves image aspect' — context the bare x/y/width/height schema does not convey. It says nothing about elementId vs elementIds, areaId side selection, or the instruction field.

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?

States a specific verb (apply) and resource (an image mask shape) and enumerates every supported shape, mapping enum values like 'rounded' and 'blob' to human terms ('rounded rectangle', 'organic shape'). It does not name the sibling inverse, remove_image_mask, or distinguish itself from crop_image, so an agent must infer the boundary from the sibling list.

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 description gives an invocation pattern (pass elementId, areaId and imageMask:{shape:'circle'}) which helps construction, and notes that connected-crop/filter/background state persists. It never says when to prefer this over crop_image, remove_image_mask, or the content-framing path, and states no preconditions or exclusions.

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

All streetshirts 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