Skip to main content
Glama

Sharpen an image

sharpen_creative

Improve a finished image's detail, sharpness and clarity. The result is a new version of it. The source is a creative of the brand (creativeId) or an image on the web (imageUrl: a direct, public URL to a JPEG, PNG or WebP file). An image the user pasted or attached in the chat has no such URL and you cannot read it yourself: call request_image_upload right away (do not ask them to re-attach it), and once the image has landed use its creativeId here. An image you hold as a file on your own filesystem (a coding agent in a project) goes through upload_image_file instead. A linked image is added to the brand's library first and its creativeId is returned as sourceCreativeId; an image the library already holds is not added again, and sourceCreativeId is that creative, with alreadyInLibrary: true. Reuse sourceCreativeId for any further work on the same image instead of passing imageUrl again. Cost: 30 credits. Call with dryRun: true first and tell the user the cost. Once they agree, pass the quoted credits as expectedCredits; a call that would cost a different amount is refused. Give each new generation a new requestId, and repeat it unchanged only on a retry: a retry within 2 minutes returns the first result and is not charged again. Without a requestId, the same arguments within 2 minutes count as a retry. Needs generation allowed over MCP (see get_workspace); a dry run still quotes when it is not, and says why the call would be refused in wouldRefuse. Returns a jobId, creditsCharged and creditsRemaining; ready in 1 to 5 minutes. If a job panel shows, it tracks the work: do not poll, end your turn with one line saying it is under way, and later use show_creatives with the creativeIds you are told. Otherwise call wait_for_jobs with the jobIds until allFinal is true.

Input Schema

