Loading ToolBench
MCP server for automating and managing interactions on a Facebook Page using the Facebook Graph API
FacebookMCP shows consistent naming patterns and basic schema presence but suffers from critical gaps in parameter descriptions, output schema documentation, and error handling guidance. Of 30 tools analyzed, most follow verb_noun naming conventions (get_, post_, delete_, etc.) which is positive. However, parameter descriptions are minimal or absent across nearly all tools, e.g., post_to_facebook accepts 'message' with description 'The text message to post' (adequate), but tools like filter_negative_comments accept 'comments' with only 'Dictionary of comments to filter' (vague; what structure?). Output schemas are entirely undocumented, the code shows return type hints (dict[str, Any], list[dict[str, Any]], int) but no specification of what fields are in those dicts or what data the LLM should expect. Error handling is absent: no guidance on what errors can occur, whether they are retryable, or what the LLM should do next. The server uses FastMCP, which abstracts away detailed schema control, and type hints are present but shallow. Tools dealing with destructive operations (delete_post, delete_comment, delete_comment_from_post) lack any confirmation or dry-run mechanism. The toolset is large (30 tools) but many are narrowly-scoped analytics (get_post_reactions_like_total, get_post_reactions_love_total, etc.), suggesting missed composition opportunities, a single get_post_reactions() returning all reaction types would be more efficient. No tool annotations (readOnlyHint, destructiveHint) are visible in the code, despite the risk classification provided.
Delete a specific comment from the Page.
Alias to delete a comment on a post.
Delete a specific post from the Facebook Page.
Filter comments for basic negative sentiment.
Count the number of comments on a given post.
Return the number of likes on a post.
Get the Page's total fan/like count.
Output schemas completely undocumented. Tools return dict[str, Any] or list[dict[str, Any]] with no specification of field names, types, or structure. LLMs cannot plan downstream operations or extract required data without knowing what fields are present.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 25 | - | v1 |
Fetch the most recent posts on the Page.
Fetch number of post clicks.
Retrieve all comments for a given post.
Fetch number of engaged users.
Fetch total impressions of a post.
Fetch organic impressions of a post.
Fetch paid impressions of a post.
Fetch unique impressions of a post.
Fetch all insights metrics (impressions, reactions, clicks, etc).
Fetch number of 'Anger' reactions.
Fetch number of 'Haha' reactions.
Fetch number of 'Like' reactions.
Fetch number of 'Love' reactions.
Fetch number of 'Sorry' reactions.
Fetch number of 'Wow' reactions.
Get the number of shares for a post.
Get the top commenters on a post.
Post an image with a caption to the Facebook page.
Create a new Facebook Page post with a text message.
Reply to a specific comment on a Facebook post.
Schedule a new post for future publishing.
Send a direct message to a user.
Updates an existing post's message.
Parameter descriptions are vague or missing depth. Many parameters lack context on expected format, constraints, or valid values. E.g., 'comments' parameter in filter_negative_comments described only as 'Dictionary of comments to filter', no specification of structure, required keys, or expected comment format. LLMs cannot construct valid inputs without clearer guidance.
No error handling or recovery guidance. Tools provide no documentation of failure modes, whether errors are retryable, or what the LLM should do if a call fails. Critical for production reliability.
Destructive operations (delete_post, delete_comment, delete_comment_from_post) lack confirmation or dry-run mechanism. No pattern to prevent accidental deletion of posts or comments.
No tool annotations. Tools marked as DESTRUCTIVE, WRITE, or READ_ONLY in the risk classification but lacking readOnlyHint, destructiveHint, idempotentHint attributes in FastMCP registration. Prevents LLMs from understanding safety implications.
Redundant tools for similar analytics. Six separate tools for reaction types (get_post_reactions_like_total, get_post_reactions_love_total, ..., get_post_reactions_anger_total) could be consolidated into single get_post_reactions(post_id) returning all reaction counts. Current design forces the agent to make 6 calls to get complete reaction data instead of 1.
Missing pagination support. Tools like get_page_posts(), get_post_comments(), and get_post_top_commenters() return lists but no pagination parameters (limit, offset, cursor) or metadata (total_count, has_more). Large result sets risk context window exhaustion.
Tool naming clarity issue: 'delete_comment_from_post' is redundant given 'delete_comment' already exists. Parameter names don't make the distinction clear, both accept comment_id and (in one case) post_id. LLMs may conflate them. Consolidate or rename for clarity.