Skip to main content
Glama

meta_ads_creatives_upload_image

Uploads an image from a public HTTPS URL to a Meta Ads account and returns the image_hash required to create ads, dynamic ads, or carousels that reference it.

Instructions

Uploads an image to the Meta Ads account by fetching it from a public HTTPS URL. Returns the image_hash that can be referenced in meta_ads_creatives_create / create_dynamic / create_carousel. Mutating — the image is persisted in the account library. For uploads from local files (not URLs) use meta_ads_images_upload_file instead.

Input Schema

NameRequiredDescriptionDefault
reasonNoWhy this change is being made: one or two sentences naming the evidence and the expected effect. Stored in the journal and on the action_log entry this call produces, for the operator and the next session.
approvalNoExternal approval this change carries out (recorded and shown, never verified)
expectedNoExpected effects [{metric, direction, target?, horizon_days?, primary?}], exactly one primary:true when several; metric cpa/cpc/cpl/cpm/conversions/cvr/ctr/roas/cost/spend/clicks/impressions; direction up/down/hold.
image_urlYesPublic HTTPS URL of the image. Meta fetches it once at upload time — subsequent changes to the source URL do not affect the stored asset.
account_idNoMeta Ads account ID in the format 'act_XXXXXXXXXX' (e.g. 'act_1234567890'). Optional — falls back to META_ADS_ACCOUNT_ID from the configured credentials. The leading 'act_' prefix is required.
decision_idNoA proposed decision this change carries out.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.33.0
    • changedInput schema / properties / expected / description
      Previous value: -"Expected effects [{metric, direction, target?, horizon_days?}]; metric cpa/cpc/cpl/cpm/conversions/cvr/ctr/roas/cost/spend/clicks/impressions; direction up/down/hold."New value: +"Expected effects [{metric, direction, target?, horizon_days?, primary?}], exactly one primary:true when several; metric cpa/cpc/cpl/cpm/conversions/cvr/ctr/roas/cost/spend/clicks/impressions; direction up/down/hold."
  2. Changed1 schema field changedv0.28.0
    • addedInput schema / properties / approval
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "External approval this change carries out (recorded and shown, never verified)",
      +  "properties": {
      +    "approved_at": {
      +      "maxLength": 64,
      +      "type": "string"
      +    },
      +    "approved_by": {
      +      "maxLength": 80,
      +      "type": "string"
      +    },
      +    "reference": {
      +      "maxLength": 128,
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "reference",
      +    "approved_by",
      +    "approved_at"
      +  ],
      +  "type": "object"
      +}
  3. Changed2 schema fields changedv0.26.0
    • addedInput schema / properties / decision_id
      Added value: +{
      +  "description": "A proposed decision this change carries out.",
      +  "maxLength": 128,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / expected
      Added value: +{
      +  "description": "Expected effects [{metric, direction, target?, horizon_days?}]; metric cpa/cpc/cpl/cpm/conversions/cvr/ctr/roas/cost/spend/clicks/impressions; direction up/down/hold.",
      +  "maxItems": 12,
      +  "type": "array"
      +}
  4. Changed1 schema field changedv0.20.0
    • addedInput schema / properties / reason
      Added value: +{
      +  "description": "Why this change is being made: one or two sentences naming the evidence and the expected effect. Stored in the journal and on the action_log entry this call produces, for the operator and the next session.",
      +  "maxLength": 500,
      +  "type": "string"
      +}
  5. Changed1 schema field changedv0.10.37
    • addedInput schema / additionalProperties
      Added value: +false
  6. Addedv0.9.12
  7. Removedv0.9.6
  8. Addedv0.9.2
  9. Removedv0.9.1
  10. Addedv1.0.5

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it declares the operation mutating, states that the asset is persisted in the account library, and discloses the snapshot behavior ('Meta fetches it once at upload time — subsequent changes to the source URL do not affect the stored asset'). Missing are permission/token requirements and failure modes for non-HTTPS or unreachable URLs.

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?

Four short sentences, front-loaded with what it does, then the return value, then the mutating caveat, then the alternative. Nothing is repeated and every sentence carries a distinct piece of 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?

With no output schema, the description usefully supplies the return value (image_hash) and its downstream consumers, and covers the mutation and the sibling routing. The remaining gap is error behavior when the URL is rejected or unfetchable, which matters for a network-dependent upload.

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 coverage is 100%, so every parameter including image_url, account_id, and the journaling fields is already documented in structured data. The description adds no per-parameter semantics beyond what the schema states, so the baseline 3 applies.

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 ('Uploads an image to the Meta Ads account') plus the mechanism ('fetching it from a public HTTPS URL'), which alone separates it from meta_ads_videos_upload and the creative-creation siblings. It also explicitly names the sibling it is not (meta_ads_images_upload_file for local files).

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?

Gives a clear selection rule against the nearest alternative: URL-based uploads here, local-file uploads via meta_ads_images_upload_file. It also tells the agent what to do next with the result by naming the three create_* tools that consume the image_hash.

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

Deploy Server

Other Tools