Skip to main content
Glama

Meta Ads (Facebook & Instagram)

meta_ads_media_write_get_upload_command

Upload images and videos to Meta Ads account. Actions: upload_image — upload an image. Returns the image hash you need for create_creative. upload_video — upload video from URL (Meta fetches it). Returns video_id. get_upload_command — get a curl command for uploading large local video files (keeps file out of AI context). upload_image accepts the file in four ways (use exactly one): image_url/file_url (public URL), upload_id (uploaded via the command this tool hands you), file_base64, or upload_code. Call upload_image with NO file to get a ready-made upload command for a file on the user's machine. Facebook CDN links (*.fbcdn.net) are signed, expiring and pinned to the browser that opened them — they do NOT work as image_url from the server; upload the file instead. For listing already-uploaded media use meta_ads_media.

[Flattened action: get_upload_command]

Bulk support: accepts upload_ids for batched execution.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNo
accountNo
file_urlNo
file_nameNo
file_pathNo
image_urlNo
upload_idNo
video_urlNo
upload_idsNo
file_base64No
upload_codeNo
auth_accountNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed6 schema fields changed
    • addedInput schema / properties / file_base64
      Added value: +{
      +  "type": "string"
      +}
    • addedInput schema / properties / file_name
      Added value: +{
      +  "type": "string"
      +}
    • addedInput schema / properties / file_url
      Added value: +{
      +  "type": "string"
      +}
    • addedInput schema / properties / upload_code
      Added value: +{
      +  "type": "string"
      +}
    • addedInput schema / properties / upload_id
      Added value: +{
      +  "type": "string"
      +}
    • addedInput schema / properties / upload_ids
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

The description discloses useful behavioral details beyond the annotations: signed/expiring FB CDN URLs, video URLs being fetched by Meta, curl commands keeping files out of AI context, upload_id flow, and bulk support. It does not contradict the readOnlyHint=false, idempotentHint=false, or destructiveHint=false annotations.

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?

The description is front-loaded with the action list and keeps important caveats near the relevant actions. It is longer than strictly necessary because it includes the full upload_image and upload_video behavior in get_upload_command, but the structure makes the information relatively scannable.

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?

There is no output schema, and while the action lines mention image hash and video_id, the description still lacks a clear statement of what exactly get_upload_command returns and which parameters should be passed for that specific action. Given the tool has many optional-looking parameters, the description is quite complete but not sufficient for fully confident invocation.

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?

The input schema has 12 parameters with zero descriptions, and the description only partially compensates. It explains public image_url, file_base64, upload_id, upload_code, video_url, and upload_ids, but it leaves title, account, file_name, file_path, and auth_account implicitly mapped at best. For a high-parameter tool with no schema descriptions, this is a meaningful coverage gap.

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 does identify a concrete purpose: uploading media to a Meta Ads account and getting a curl command for large local video files. However, it lists upload_image and upload_video as actions when this tool is supposedly the get_upload_command variant, so the scope is somewhat ambiguous and not fully differentiated from the sibling upload tools.

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

Usage Guidelines4/5

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

It provides usable guidance on how to pass files, when to call with no file, and warns that Facebook CDN links cannot be used server-side. It also points to meta_ads_media for listing media. It stops short of explicitly saying when to use this tool instead of the separate direct upload siblings, so it is clear but not fully complete.

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.

TDQS

B3/5.0
Disambiguation2/5

Many tools are near-identical variants of the same action, with only a `[Flattened action]` marker distinguishing e.g. the four `meta_ads_campaign_write_*` tools and the three `meta_ads_creative_write_*` tools. The reporting tools also overlap: `meta_ads_ads`, `meta_ads_realtime`, `meta_ads_today`, and `meta_ads_roas` all return spend/performance data, making selection genuinely ambiguous. Unrelated platform tools like `marketplace` and `toolkit_info` are mixed in, further muddying what the server is for.

Naming Consistency3/5

Most Meta Ads tools follow a readable `meta_ads_<resource>_<action>` snake_case convention, and write actions are reasonably predictable. However, there are inconsistencies: `meta_ads_ads` vs `meta_ads_audience`, `meta_ads_business_list` vs `meta_ads_business_accounts` vs `meta_ads_list_accounts`, and `meta_ads_adset_delete` vs the `meta_ads_adset_write_*` grouping. The unbranded platform tools (`connect`, `report_bug`, `show_version`) also break the pattern.

Tool Count2/5

44 tools is far above the recommended range and pushes the server into unwieldy territory. The count is inflated because flattened actions were expanded into separate tools: the campaign write tool appears four times, audience write twice, adset create/update twice, creative tools three times, media upload three times, and business/pages actions once per variant. A consolidated action-based design could reduce real surface area to roughly 15-20 tools.

Completeness4/5

The core Meta Ads lifecycle is well covered: campaigns, ad sets, creatives/ads, custom audiences, media upload, business managers, pages, and reporting all have create/read/update/delete or equivalent destinations. The main gaps are no direct `list_ad_sets` tool, no `remove_users` for audiences, and an apparent reference to a nonexistent `meta_ads_media` tool for listing uploaded media. These are noticeable but usually workaroundable.