Skip to main content
Glama
Sign In
facebook-mcp

facebook-mcp

by IvanBBaev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create Video Post

facebook_create_video_post

Upload a video to a Facebook Page from a local file or HTTPS URL to create a draft or published video post; preview the write by default.

Instructions

Upload a video to a Page. A local path inside FB_MEDIA_DIR is streamed chunk-by-chunk through the resumable protocol (progress is reported); an https:// URL is handed to Meta to fetch. A completed upload is a CREATED video, not yet an encoded, published one. Dry run by default.

Input Schema

NameRequiredDescriptionDefault
applyNoSet true to actually perform the write. Omitted or false ⇒ the server decides from its configured write mode: usually a dry run that returns a plan preview and changes nothing, but a server (or package) configured apply-first performs the write. To be certain nothing happens, read the result: a dry run always reports the plan and says the write was NOT performed.
titleNoVideo title, shown in the video library.
videoYesThe video: a local file path inside FB_MEDIA_DIR (streamed from here, resumable, up to 256 MB) or an https:// URL Meta fetches from its own network.
plan_idNoThe `planId` returned by a preceding dry-run preview of this same tool. Required for irreversible and spend-tier writes; plans expire a few minutes after they are created.
profileNoPage profile key (e.g. "brand-a") or a raw Page ID. Omitted ⇒ the default Page (FB_PAGE_ID).
publishedNofalse ⇒ create the post UNPUBLISHED (a draft that stays invisible until facebook_update_post action:"publish_now"). Omitted or true ⇒ publish immediately. Must be omitted when scheduled_publish_time is set.
targetingNoWho sees the post in Feed: geo_locations and/or age_min. Narrows distribution only — the post stays publicly reachable by link and on the Page.
descriptionNoThe post text shown with the video (the video caption).
page_timezoneNoIANA timezone name of the Page (e.g. "Europe/Sofia"), used only to echo a scheduled instant in Page-local time next to UTC. Omitted ⇒ the server reads the Page's own timezone; if that read fails the echo is UTC-only.
scheduled_publish_timeNoWhen to publish, as an ISO-8601 instant WITH an explicit offset — "2026-08-01T09:30:00+03:00" or "2026-08-01T06:30:00Z". A bare local time ("2026-08-01T09:30:00") and a raw epoch number are both REFUSED, because they have no unambiguous meaning. Must be at least 10 minutes and at most 75 days ahead. Setting this creates the post unpublished; do NOT also pass published:true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.8.0
    • changedInput schema / properties / scheduled_publish_time / description
      Previous value: -"When to publish, as an ISO-8601 instant WITH an explicit offset — \"2026-08-01T09:30:00+03:00\" or \"2026-08-01T06:30:00Z\". A bare local time (\"2026-08-01T09:30:00\") and a raw epoch number are both REFUSED, because they have no unambiguous meaning. Must be more than 10 minutes and at most 75 days ahead. Setting this creates the post unpublished; do NOT also pass published:true."New value: +"When to publish, as an ISO-8601 instant WITH an explicit offset — \"2026-08-01T09:30:00+03:00\" or \"2026-08-01T06:30:00Z\". A bare local time (\"2026-08-01T09:30:00\") and a raw epoch number are both REFUSED, because they have no unambiguous meaning. Must be at least 10 minutes and at most 75 days ahead. Setting this creates the post unpublished; do NOT also pass published:true."
    • addedInput schema / properties / targeting
      Added value: +{
+  "additionalProperties": false,
+  "description": "Who sees the post in Feed: geo_locations and/or age_min. Narrows distribution only — the post stays publicly reachable by link and on the Page.",
+  "properties": {
+    "age_min": {
+      "anyOf": [
+        {
+          "const": 13,
+          "type": "number"
+        },
+        {
+          "const": 15,
+          "type": "number"
+        },
+        {
+          "const": 18,
+          "type": "number"
+        },
+        {
+          "const": 21,
+          "type": "number"
+        },
+        {
+          "const": 25,
+          "type": "number"
+        }
+      ],
+      "description": "Minimum viewer age: 13, 15, 18, 21 or 25."
+    },
+    "geo_locations": {
+      "additionalProperties": false,
+      "properties": {
+        "cities": {
+          "description": "City location ids as [{key:\"...\"}], from Ads Manager targeting search.",
+          "items": {
+            "additionalProperties": false,
+            "properties": {
+              "key": {
+                "pattern": "^\\d+$",
+                "type": "string"
+              }
+            },
+            "required": [
+              "key"
+            ],
+            "type": "object"
+          },
+          "maxItems": 250,
+          "type": "array"
+        },
+        "countries": {
+          "description": "Uppercase ISO country codes, e.g. [\"BG\",\"RO\"].",
+          "items": {
+            "pattern": "^[A-Z]{2}$",
+            "type": "string"
+          },
+          "maxItems": 25,
+          "minItems": 1,
+          "type": "array"
+        },
+        "regions": {
+          "description": "Region location ids as [{key:\"...\"}], from Ads Manager targeting search.",
+          "items": {
+            "additionalProperties": false,
+            "properties": {
+              "key": {
+                "pattern": "^\\d+$",
+                "type": "string"
+              }
+            },
+            "required": [
+              "key"
+            ],
+            "type": "object"
+          },
+          "maxItems": 200,
+          "type": "array"
+        }
+      },
+      "type": "object"
+    }
+  },
+  "type": "object"
+}
  2. First observedv0.7.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations only cover safety/openness, so the operational detail here is real added value: the resumable chunked protocol, progress reporting, the fact that URLs are fetched by Meta rather than streamed, and that a finished upload is still an unencoded asset. It does not warn that the call is non-idempotent (a retried upload can duplicate the video) nor explain the apply/plan_id write gate, both of which matter for a mutation tool.

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?

Three tight sentences with the core action front-loaded and no filler; the 'not yet encoded, published' clarification and the dry-run note are each doing work. Slightly under-structured — a fragment ('Dry run by default') closes it while the entire publish/draft axis goes unmentioned.

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 10-parameter, nested-object mutation with no output schema, the description covers the mechanics an agent most needs (upload path semantics, resumability, progress, resulting resource state, dry-run default). Gaps remain around the publish/draft/schedule axis and plan_id workflow, though the schema covers those thoroughly.

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 the schema already documents the local-path/URL duality, the 256 MB cap, published, scheduled_publish_time and targeting in more detail than the description. The description adds no per-parameter meaning beyond restating the video source modes, so baseline 3 applies.

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?

Specific verb and resource: 'Upload a video to a Page', and it explicitly clarifies the state transition ('a CREATED video, not yet an encoded, published one'). It never distinguishes itself from the obvious neighbours (facebook_create_reel, facebook_create_post, facebook_create_photo_post), so it stops short of a 5.

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?

'Dry run by default' and the local-path-vs-URL split imply when to reach for this tool, but there is no explicit when/when-not and no mention of facebook_create_reel as the alternative for short-form vertical video, nor of facebook_get_video_status after upload. Usage is inferable rather than stated.

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