NameRequiredDescriptionDefault
dryRunNotrue: return the exact cost (credits, breakdown, balanceAfter) without charging or starting anything, and wouldRefuse when the organization's spending controls would refuse the real call.
brandIdNoA brand id from get_workspace or list_brands, or the brand's name. Omit it when the organization has a single brand.
imageUrlNoA direct, publicly reachable https URL of the image to work on, when it is not in the library yet.
requestIdNoYour own unique id for this request. Use a new one for every new request, even with the same arguments. Repeat it unchanged only to retry this exact call within 2 minutes; the retry returns the first result.
creativeIdNoA creative id from list_creatives, search_library, get_job or get_upload.
expectedCreditsNoThe credits the dryRun quoted and the user agreed to. The call is refused if it would cost a different amount.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / brandId / description
      Previous value: -"A brand id from get_workspace or list_brands. Omit it when the organization has a single brand."New value: +"A brand id from get_workspace or list_brands, or the brand's name. Omit it when the organization has a single brand."
    • changedOutput schema / anyOf
      Previous value: -[
      -  {
      -    "additionalProperties": false,
      -    "properties": {
      -      "balanceAfter": {
      -        "type": "number"
      -      },
      -      "breakdown": {
      -        "type": "string"
      -      },
      -      "credits": {
      -        "type": "number"
      -      },
      -      "deduplicated": {
      -        "const": true,
      -        "description": "The same call was made in the last 2 minutes: this is its result, not charged again.",
      -        "type": "boolean"
      -      },
      -      "dryRun": {
      -        "const": true,
      -        "type": "boolean"
      -      },
      -      "wouldRefuse": {
      -        "description": "Set when the organization's MCP spending controls would refuse the real call: the refusal it would get.",
      -        "type": "string"
      -      }
      -    },
      -    "required": [
      -      "dryRun",
      -      "credits",
      -      "breakdown",
      -      "balanceAfter"
      -    ],
      -    "type": "object"
      -  },
      -  {
      -    "additionalProperties": false,
      -    "properties": {
      -      "creditsCharged": {
      -        "type": "number"
      -      },
      -      "creditsRemaining": {
      -        "type": "number"
      -      },
      -      "deduplicated": {
      -        "const": true,
      -        "description": "The same call was made in the last 2 minutes: this is its result, not charged again.",
      -        "type": "boolean"
      -      },
      -      "jobId": {
      -        "type": "string"
      -      },
      -      "sourceCreativeId": {
      -        "type": "string"
      -      },
      -      "watchToken": {
      -        "type": "string"
      -      }
      -    },
      -    "required": [
      -      "jobId",
      -      "watchToken",
      -      "creditsCharged",
      -      "creditsRemaining",
      -      "sourceCreativeId"
      -    ],
      -    "type": "object"
      -  }
      -]New value: +[
      +  {
      +    "additionalProperties": false,
      +    "properties": {
      +      "balanceAfter": {
      +        "type": "number"
      +      },
      +      "breakdown": {
      +        "type": "string"
      +      },
      +      "credits": {
      +        "type": "number"
      +      },
      +      "deduplicated": {
      +        "const": true,
      +        "description": "The same call was made in the last 2 minutes: this is its result, not charged again.",
      +        "type": "boolean"
      +      },
      +      "dryRun": {
      +        "const": true,
      +        "type": "boolean"
      +      },
      +      "wouldRefuse": {
      +        "description": "Set when the organization's MCP spending controls would refuse the real call: the refusal it would get.",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "dryRun",
      +      "credits",
      +      "breakdown",
      +      "balanceAfter"
      +    ],
      +    "type": "object"
      +  },
      +  {
      +    "additionalProperties": false,
      +    "properties": {
      +      "alreadyInLibrary": {
      +        "const": true,
      +        "description": "The brand's library already held this image, so no new creative was added: the id names that one.",
      +        "type": "boolean"
      +      },
      +      "creditsCharged": {
      +        "type": "number"
      +      },
      +      "creditsRemaining": {
      +        "type": "number"
      +      },
      +      "deduplicated": {
      +        "const": true,
      +        "description": "The same call was made in the last 2 minutes: this is its result, not charged again.",
      +        "type": "boolean"
      +      },
      +      "jobId": {
      +        "type": "string"
      +      },
      +      "sourceCreativeId": {
      +        "type": "string"
      +      },
      +      "watchToken": {
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "jobId",
      +      "watchToken",
      +      "creditsCharged",
      +      "creditsRemaining",
      +      "sourceCreativeId"
      +    ],
      +    "type": "object"
      +  }
      +]
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond annotations: 30-credit cost, the dry-run/quote/confirm protocol, refusal on credit mismatch, requestId retry semantics with a 2-minute no-charge window, the generation-allowed-over-MCP prerequisite with wouldRefuse behavior, and 1-5 minute readiness. Annotations only say it is a non-read-only, non-idempotent, non-destructive operation; the description supplies the operational and financial consequences.

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?

Purpose is front-loaded and every sentence carries operative information, but the single dense paragraph bundles routing, cost, retry, gating and polling rules without line breaks, making it harder to scan than it needs to be.

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 paid, asynchronous, gated generation tool with an output schema, this covers everything an agent needs: input-source routing, cost confirmation, retry identity, refusal conditions and what to do while the job runs. The output schema already documents returns, and the description still names jobId, creditsCharged and creditsRemaining as a convenience.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: expectedCredits must match the quoted amount or the call is refused, requestId must be new per request and repeated only on retry, and sourceCreativeId should be reused rather than re-passing imageUrl. That is meaningfully more than the field docs alone.

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?

States a specific verb and resource ('Improve a finished image's detail, sharpness and clarity') and immediately distinguishes the outcome ('The result is a new version of it'). It is clearly separable from siblings like remove_background, resize_creative and generate_image without opening a schema.

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

Usage Guidelines5/5

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

Explicitly routes between the three input paths: creativeId for library creatives, imageUrl for public web files, request_image_upload for chat attachments (with 'do not ask them to re-attach it'), and upload_image_file for local files. It also prescribes the dryRun-then-expectedCredits flow and the wait_for_jobs vs job-panel branch, leaving nothing to inference.

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