Skip to main content
Glama

aspect_ratio_change

Change an image's aspect ratio, filling new space with AI. Returns { processedImage }. Cost: 2 credits.

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": {
      "image": "<image>",
      "aspectRatio": "<aspectRatio>"
    },
    "name": "aspect_ratio_change"
  }
}

Input Schema

NameRequiredDescriptionDefault
imageYesImage as a base64 data URI (data:image/png;base64,…) or an HTTPS image URL
aspectRatioYesTarget ratio

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of explaining behavior, and it does add useful details: the new space is AI-generated, the return shape is { processedImage }, and the call costs 2 credits. It stays silent on what happens to content outside the new frame (crop versus preserve), how nondeterministic the AI fill is, and whether credit balance must be checked first.

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?

Three short, front-loaded clauses cover purpose, return value, and cost, with no filler. Nothing can be trimmed without losing information.

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?

For a two-parameter tool with no output schema, the description covers the action, the return key, and the cost, which is enough to call it correctly. The gaps concern crop-versus-expand behavior and credit preconditions, which are minor rather than blocking.

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%, and both parameters (the base64 data URI or HTTPS URL, and the aspectRatio enum) are fully documented in the schema. The description adds nothing beyond that, which matches the baseline of 3 when the schema does the heavy lifting.

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?

The description states a specific verb and resource and explains the mechanism: change an image's aspect ratio and fill the new space with AI. That is clear enough to act on. It does not distinguish the tool from the other AI-editing siblings, such as ai_expand, even though 'filling new space with AI' overlaps most closely with that one.

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 use case is only implied: when you want a different aspect ratio, call this tool. The description never says when to choose it over ai_expand or other editing tools, and it gives no prerequisites, such as requiring a source image or sufficient credits.

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