This server gives AI assistants access to the RecurPost social media management API for managing accounts, content, and posting.
Verify RecurPost API credentials
List workspaces, connected social accounts, and content libraries
Get URLs to connect new social media accounts
Post content immediately or schedule it for a future time
Add content to libraries for recurring/evergreen posting
View posting history with engagement metrics for a social account
Generate social media post text with AI, including multi-turn conversations
Generate images from text descriptions with AI
Support platform-specific options for Facebook, Instagram, LinkedIn, Twitter/X, Pinterest, TikTok, YouTube, Threads, Bluesky, and Google Business Profile
Scope actions and lists to a specific workspace using a workspace ID
Provides tools to manage social media content, allowing users to schedule or immediately post content to Facebook pages, manage content libraries for recurring posting, and view posting history with engagement metrics.
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., "@RecurPost MCP Server Schedule a LinkedIn post about productivity for next Monday at 9 AM."
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.
An MCP (Model Context Protocol) server that gives AI assistants access to the RecurPost social media management API.
List connected social accounts and content libraries
List workspaces and work inside any workspace you're a member of
Post content immediately or schedule it for later
Add content to libraries for recurring/evergreen posting
View posting history with engagement metrics
Generate social media content and images with AI
Get URLs to connect new social media accounts
Related MCP server: Ayrshare Unofficial MCP Server
Log in to RecurPost
Go to Account Settings
Generate an API Password Key (this is not your login password)
Works on macOS and Windows. Nothing else to install: Claude Desktop runs the extension with its own built-in Node.js.
Download recurpost.mcpb.
Double-click the file (or drag it onto Settings > Extensions in Claude Desktop) and click Install.
Enter your RecurPost email and API Password Key when asked. The key is stored in your operating system's keychain, not in a plain text file.
The RecurPost tools are available in a new chat straight away. To update, download the latest file and install it again.
The manual routes below need Node.js 18 or newer. Download the LTS installer
from https://nodejs.org if node -v in a terminal does not print a version.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"recurpost": {
"command": "npx",
"args": ["-y", "recurpost-mcp"],
"env": {
"RECURPOST_EMAIL": "your-email@example.com",
"RECURPOST_API_KEY": "your-api-key"
}
}
}
}Quit Claude Desktop completely (Cmd+Q, not just the window) and reopen it.
Do not use npx on Windows. Windows has no npx executable (only
npx.cmd, which Claude Desktop cannot launch), and even through cmd /c
the first-run package download routinely takes longer than the 60-second
handshake limit, so the server shows as "running" while every call fails.
Install the package once, then point Claude Desktop straight at it:
Open Command Prompt and run:
npm install -g recurpost-mcpFind where it landed. This prints the global folder:
npm root -gIt is normally C:\Users\YOUR-USERNAME\AppData\Roaming\npm\node_modules.
Quit Claude Desktop fully first. Closing the window is not enough:
right-click the Claude icon in the system tray and choose Quit, or end
every Claude.exe in Task Manager. The app rewrites its config file on
exit and will discard edits made while it is running.
Open %APPDATA%\Claude\claude_desktop_config.json and add, using the
folder from step 2 and double backslashes exactly as shown:
{
"mcpServers": {
"recurpost": {
"command": "C:\\Program Files\\nodejs\\node.exe",
"args": [
"C:\\Users\\YOUR-USERNAME\\AppData\\Roaming\\npm\\node_modules\\recurpost-mcp\\build\\index.js"
],
"env": {
"RECURPOST_EMAIL": "your-email@example.com",
"RECURPOST_API_KEY": "your-api-key"
}
}
}
}If you save with Notepad, set Save as type to All Files (or it
silently adds .txt) and Encoding to UTF-8, not UTF-8 with BOM.
Start Claude Desktop. The tools appear within a couple of seconds.
claude mcp add recurpost --scope user \
-e RECURPOST_EMAIL=your-email@example.com \
-e RECURPOST_API_KEY=your-api-key \
-- npx -y recurpost-mcpOne line (the backslash line breaks above are bash-only). After
npm install -g recurpost-mcp:
claude mcp add recurpost --scope user -e RECURPOST_EMAIL=your-email@example.com -e RECURPOST_API_KEY=your-api-key -- "C:\Program Files\nodejs\node.exe" "C:\Users\YOUR-USERNAME\AppData\Roaming\npm\node_modules\recurpost-mcp\build\index.js"On every platform the -e flags must come before --. Anything after --
is passed to the server command, so the server would start without
credentials. --scope user makes the server available in every project;
omit it to add it to the current project only.
Ask: "Verify my RecurPost connection" (runs user_login), then
"Show me all my connected social accounts".
Claude Desktop writes a log per server:
macOS: ~/Library/Logs/Claude/mcp-server-recurpost.log
Windows: %APPDATA%\Claude\logs\mcp-server-recurpost.log
What you see | Cause | Fix |
Server not listed under Settings > Developer at all, no log file | Config never read: saved as | Re-save as All Files / UTF-8; quit Claude fully before editing |
Log says | Windows cannot launch | Use the Windows config above ( |
Server shows as running, log says |
| Same fix: global install, launch with |
Tool result says | The spawned process has no working network | Check VPN/proxy/antivirus; if |
| Credentials not in | Move them into the |
Tool | Description |
| Verify your API credentials |
| List all workspaces you're a member of (own and shared) |
| List all connected social media accounts |
| List all content libraries |
| Get URLs to connect new social accounts |
| Get posting history for a social account |
| Post or schedule content to a social account |
| Add content to a library for recurring posting |
| Generate social media post text with AI |
| Generate images from text descriptions |
social_account_list, library_list, history_data, post_content, and add_content_in_library accept an optional workspace_id (a ws_id from workspace_list). When omitted, your default workspace is used. When provided, results and actions are scoped to that workspace — social accounts and libraries must belong to it.
"Show me all my connected social accounts"
"Schedule a post about our summer sale on my Facebook page for tomorrow at 9am"
"Generate a LinkedIn post about remote work productivity tips"
"What posts went out on my Twitter account this week?"
"Add 5 evergreen tips about social media marketing to my Tips library"
"List my workspaces, then show the social accounts in the Client A workspace"
Your credentials are stored in your local config and never leave your machine except to authenticate directly with the RecurPost API
The server runs locally as a subprocess — no external servers involved
API key and email are passed via environment variables, never exposed to the AI model
MIT
Add a post to a content library for recurring/evergreen posting
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Library ID (from library_list) | |
| url | No | Website link to include | |
| gbp_cta | No | Google Business Profile call to action | |
| message | Yes | Default post content text | |
| pi_title | No | Pinterest pin title | |
| yt_thumb | No | YouTube custom thumbnail URL | |
| yt_title | No | YouTube video title | |
| image_url | No | Array of image URLs to attach | |
| video_url | No | Public video URL to attach | |
| bs_message | No | Bluesky-specific message override | |
| fb_message | No | Facebook-specific message override | |
| in_message | No | Instagram-specific message override | |
| ln_message | No | LinkedIn-specific message override | |
| pi_message | No | Pinterest-specific message override | |
| th_message | No | Threads-specific message override | |
| tk_message | No | TikTok-specific message override | |
| tw_message | No | Twitter/X-specific message override | |
| yt_message | No | YouTube-specific message override | |
| gbp_cta_url | No | Google Business Profile CTA URL | |
| gmb_message | No | Google Business Profile-specific message override | |
| ln_document | No | LinkedIn document URL (PPT/PDF/DOCX) | |
| yt_category | No | YouTube video category | |
| fb_post_type | No | Facebook post type | |
| in_post_type | No | Instagram post type | |
| workspace_id | No | Workspace ID (ws_id from workspace_list). Omit to use your default workspace. | |
| yt_user_tags | No | YouTube tags | |
| first_comment | No | Default first comment | |
| tk_allow_duet | No | Allow TikTok duets | |
| gbp_offer_terms | No | GBP offer terms and conditions | |
| gbp_offer_title | No | GBP offer title | |
| is_top_of_queue | No | Add to top of queue (1) or bottom (0) | |
| content_livedate | No | Content live date (YYYY-MM-DD) | |
| fb_first_comment | No | Facebook first comment | |
| in_first_comment | No | Instagram first comment | |
| ln_first_comment | No | LinkedIn first comment | |
| ln_document_title | No | LinkedIn document title | |
| tk_allow_comments | No | Allow TikTok comments | |
| tk_allow_stitches | No | Allow TikTok stitches | |
| tk_privacy_status | No | TikTok privacy status | |
| yt_privacy_status | No | YouTube privacy status | |
| content_expiredate | No | Content expiry date (YYYY-MM-DD) | |
| gbp_offer_end_date | No | GBP offer end date | |
| gbp_offer_start_date | No | GBP offer start date | |
| gbp_offer_coupon_code | No | GBP offer coupon code | |
| gbp_redeem_offer_link | No | GBP offer redemption URL | |
| in_reel_share_in_feed | No | Share Instagram reel in feed | |
| yt_video_made_for_kids | No | Is the YouTube video made for kids | |
| host_images_on_recurpost | No | Host images on RecurPost (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'Add a post', which implies a write operation but doesn't mention any side effects, authentication requirements, return values, or the fact that content is queued for future posting. For a tool with 48 parameters, this is a significant transparency gap.
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 core purpose. It's efficient with no filler, but it's so brief that it omits important contextual details. The structure is appropriate for the clarity it provides, but the extreme brevity hurts completeness.
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 tool with 48 parameters, no output schema, and no annotations, the description is far too minimal. It doesn't explain the workflow (e.g., that content is stored for recurring posting), how to obtain the required library_id (from library_list), the optional workspace_id behavior, or what the response indicates about success. An agent would need to rely entirely on the schema and sibling tools to understand the full 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 schema has 100% description coverage for all 48 parameters, each with a clear description. The tool description itself adds no additional meaning beyond what the schema provides. Since the schema already documents parameters well, the description's lack of parameter information is acceptable, though it doesn't add value beyond the 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 clearly states the action (add a post) and the target resource (content library), and specifies the purpose (recurring/evergreen posting). This distinguishes it from sibling tools like library_list (listing libraries) and post_content (immediate posting), even without naming 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 implies the tool is for adding content to a library for later posting, but it doesn't explicitly state when to use this versus alternatives like post_content or generate_content_with_ai. There's no mention of prerequisites such as needing a library_id from library_list, or when to choose this over direct posting. The intent is inferable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get URLs to connect new social media accounts to RecurPost
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fails to disclose whether this creates server-side state (pending connections), URL expiration behavior, or specific platform requirements. Only states it returns URLs.
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, front-loaded with verb, zero waste. Appropriate length for the tool's simplicity.
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?
No output schema exists, so description should ideally elaborate on the URL format, quantity, or usage instructions. It mentions URLs but lacks critical details expected when return structure is undefined.
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?
Zero parameters present. Per scoring rules, this establishes a baseline of 4 with no deductions needed. The description does not need to compensate for missing parameter documentation.
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?
Clear verb 'Get' and resource 'URLs to connect new social media accounts', but lacks specificity about what type of URLs (OAuth, authentication) and doesn't explicitly differentiate from the sibling 'social_account_list'.
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 explicit guidance on when to use this tool versus 'social_account_list' or prerequisites for account connection. The 'new' qualifier provides minimal implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate social media content text using RecurPost AI. Supports multi-turn conversations via ai_id.
| Name | Required | Description | Default |
|---|---|---|---|
| ai_id | No | AI conversation ID from a previous response, for follow-up turns | |
| prompt_text | Yes | Topic or text to generate content about | |
| chat_progress | No | Chat progress marker from a previous response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It successfully explains the conversational state management (multi-turn via ai_id), but omits safety-critical details such as rate limits, whether generation is billable, or if content is automatically persisted versus just returned.
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?
Two efficiently constructed sentences. The first front-loads the core purpose, while the second adds the essential multi-turn context. Zero duplication of schema details or redundant filler.
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 schema's rich parameter documentation (100% coverage) and the tool's moderate complexity, the description covers the essential behavioral context (AI generation, conversation continuity). It effectively compensates for the missing output schema by implying the conversational cycle through parameter descriptions, though it could explicitly mention that the response contains new ai_id/chat_progress values for subsequent calls.
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?
While the schema has 100% description coverage (baseline 3), the description adds valuable semantic context by framing ai_id and chat_progress within the 'multi-turn conversation' workflow, helping the agent understand these parameters form a conversation state protocol.
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 specific action (Generate), resource (social media content text), and mechanism (using RecurPost AI). It distinguishes from the sibling 'generate_image_with_ai' by explicitly specifying 'text' content.
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 implicit usage guidance by explaining that ai_id enables 'multi-turn conversations,' indicating when to populate that parameter. However, it lacks explicit guidance on when to use this tool versus siblings like 'generate_image_with_ai' or prerequisites like authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an image from a text description using RecurPost AI
| Name | Required | Description | Default |
|---|---|---|---|
| prompt_text | Yes | Detailed description of the image to generate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. Missing critical behavioral details: output format (URL, base64, file ID?), synchronous vs async behavior, API limits, content policy restrictions, and whether results persist in the RecurPost ecosystem.
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, front-loaded with action verb, no redundant words. Efficiently communicates core purpose, though minimalism contributes to lack of necessary behavioral context.
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 an image generation tool with no output schema and no annotations, the description should disclose return behavior, side effects, and storage implications. Currently insufficient for an agent to predict outcomes, handle errors, or integrate the result into subsequent workflow steps.
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 prompt_text adequately described. Description mentions 'text description' which aligns with the parameter, but adds no additional syntax constraints, prompt engineering guidance, or formatting examples beyond what the schema provides. Baseline 3 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?
Clearly states the verb (Generate), resource (image), and method (using RecurPost AI). Implicitly distinguishes from sibling generate_content_with_ai by specifying 'image' versus generic 'content', though lacks explicit scope constraints or differentiating guidance.
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 provided on when to use this tool versus generate_content_with_ai, prerequisites for image generation, or how to handle results. Fails to mention if generated images are automatically stored in the library or require separate ingestion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get posting history for a social account (max 100 posts per request)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Social account ID (from social_account_list) | |
| end_date | No | End date in YYYY-MM-DD HH:MM:SS format | |
| start_date | No | Start date in YYYY-MM-DD HH:MM:SS format | |
| workspace_id | No | Workspace ID (ws_id from workspace_list). Omit to use your default workspace. | |
| is_get_video_updates | No | Include video update metrics (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full behavioral burden. It does disclose a rate/limit constraint ('max 100 posts per request'), but it does not mention pagination, response shape, error behavior, or authentication requirements. This is too thin for a tool with zero annotation support.
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 states the action, target, and key constraint without filler. Every part earns its place.
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 schema covers parameter semantics well, and the core purpose is clear. However, with no output schema and no annotations, the description does not explain the return structure, how to fetch beyond 100 posts, or how date-range and video-update flags affect the result. These are meaningful gaps for a history-retrieval tool.
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?
All five parameters are documented in the schema, including source hints ('from social_account_list'), date formats, and defaults. The free-text description adds no parameter-level meaning beyond the schema, so the baseline 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 uses a specific verb ('Get') and resource ('posting history for a social account'), making the tool's function clear. It also adds a concrete limit ('max 100 posts per request'), but it does not explicitly differentiate from sibling tools, though none obviously overlaps.
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 clearly implies when to use the tool: when posting history for a social account is needed. It does not state exclusions or name alternatives, but among the listed siblings, none appears to provide the same history-retrieval function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all content libraries with their IDs
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | No | Workspace ID (ws_id from workspace_list). Omit to use your default workspace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. 'List' implies a read-only operation with no side effects, which is reasonable, but the description does not explicitly confirm safety, mention any permissions, rate limits, or pagination behavior. It adds minimal behavioral context beyond the obvious.
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 immediately states the action and resource. It is front-loaded and contains no fluff, but it is perhaps too minimal—it omits the workspace scoping that the parameter implies. Still, it is efficient and well-structured.
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 listing tool with one optional parameter and no output schema, the description is mostly adequate. However, it does not explicitly mention that libraries are scoped to a workspace (or default), which could confuse an agent about whether 'all' means globally or per-workspace. The schema clarifies this, but the description alone leaves room for ambiguity. No output format is described, which is acceptable given the tool's simplicity.
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%, with the single parameter workspace_id already documented in the schema (including its default-workspace behavior). The description adds no parameter-specific information, so it does not go beyond what the schema provides. Baseline 3 is appropriate given the complete schema coverage.
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 a specific verb (List), resource (content libraries), and scope (all with their IDs). It distinguishes the tool from siblings like add_content_in_library or post_content, which have clearly different purposes, so an agent can immediately understand what this tool does.
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 as a listing operation but provides no explicit guidance on when to use it versus alternatives or when not to use it. It does not mention any prerequisites like the need to call workspace_list first (though the parameter description hints at that). The context is clear only by implication, not by direct statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post content immediately or schedule it for a future time on a social account
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Social account ID (from social_account_list) | |
| url | No | Website link to include | |
| gbp_cta | No | Google Business Profile call to action | |
| message | Yes | Post content text | |
| pi_title | No | Pinterest pin title | |
| yt_thumb | No | YouTube custom thumbnail URL | |
| yt_title | No | YouTube video title | |
| image_url | No | Array of image URLs to attach | |
| video_url | No | Public video URL to attach | |
| bs_message | No | Bluesky-specific message override | |
| fb_message | No | Facebook-specific message override | |
| in_message | No | Instagram-specific message override | |
| ln_message | No | LinkedIn-specific message override | |
| pi_message | No | Pinterest-specific message override | |
| th_message | No | Threads-specific message override | |
| tk_message | No | TikTok-specific message override | |
| tw_message | No | Twitter/X-specific message override | |
| yt_message | No | YouTube-specific message override | |
| gbp_cta_url | No | Google Business Profile CTA URL | |
| gmb_message | No | Google Business Profile-specific message override | |
| ln_document | No | LinkedIn document URL (PPT/PDF/DOCX) | |
| yt_category | No | YouTube video category | |
| fb_post_type | No | Facebook post type | |
| in_post_type | No | Instagram post type | |
| workspace_id | No | Workspace ID (ws_id from workspace_list). Omit to use your default workspace. | |
| yt_user_tags | No | YouTube tags | |
| first_comment | No | Default first comment | |
| tk_allow_duet | No | Allow TikTok duets | |
| fb_first_comment | No | Facebook first comment | |
| in_first_comment | No | Instagram first comment | |
| ln_first_comment | No | LinkedIn first comment | |
| ln_document_title | No | LinkedIn document title | |
| tk_allow_comments | No | Allow TikTok comments | |
| tk_allow_stitches | No | Allow TikTok stitches | |
| tk_privacy_status | No | TikTok privacy status | |
| yt_privacy_status | No | YouTube privacy status | |
| schedule_date_time | No | Schedule time in YYYY-MM-DD HH:MM:SS format. Omit for immediate posting. | |
| in_reel_share_in_feed | No | Share Instagram reel in feed | |
| yt_video_made_for_kids | No | Is the YouTube video made for kids | |
| host_images_on_recurpost | No | Host images on RecurPost (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states that content is posted immediately or scheduled, but does not disclose irreversibility, failure modes, rate limits, or authentication requirements. For a mutation tool, this is a significant gap.
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 with zero waste. It is concise, but given the tool's complexity, it is arguably too sparse; however, the structure itself 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?
With 40 parameters, no output schema, and no annotations, the description is severely under-specified. It fails to explain platform-specific overrides, scheduling format, workspace handling, or any operational nuance, making it inadequate for an agent to use correctly.
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 schema fully documents all 40 parameters. The description adds no additional parameter meaning beyond what the schema provides, warranting the baseline score of 3.
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 verb 'post' and the resource 'content on a social account', and distinguishes it from siblings like generate_content_with_ai (generation) and social_account_list (listing). The action is unambiguous.
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 use this tool vs. alternatives. It does not mention exclusions, prerequisites (like having a connected account), or when not to use it, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify RecurPost API credentials
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It fails to mention what the tool returns (likely auth tokens or session identifiers), failure modes for invalid credentials, rate limiting, or whether this establishes state for subsequent calls. For an authentication-critical tool, this is a significant gap.
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 single sentence is front-loaded with the action verb and contains no redundant or wasteful language. However, given the tool's importance and lack of supporting annotations, the description could be appropriately longer 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?
Without an output schema or annotations for an authentication tool, the description should explain the return values (tokens, expiration) and side effects (session establishment). It omits these critical details, leaving agents uncertain about how to handle the output or subsequent authentication state.
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?
With zero parameters in the input schema (schema coverage 100%), the baseline score applies. The description does not need to parameter details, and the schema is trivially complete.
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 provides a clear verb ('Verify') and resource ('RecurPost API credentials'), and combined with the tool name 'user_login', distinguishes this authentication tool from content management siblings like 'add_content_in_library' or 'social_account_list'. However, it lacks specificity about what verification entails (e.g., establishing a session vs. just checking validity).
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 sibling authentication tools like 'connect_social_account_urls', nor does it state that this should be called first before other operations or what prerequisites are needed. The description implies functionality but not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all workspaces the user is a member of (own and shared), with their IDs. Pass a ws_id as workspace_id to other tools to work inside that workspace.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It states the tool lists workspaces and returns IDs, which implies a read-only, non-destructive operation. However, it does not explicitly disclose edge cases like empty workspace lists, ordering, or any permission requirements. The description is adequate but not rich.
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 two sentences with no filler. The primary action is stated first, followed by a practical usage hint. Every word earns its place, and it is easy to scan.
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 no-parameter, list-type tool with no output schema, the description is complete. It explains what is returned (workspaces with IDs) and how to use the result (pass the ID to other tools). There are no gaps that would prevent an agent from calling it correctly.
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 zero parameters, so the baseline for this dimension is 4. The description adds no parameter-specific information because none exist. The schema coverage is trivially 100%, and there is nothing else to clarify.
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 lists all workspaces the user is a member of (own and shared) and includes their IDs. This is a specific verb and resource, and it is distinct from sibling tools that handle content, social accounts, or authentication. No ambiguity exists about what the tool does.
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 clear guidance on how to use the output: pass the ws_id as workspace_id to other tools. It implies when to use this tool (whenever workspace IDs are needed) but does not explicitly contrast with alternatives. However, since no sibling tool lists workspaces, the context is sufficiently clear.
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.1.3add_content_in_library1 field changedInput schema / properties / workspace_idAdded value: +{
+ "description": "Workspace ID (ws_id from workspace_list). Omit to use your default workspace.",
+ "type": "string"
+}history_data1 field changedInput schema / properties / workspace_idAdded value: +{
+ "description": "Workspace ID (ws_id from workspace_list). Omit to use your default workspace.",
+ "type": "string"
+}library_list2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / workspace_idAdded value: +{
+ "description": "Workspace ID (ws_id from workspace_list). Omit to use your default workspace.",
+ "type": "string"
+}post_content1 field changedInput schema / properties / workspace_idAdded value: +{
+ "description": "Workspace ID (ws_id from workspace_list). Omit to use your default workspace.",
+ "type": "string"
+}social_account_list2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / workspace_idAdded value: +{
+ "description": "Workspace ID (ws_id from workspace_list). Omit to use your default workspace.",
+ "type": "string"
+}workspace_listv1.0.0add_content_in_libraryconnect_social_account_urlsgenerate_content_with_aigenerate_image_with_aihistory_datalibrary_listpost_contentsocial_account_listuser_loginScored across 10 tools
Each tool targets a distinct function: retrieving history, adding to library, listing accounts, connecting accounts, verifying login, listing libraries/workspaces, posting, and AI generation. No two tools overlap in purpose, making it clear which tool to invoke.
Tool names mix noun-first constructs (history_data, social_account_list, library_list, workspace_list) with verb-first constructs (add_content_in_library, connect_social_account_urls, post_content, generate_content_with_ai). The pattern is inconsistent and not predictable across the set.
With 10 tools, the surface is well-scoped for a social media management server. Each tool covers a necessary operation without redundancy, and the count falls comfortably within the ideal range.
The tool set covers core workflows: account management (list/connect), content management (add to library, post), AI generation (text/image), plus supports for lists and login verification. Minor gaps exist, such as updating or deleting content, but the primary lifecycle is well-covered.
Draft, schedule, and publish social posts for your workspace straight from your AI.
Schedule, generate and publish social posts to X, LinkedIn, Instagram, Threads and YouTube
Schedule and publish social posts across 9 platforms (Instagram, LinkedIn, X, TikTok, Facebook, Threads, Pinterest, Bluesky, Mastodon) straight from Claude, ChatGPT, Cursor, or any MCP client. Create, edit, and reschedule posts, upload media, and pull account and post analytics, follower demographics, and best-time windows. 20 tools, free on every plan.
Schedule and manage social media posts across connected platforms using natural language.
social_account_listA
List all connected social media accounts with their IDs
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and 'List' does imply a read-only operation with the useful addition that IDs are returned. However, it does not disclose authentication expectations, workspace-scoping behavior, or any caveats about which accounts are visible.
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 focused sentence with no filler. The core action, resource, and expected output are all front-loaded and immediately actionable.
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 optional-parameter list tool with no output schema, the description is mostly sufficient. The only plausible gap is not stating the intended use in the broader workflow (e.g., retrieving IDs before posting), but the schema covers the sole parameter and the purpose is clear.
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 workspace_id parameter is already clearly described in the schema. The description adds no extra parameter-level meaning, so the 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 uses a specific verb ('List') with a clear resource ('connected social media accounts') and specifies the output ('IDs'). It naturally distinguishes this tool from siblings like connect_social_account_urls, which performs a different action on the same 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?
The description gives no guidance on when to use this tool versus alternatives such as connect_social_account_urls or post_content. There are no when-to-use or when-not-to-use instructions, and no mention of the workflow context in which account IDs are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.