Facebook MCP Server
Provides tools for posting messages, replying to comments, retrieving posts and comments, filtering negative comments, and deleting posts/comments on a Facebook Page.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Facebook MCP Serverpost an update about our new product launch"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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
Configure Facebook Credentials:
Create a
.envfile in the root directory of your project.Add your Facebook Page access token and Page ID to the
.envfile:FACEBOOK_PAGE_ACCESS_TOKEN=YOUR_PAGE_ACCESS_TOKEN FACEBOOK_PAGE_ID=YOUR_PAGE_IDReplace
YOUR_PAGE_ACCESS_TOKENandYOUR_PAGE_IDwith your actual values.Important: Add
.envto your.gitignoreto avoid committing sensitive information.
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 toolsdelete_commentB
Deletes a comment from a post.
| Name | Required | Description | Default |
|---|---|---|---|
| comment_id | Yes | ID of the comment to delete. |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | ID of the post to delete. |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | ID of the post |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | ID of the post |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Message to post |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | ID of the post | |
| comment_id | Yes | ID of the comment | |
| message | Yes | Reply message |
TDQS
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.
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.
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.
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.
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.
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.
7 tool updates
v0.1.0- First observed
delete_comment - First observed
delete_post - First observed
filter_negative_comments - First observed
get_page_posts - First observed
get_post_comments - First observed
post_to_facebook - First observed
reply_to_comment
TDQS
Scored across 7 tools
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.
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.
With 7 tools, the set is well-scoped for managing Facebook Page content. It covers essential operations without unnecessary duplication or bloat.
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
Related MCP Connectors
MCP server for QPost — lets AI agents publish video and image posts to YouTube, TikTok, Instagram.
- MysocialOAuthio.mysocial
Social media MCP server: your Instagram, TikTok, YouTube, LinkedIn and Threads history for your AI.
A Model Context Protocol (MCP) server for Selise Blocks Cloud integration
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Related MCP Servers
- AlicenseNot gradedqualityFmaintenanceFacebook MCP server for automating posts, comment moderation, insights, and sentiment filtering.219PythonMIT
- AlicenseAqualityDmaintenanceMCP 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.4MIT
- AlicenseAqualityDmaintenanceMCP server for Facebook Pages that allows creating, scheduling, and deleting posts, managing comments, and retrieving Page insights using the Facebook Graph API.87 npmMIT
- AlicenseAqualityAmaintenanceA TypeScript MCP server for the Meta Graph API focused on Facebook Pages, enabling publishing, reading, insights, and moderation tasks.3028 npm1MIT