Skip to main content
Glama
tiroshanm

Facebook MCP Server

by tiroshanm

Facebook MCP Server

Overview

A Model Context Protocol (MCP) server implementation that provides Facebook Page interaction and management capabilities. This server enables automated posting, comment moderation, and content retrieval.

Related MCP server: io.github.anthonyjbolo/mcp-fb-publisher

Components

Tools

The server offers the following tools:

  • post_to_facebook:

    • Posts a message to the Facebook Page.

    • Input: message (string): The message to post.

  • reply_to_comment:

    • Replies to a comment on a specific post.

    • Input:

      • post_id (string): The ID of the post.

      • comment_id (string): The ID of the comment.

      • message (string): The reply message.

  • get_page_posts:

    • Retrieves posts published on the Facebook Page.

    • Input: None.

  • get_post_comments:

    • Retrieves comments for a specific post.

    • Input: post_id (string): The ID of the post.

  • filter_negative_comments:

    • Filters negative comments from a post based on keywords.

    • Input: post_id (string): The ID of the post.

  • delete_post:

    • Deletes a post from the Facebook Page.

    • Input: post_id (string): The ID of the post to delete.

  • delete_comment:

    • Deletes a comment from a post.

    • Input: comment_id (string): The ID of the comment to delete.

Setup

  1. Configure Facebook Credentials:

    • Create a .env file in the root directory of your project.

    • Add your Facebook Page access token and Page ID to the .env file:

      FACEBOOK_PAGE_ACCESS_TOKEN=YOUR_PAGE_ACCESS_TOKEN
      FACEBOOK_PAGE_ID=YOUR_PAGE_ID
    • Replace YOUR_PAGE_ACCESS_TOKEN and YOUR_PAGE_ID with your actual values.

    • Important: Add .env to your .gitignore to avoid committing sensitive information.

  2. Configure in Claude Desktop (or your MCP Client):

    • Configure your MCP client (e.g., Claude Desktop) to connect to the Facebook MCP server.

    • Example configuration for Claude Desktop (uv):

      {
        "mcpServers": {
            "facebook": {
                "command": "uv",
                "args": [
                    "--directory",
                    "/path/to/facebook-mcp-server",
                    "run",
                    "facebook-mcp-server"  
                ]
            }
        }
      }

Building

Comming Next.

License

This MCP server is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License. For more details, please see the LICENSE file in the project repository.

Available Tools

7 tools
delete_commentB

Deletes a comment from a post.

ParametersJSON Schema
NameRequiredDescriptionDefault
comment_idYesID of the comment to delete.

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It only states the operation without revealing permanent effects, permission requirements, or error conditions (e.g., if comment doesn't exist).

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 a single concise sentence with no fluff. It is front-loaded with the verb. However, it might be too brief for full clarity.

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?

For a simple deletion tool with one parameter and no output schema, the description is minimally adequate but lacks side effects or prerequisite info (e.g., comment must exist).

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% and the description adds no new parameter meaning beyond the schema's 'ID of the comment to delete.' Baseline score of 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?

The description clearly states the action ('Deletes') and the resource ('a comment from a post'), and it distinguishes from siblings like 'delete_post' (deletes whole post) and 'get_post_comments' (read-only).

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs. alternatives (e.g., 'delete_post' or 'filter_negative_comments'). No contexts or limitations are provided.

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

delete_postC

Deletes a post from the Facebook Page.

ParametersJSON Schema
NameRequiredDescriptionDefault
post_idYesID of the post to delete.

TDQS

C2.8/5.0
Behavior2/5

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

No annotations provided, and description only says 'deletes' without disclosing side effects, irreversibility, or required permissions. For a destructive action, more detail is needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is concise but too sparse, missing important context. Could be more informative without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Missing behavioral details and usage guidance. Even for a simple tool, the description is too minimal to fully inform an agent about consequences and prerequisites.

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 baseline is 3. Description adds no extra meaning beyond the schema's parameter description for post_id.

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?

Description clearly states the action (deletes) and resource (post from Facebook Page). It is specific and unambiguous, but does not distinguish from sibling delete_comment.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like delete_comment. No when-to-use or when-not-to-use context provided.

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

filter_negative_commentsB

Filters negative comments from a post

ParametersJSON Schema
NameRequiredDescriptionDefault
post_idYesID of the post

TDQS

B3.2/5.0
Behavior2/5

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

No annotations provided, so the description carries the full burden. It does not disclose what 'filter' means—whether it returns a list, deletes, or marks comments. The behavior is ambiguous.

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?

Single sentence, no unnecessary words. Highly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite low complexity (one parameter, no output schema), the description is too minimal. It lacks details on return value, side effects, or prerequisites, leaving the agent uncertain about the tool's operation.

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% with a clear description for post_id. The tool description adds no additional parameter meaning beyond the schema, so baseline 3 is appropriate.

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?

The description 'Filters negative comments from a post' clearly states the action (filter), the resource (negative comments), and the context (from a post). It distinguishes from siblings like get_post_comments and delete_comment.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. The description does not mention when not to use it or suggest other tools for different needs, such as get_post_comments for all comments.

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

get_page_postsC

Retrieves posts published on the Facebook Page

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.9/5.0
Behavior1/5

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

No annotations are provided, and the description offers no information about behavioral traits such as pagination, rate limits, authentication needs, or whether it returns all posts or only a subset. This is a critical gap for an API tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise—a single sentence of seven words. While it is front-loaded and without waste, it is under-specified and fails to provide necessary detail for effective use.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema) and the presence of sibling tools, the description is insufficient. It omits crucial details like return format, pagination, or any filtering capabilities, leaving the agent with incomplete context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, and schema coverage is 100% (all zero). According to the rubric, a baseline of 4 is appropriate since the description adds no additional meaning beyond the schema, but no meaning is needed.

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?

