Skip to main content
Glama
Sign In
facebook-mcp

facebook-mcp

by IvanBBaev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Like or unlike comments as the Page

facebook_like_comment
Idempotent

Like or unlike up to 50 Facebook comments as a Page; already-liked or not-liked comments are skipped and each comment ID gets its own result.

Instructions

Like up to 50 comments as the Page, or unlike them with unlike:true. Reversible with the opposite flag. A comment the Page has already liked (or, for unlike, has not liked) is skipped without a write; each id gets its own outcome. Needs a PAGE token with pages_manage_engagement.

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.
unlikeNotrue ⇒ remove the Page's like instead of adding one. Default false.
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).
comment_idsYesComment IDs to act on — 1 to 50 per call. Each id gets its own outcome, so one bad id does not fail the rest. Split larger sweeps into several calls.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.0

TDQS

A4.2/5.0
Behavior4/5

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

Adds real context beyond the annotations: idempotent skip-if-already-liked behavior, per-id partial failure ('each id gets its own outcome'), reversibility, and the exact permission (pages_manage_engagement with a PAGE token). The notable omission is any hint of the dry-run/`apply`/`plan_id` safety protocol, which is the most consequential behavior for a write tool.

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, zero waste, front-loaded with the action and the 50-comment scope. Every sentence carries a distinct operational fact (mode, reversibility, idempotency, per-id outcomes, auth).

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?

Covers batching limits, partial-failure semantics, auth requirements, and reversibility for a 5-param mutation tool with no output schema. The only missing piece is signaling that a write may not occur without `apply`/`plan_id`, which the description leaves entirely to the schema.

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 the schema already explains apply, plan_id, profile, unlike, and comment_ids fully. The description only echoes the `unlike` flag and the 50-id cap, both of which are already in the schema, and says nothing about apply/plan_id.

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 ('Like up to 50 comments as the Page, or unlike them') and immediately incorporates the mode flag. An agent can tell this apart from facebook_hide_comment, facebook_delete_comment, and facebook_reply_to_comment without opening the schema.

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?

'or unlike them with `unlike:true`' gives explicit mode selection, and the skip semantics tell the agent how to interpret no-op outcomes. However, it never names an alternative tool or says when to prefer this over other comment moderation tools, so a small inference gap remains.

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