Skip to main content
Glama
lmtNoLimit

mcp-facebook

by lmtNoLimit

facebook_schedule_post

Schedule a Facebook Page post for a future time by providing message text and an ISO 8601 datetime. Set publication between 10 minutes and 6 months ahead.

Instructions

Schedule a Facebook Page post for a future time. The scheduled_time must be between 10 minutes and 6 months from now (ISO 8601 format).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
linkNoOptional URL to attach to the post
messageYesThe text content of the post to schedule
scheduled_timeYesISO 8601 datetime string for when to publish (e.g. 2026-04-01T14:00:00Z). Must be 10 min to 6 months from now.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It restates the 10-minute-to-6-month window (already in the schema) but discloses nothing about required permissions, whether the scheduled post can later be edited or cancelled, rate limits, or what is returned. For a mutation tool with zero annotation coverage, this is a significant gap.

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?

Two short sentences with the core action front-loaded and the key constraint immediately after. No filler; every clause earns its place.

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?

Adequate at minimum: the action and the critical scheduling window are covered, and params are fully documented by the schema with no output schema to explain. However, for a write operation with no annotations, the description omits permissions, editability/cancellation, and success response behavior, leaving meaningful gaps.

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%, so all three parameters are already documented in the schema, including the ISO 8601 example and the time-window constraint. The description merely repeats the scheduled_time constraint and adds no syntax or format detail beyond the schema, 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?

States a specific verb (Schedule) and resource (Facebook Page post) with a clear temporal scope. The 'schedule for a future time' framing implicitly distinguishes it from the sibling facebook_create_post, but does not name or contrast the alternative explicitly.

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?

Usage is only implied: 'for a future time' hints at when this tool applies over immediate publishing. No explicit when-to-use, when-not-to-use, or reference to facebook_create_post as the alternative for immediate posts.

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