The description clearly states the action ('Retrieves') and the resource ('posts published on the Facebook Page'). It effectively distinguishes from sibling tools that deal with deleting, commenting, or filtering posts.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. Even though it's the only retrieval tool among siblings, the description does not explicitly state its purpose or provide context for when it should be chosen.

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

get_post_commentsB

Retrieves comments for a specific post

ParametersJSON Schema
NameRequiredDescriptionDefault
post_idYesID of the post

TDQS

B3.1/5.0
Behavior3/5

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

No annotations are provided. The description implies a read-only operation ('Retrieves'), which is correct. But it lacks details on pagination, ordering, or return structure. Adequate but minimal.

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 a single concise sentence with no waste. However, it could be expanded slightly to include return type or usage hints without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and simple operation, the description should explain what is returned (e.g., list of comments). It does not, leaving the agent uninformed about the response format.

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% (post_id described). The tool description adds no extra meaning to the parameter; baseline 3 is appropriate.

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 clearly states the tool retrieves comments for a specific post, with a clear verb and resource. However, it does not differentiate from sibling tools like 'filter_negative_comments' or 'reply_to_comment', so not 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 Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives. No context about prerequisites or exclusions. The description is too brief to inform decision-making.

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

post_to_facebookC

Posts a message to the Facebook Page

ParametersJSON Schema
NameRequiredDescriptionDefault
messageYesMessage to post

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description must disclose traits. It only says 'posts a message' without mentioning potential rate limits, character limits, permission requirements, or side effects like overwriting previous posts.

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 a single sentence with the verb first. It is concise and to the point, though slightly more structure could be added without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and a mutation operation, the description lacks details on return values, error conditions, and behavioral constraints (e.g., character limits). This makes it insufficient for an agent to fully assess the tool's usage.

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% and the parameter description 'Message to post' is adequate. The tool description adds no additional semantic value, which is acceptable for a single, simple parameter.

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 clearly states the action ('posts') and resource ('message to the Facebook Page'), distinguishing it from sibling tools that delete, filter, get, or reply. However, it does not specify which Facebook Page, assuming context.

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

Usage Guidelines2/5

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

No guidance on when or when not to use this tool versus alternatives. There is no mention of prerequisites, such as needing an authenticated session or a specific page ID.

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

reply_to_commentC

Replies to a comment on a specific post

ParametersJSON Schema
NameRequiredDescriptionDefault
post_idYesID of the post
comment_idYesID of the comment
messageYesReply message

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations and no behavioral details in the description, the agent learns nothing about side effects (e.g., whether it notifies users, requires authentication, or has rate limits). This is a significant gap 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that efficiently conveys the core function without any redundant or irrelevant information. It is well-structured and to the point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and annotations, the description fails to cover what happens after a reply (e.g., visibility, editing, or deletion possibilities). It omits necessary context for safe and effective use.

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 schema provides 100% coverage with descriptions for each parameter, but those descriptions are minimal (e.g., 'ID of the post') and add little beyond the parameter names. Per guidelines, high coverage yields a baseline of 3, though the descriptions don't enhance understanding.

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 clearly states the action ('Replies') and the resource ('a comment on a specific post'), making the tool's purpose immediately understandable. It also stands out from sibling tools like delete_comment and filter_negative_comments, though it doesn't explicitly contrast them.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as filter_negative_comments or get_post_comments. There are no prerequisites, usage contexts, or exclusions mentioned, leaving the agent to infer usage.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 7 tool updatesv0.1.0
    • First observeddelete_comment
    • First observeddelete_post
    • First observedfilter_negative_comments
    • First observedget_page_posts
    • First observedget_post_comments
    • First observedpost_to_facebook
    • First observedreply_to_comment

TDQS

A3.5/5.0

Scored across 7 tools

Disambiguation5/5

All 7 tools serve distinct and clearly defined purposes, with no overlap. Each tool targets a specific action on a specific resource (posts or comments), making selection unambiguous.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., delete_comment, get_page_posts), providing a predictable and logical naming scheme.

Tool Count5/5

With 7 tools, the set is well-scoped for managing Facebook Page content. It covers essential operations without unnecessary duplication or bloat.

Completeness4/5

The tool set covers create, read, and delete for posts and comments, plus filtering and replying. The only notable gap is the absence of update operations (e.g., update_post, update_comment), but the core workflow is supported.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    D
    maintenance
    MCP server to safely publish posts to multiple Facebook Pages via Meta Graph API, with built-in guardrails for brand voice, banned topics, image requirements, and anti-duplication.
    4
    MIT
  • A
    license
    A
    quality
    D
    maintenance
    MCP server for Facebook Pages that allows creating, scheduling, and deleting posts, managing comments, and retrieving Page insights using the Facebook Graph API.
    8
    7 npm
    MIT
  • A
    license
    A
    quality
    A
    maintenance
    A TypeScript MCP server for the Meta Graph API focused on Facebook Pages, enabling publishing, reading, insights, and moderation tasks.
    30
    28 npm
    1
    MIT