Provides tools for managing Facebook accounts, campaigns, and lead collections, including the ability to scrape groups and pages for lead generation.
Enables interaction with messaging features, allowing users to view conversations, search through messages, and send messages directly.
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., "@MessengerFlow MCP Server Show my active campaigns and today's lead performance."
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.
MCP server for MessengerFlow — manage campaigns, accounts, leads, inbox, and analytics from AI assistants like Claude Desktop.
Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"messengerflow": {
"command": "npx",
"args": ["@messengerflow/mcp-server"],
"env": {
"MESSENGERFLOW_API_KEY": "mf_your_key_here"
}
}
}
}No API key needed — authenticates with your MessengerFlow account:
{
"mcpServers": {
"messengerflow": {
"url": "https://mcp.messengerflow.com/mcp"
}
}
}cd mcp
npm install
MESSENGERFLOW_API_KEY=mf_your_key npm run devRelated MCP server: Meta Marketing API MCP Server
Variable | Required | Default | Description |
| Yes | — | API key (starts with |
| No |
| API base URL |
To get your API key:
Log in to app.messengerflow.com
Go to Settings > API Keys
Click Create API Key and copy the key (starts with mf_)
Tool | Description |
| Create, update, start/stop, delete campaigns. View leads and activity. |
| Add, update, delete Facebook accounts. View stats and logs. |
| Import CSV, scrape groups/pages, merge, export lead collections. |
| View conversations, search, send messages, manage read status. |
| Dashboard stats, activity charts, performance metrics. |
URI | Description |
| Dashboard stats |
"List my campaigns"
"Show dashboard stats"
"How many unread messages do I have?"
"Create a new campaign called 'Spring Launch'"
"Export leads from collection X"
npm run build # Outputs to dist/
npm start # Run built versionGet dashboard stats, activity charts, performance metrics, and message/booking charts.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform | |
| period | No | Time period filter (e.g. "7d", "30d") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Get', implying read-only, but does not mention permissions, output format, or any side effects. This is minimal disclosure even for a read operation.
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, front-loaded sentence that directly lists the data types. There is no filler or redundancy, making it an efficient and effective description.
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 simple tool shape and full schema coverage, the description is adequate but not thorough. It lacks use case guidance, output shape, and any caveats, and no output schema or annotations exist to fill the gaps. For a read-only analytics tool this may be acceptable, but it is not comprehensive.
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 already fully describes both parameters. The description adds human-readable labels for the action enum values, such as 'dashboard stats' mapping to 'dashboard_stats'. This provides semantic context beyond the generic schema descriptions.
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 analytics data, listing specific chart/stat categories. The verb 'Get' and the resource 'analytics' make the purpose evident. It differentiates from sibling 'manage_*' tools, though it does not explicitly reference 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?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It only restates the function in terms of data categories, leaving usage context implicit at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add, update, and delete Facebook accounts. View account stats and logs.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Account ID (required for get/update/delete/get_stats/get_logs) | |
| data | No | Request body for add/update actions | |
| limit | No | Pagination limit | |
| action | Yes | Action to perform | |
| offset | No | Pagination offset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It mentions mutating actions (add/update/delete) and read actions (view stats/logs), but does not disclose potential side effects (e.g., permanent deletion), permission requirements, or pagination behavior. This is a significant gap for a tool that can delete data.
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 concise, using two short sentences that front-load the main actions. However, it omits the 'list' and 'get' actions and could list all actions for completeness without becoming overly long. It is efficient but slightly incomplete in scope.
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 this is a multi-action tool with five parameters, nested objects, and no output schema, the description is too brief to be contextually complete. It does not explain the meaning of stats/logs, the behavior of pagination parameters (offset/limit), or the return format. The description needs more detail to compensate for the lack of annotations and output schema.
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 documents all five parameters with descriptions, reaching 100% coverage, so the baseline is 3. The description adds no extra parameter details, but it does align with the schema by implying 'data' is used for add/update. No additional semantics beyond the schema are provided.
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 identifies the tool's primary functions: adding, updating, deleting, and viewing stats/logs for Facebook accounts. It distinguishes itself from sibling tools by pointing to the 'accounts' resource. However, it omits the 'list' and 'get' actions present in the enum, so it is not fully complete.
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?
The description provides no guidance on when to use this tool versus alternatives like manage_campaigns or get_analytics. It does not mention exclusions, prerequisites, or preferred scenarios. The usage is only implicitly suggested by the resource name (accounts).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create, update, start, stop, and delete campaigns. View campaign leads and activity. Manage campaign account assignments.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Campaign ID (required for get/update/start/stop/delete/get_leads/get_activity) | |
| data | No | Request body for create/update actions | |
| limit | No | Pagination limit | |
| action | Yes | Action to perform | |
| offset | No | Pagination offset | |
| search | No | Search query | |
| account_id | No | Account ID for add_account/remove_account |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions actions like delete and start/stop but does not disclose side effects (e.g., permanence of delete, permission requirements, whether account assignments are replaced or appended). This is a significant gap for a tool with mutable operations.
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 that front-loads the primary actions. It covers all key capabilities without wasted words, making it appropriately sized. It could be better structured (e.g., bullet-like clarity) but is efficient.
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?
The tool is complex (12 actions, 7 parameters, no output schema) yet the description is a high-level list. It does not explain return values, pagination behavior, or action-specific requirements, leaving the agent under-informed for correctly invoking the tool. The absence of an output schema increases the need for description detail, which is missing.
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% (all 7 parameters have descriptions), so the baseline is 3. The description adds no parameter-level detail beyond the schema, but it does not need to since the schema is thorough. It does, however, connect actions like get_leads and add_account to the campaign context, providing slight added context.
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 lists specific actions (create, update, start, stop, delete) and resources (campaigns, leads, activity, account assignments), making the tool's purpose clear. However, it doesn't explicitly contrast with sibling tools like manage_leads or manage_accounts, so it doesn't fully distinguish itself beyond the campaign resource.
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 given on when to choose this tool over its siblings (manage_accounts, manage_leads, manage_inbox). The description implies campaign-related tasks but offers no alternative scenarios or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View conversations, search messages, send replies, mark read/unread, and delete conversations.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Conversation ID (required for get_messages/update) | |
| data | No | Request body for send_message/update/delete actions | |
| limit | No | Pagination limit | |
| query | No | Search query for search action | |
| action | Yes | Action to perform | |
| offset | No | Pagination offset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does not mention whether deletes are permanent, if replies need authentication, rate limits, or any side effects. The mutating actions are listed but without qualification.
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 one compact, front-loaded sentence. It wastes no words but could be improved by specifying the tool's overall purpose in a single phrase.
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 a complex schema with 6 params, nested objects, and 7 actions, the description only lists actions. It does not clarify which parameters are relevant per action, how the data object should be structured, or what response formats to expect. For a tool with no output schema, this is insufficient.
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 the baseline is 3. The description adds no extra meaning to parameters; it restates the action enum in prose but nothing about id/data/query semantics beyond schema.
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 lists specific actions ('View conversations, search messages, send replies, mark read/unread, and delete conversations') with clear verb+resource pairs. It unambiguously distinguishes this tool from siblings like manage_campaigns and get_analytics.
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?
The enumerated actions imply the tool's context as a central inbox manager, and sibling tool names clearly separate concerns. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage lead collections — import CSV, scrape groups/pages, merge, rename, delete, export. Browse individual leads within a collection.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Collection ID (required for get_collection/rename/delete/get_leads/export/rescrape/retry) | |
| data | No | Request body for import/scrape/merge/rename actions | |
| limit | No | Pagination limit | |
| action | Yes | Action to perform | |
| offset | No | Pagination offset | |
| search | No | Search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It mentions potentially destructive actions like delete and merge but does not explain consequences such as irreversibility, overwrite behavior, or required permissions. No information about authentication, rate limits, or response handling is provided.
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, front-loaded sentence that efficiently lists the tool's capabilities without redundancy. It is compact, scannable, and every word contributes to conveying the purpose and scope.
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?
The tool is complex with 12 actions, a nested data object, and pagination parameters, yet the description only lists actions without explaining semantics or usage contexts. Critical details like what 'scrape_group' does, what 'retry' refers to, and the format of 'data' are missing, leaving the description inadequate for correct invocation across all actions.
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 descriptions for all six parameters, giving 100% coverage, so the baseline is 3. The description adds no parameter-level detail beyond listing the actions, which mirror the enum. It does not clarify the structure of the 'data' object or which actions require 'id', so it fails to augment the schema meaningfully.
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 manages lead collections and enumerates specific operations such as import CSV, scrape groups/pages, merge, rename, delete, and export. This distinguishes it from sibling tools like manage_campaigns and manage_inbox by resource type, despite the generic verb 'manage'.
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?
The description implies usage for lead collection management but provides no explicit guidance on when to use this tool versus alternatives. It does not mention sibling tools or any exclusions, leaving the agent to infer the tool's role from the action list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.4get_analyticsmanage_accountsmanage_campaignsmanage_inboxmanage_leadsScored across 5 tools
Each tool has a clearly distinct primary responsibility: campaigns, accounts, leads, inbox, and analytics. However, manage_campaigns includes viewing leads and activity, which overlaps somewhat with manage_leads and get_analytics, and manage_accounts includes stats and logs, which also touches analytics. This slight overlap may cause occasional ambiguity but is not severe.
All tool names follow a consistent verb_noun pattern: manage_* for operational tools and get_analytics for data retrieval. The prefix 'manage' uniformly covers CRUD-like operations across different resources, and 'get' clearly signals a read-only analytics function. This is highly predictable.
With 5 tools, the server is well-scoped for a messaging campaign platform. Each tool represents a major functional area (campaigns, accounts, leads, inbox, analytics) without fragmentation or bloat. This is within the ideal range for clarity and maintainability.
The tool set covers the core lifecycle needs for the domain: campaigns can be created, updated, started, stopped, and deleted; accounts are fully manageable; leads support import, merge, rename, delete, export, and browsing; inbox handles conversations comprehensively; analytics provides dashboard and performance data. No obvious missing operations are apparent for the intended purpose.
60+ Meta Ads tools for AI agents: audits, campaign management, audiences and CAPI tracking.
Run B2B outreach from your AI agent: 250+ tools for campaigns, leads, LinkedIn and email workflows.
AI marketing agent for paid social: Meta ads campaigns, ad creative generation, lead delivery.
Give AI agents the LinkedIn tools to find, qualify, engage, and follow up with prospects.
