Fuxux
Server Details
Schedule and manage social posts on 12 platforms: list posts, view the queue, create, edit, reschedule, and delete posts.
- Status
- Healthy
- Uptime
- 80.8% over 22 days
- OAuth
- Works in Glama
- Last Tested
- Transport
- Streamable HTTP ยท MCP 2025-11-25
- URL
TDQS
Scored across 8 tools
Each tool targets a distinct resource and action: post CRUD (create/delete/get/update/list), dashboard stats, connected accounts, and identity. Descriptions further clarify boundaries, e.g. get_post vs list_posts and the draft-finding distinction.
Seven of eight tools follow a clean verb_noun pattern (create_post, delete_post, get_post, list_posts, update_post, get_dashboard, list_connected_accounts). whoami is the lone deviation, though it is a widely understood convention and remains readable.
Eight tools are well-scoped for a social posting service, covering the full lifecycle without redundancy or filler. Each tool clearly earns its place.
Post lifecycle is fully covered (create/read/update/delete/list) plus scheduling, drafts, media, dashboard, and account listing. Minor gaps remain, such as managing (connecting/disconnecting) accounts and per-post analytics, but core workflows are complete.
Available Tools
8 toolscreate_postCreate postADestructiveInspect
Create a post: per-platform captions, optional prompt, optional scheduled_at (ISO, future), optional media_urls (strings). Without scheduled_at or draft, this publishes immediately to the connected social platforms. Set draft: true to save it for the user to review in Fuxux instead; nothing is published.
| Name | Required | Description | Default |
|---|---|---|---|
| draft | No | Save as a draft instead of publishing or scheduling (can't be combined with scheduled_at) | |
| prompt | No | Optional note on the idea behind the post (max 500 chars). Stored with the post for reference; it is not published. | |
| targets | No | Which accounts to post to. Without it, each captioned platform posts to its first connected account. Reddit is not available here: Reddit posts are created in the Fuxux web app only. | |
| captions | Yes | Map of platform id to caption text. Platform ids: twitter, instagram, linkedin, facebook, tiktok, youtube, bluesky, threads, pinterest, discord, kick, twitch | |
| media_urls | No | Up to 4 public https image/video URLs to attach | |
| scheduled_at | No | ISO datetime; if set, post is scheduled instead of published immediately |
Output Schema
| Name | Required | Description |
|---|---|---|
| post | Yes | The created post |
| results | No | Per-platform outcome; present only when published immediately |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring destructiveHint=true and openWorldHint=true, the description adds genuinely useful context: this call publishes to live connected social platforms unless scheduled_at or draft is set, and draft:true publishes nothing. It stops short of covering reversibility, auth requirements, or partial-failure behavior across multiple platforms.
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?
Three sentences, front-loaded with the tool's parameter surface before the behavior contract, and nothing is wasted. There is mild redundancy between the parenthetical parameter list and the schema, and "(ISO, future)" partly duplicates the schema's ISO datetime wording.
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?
Output schema exists, so return values need no explanation, and annotations carry the safety profile. The description covers the three execution modes completely; only peripheral details (targets/Reddit restriction) are left to the schema, which handles them adequately.
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 already documents every parameter including the draft/scheduled_at exclusivity and the targets fallback. The description's parameter mentions (ISO, future, strings) mostly restate what the schema provides, adding no syntax or constraint detail beyond it.
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?
Specific verb+resource ("Create a post") plus an enumeration of what it accepts (captions, prompt, scheduled_at, media_urls). It is clearly distinguishable from get_post/update_post/delete_post by virtue of the create verb, but it never names or contrasts with those siblings explicitly.
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?
Gives clear mode-selection guidance: no scheduled_at/draft means immediate publish, scheduled_at means schedule, draft:true means save for review. This tells the agent when each behavior applies, though it does not compare against alternatives like update_post or the web-app-only path for Reddit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_postDelete postADestructiveInspect
Delete a post from Fuxux. A draft or scheduled post will then never publish. For an already-published post this removes only Fuxux's record; it does NOT delete it from the social platform. Fails while the post is publishing.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Post id (from list_posts or create_post) |
Output Schema
| Name | Required | Description |
|---|---|---|
| success | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only flag destructiveHint=true and idempotentHint=false; the description goes well beyond them by disclosing exactly what is destroyed in each case (draft/scheduled will never publish; published posts lose only the Fuxux record, not the platform copy) and a concrete failure mode. This is precisely the kind of consequence detail a destructive tool needs.
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?
Four short sentences, each carrying distinct decision-relevant information: the action, the draft/scheduled consequence, the published-post limitation, and the failure case. Front-loaded with the core action and no 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?
For a one-parameter destructive tool with an output schema, the description covers everything the agent needs: side effects per post state, the key non-obvious limitation (no platform deletion), and the in-flight publishing failure. Return values are handled by the output schema, so nothing material 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?
There is a single parameter with 100% schema description coverage, and the schema already tells the agent it is a post UUID sourced from list_posts or create_post. The description adds no additional meaning about the id, so the baseline 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?
States a specific verb and resource ("Delete a post from Fuxux") and immediately sharpens the scope by explaining that deletion means different things for draft/scheduled vs already-published posts. An agent can distinguish this from update_post or get_post without opening any schema.
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?
Usage is implied rather than stated: the agent learns the effect of deleting in each post state, but there is no explicit when-to-use guidance or named alternative (e.g., use update_post to unpublish, or the platform's own tools to remove a live post). The failure condition "Fails while the post is publishing" is useful operational context but is not a routing rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_dashboardGet dashboardBRead-onlyInspect
Summary stats, upcoming scheduled posts, and per-platform connection status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| stats | No | |
| profile | No | |
| platforms | No | Per-platform connection status and post counts |
| upcomingPosts | No | Next posts due to publish |
| needsAttention | No | Accounts that need reconnecting |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully enumerates the payload's contents, but says nothing about auth requirements, freshness/caching, or scope limits beyond what annotations and the output schema provide.
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?
A single compact sentence with no filler, front-loading the most important content (summary stats). It is a noun fragment rather than a full clause, but nothing is wasted.
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 zero-parameter read tool with an output schema, the description covers what is needed to select and call it. The output schema handles return structure, and annotations handle safety; only usage routing against sibling read tools 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?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. Schema coverage is trivially 100%.
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?
Combined with the name 'get_dashboard', the description clearly states what the tool returns: summary stats, upcoming scheduled posts, and per-platform connection status. That content list distinguishes it from siblings like list_posts or whoami, though the description itself never states an action verb.
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 when-to-use guidance and no mention of alternatives such as list_posts or list_connected_accounts, which overlap with the data this tool surfaces. The agent must infer the entry-point role of a dashboard 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.
get_postGet postARead-onlyInspect
Get one post with its per-platform variants. Variant ids from here are what update_post uses to edit individual captions. Also finds drafts, which list_posts (month-scoped) can miss.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Post id (from list_posts or create_post) |
Output Schema
| Name | Required | Description |
|---|---|---|
| post | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered; the description adds non-obvious behavior instead โ that the response nests per-platform variants and that it surfaces drafts invisible to list_posts. It doesn't discuss pagination or failure modes, but with an output schema present the return shape is documented elsewhere.
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?
Three short sentences, each doing distinct work: what it returns, how the result feeds update_post, and the draft edge case. Front-loaded with the core action and no 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?
For a single-parameter read tool with full annotation coverage and an output schema, the description supplies everything an agent needs: identity, downstream dependency on update_post, and the one case where the sibling list_posts 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?
One parameter at 100% schema description coverage, and the schema already documents the UUID format and its origin ('from list_posts or create_post'). The description echoes that provenance but adds no format or constraint detail beyond the schema, so the baseline 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?
States a specific verb and resource ('Get one post') and immediately scopes the payload ('with its per-platform variants'), which no sibling provides. It also names list_posts and create_post/update_post, so an agent can place it in the workflow without opening another schema.
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?
Explicitly routes: variant ids retrieved here are the inputs update_post needs for per-caption edits, and it is the fallback for drafts that month-scoped list_posts can miss. Both the when-to-use and the alternative-avoidance condition are stated, not implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_connected_accountsList connected accountsARead-onlyInspect
List social accounts connected to the Fuxux workspace. Use an account's id in create_post targets to pick which account posts when a platform has more than one.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| accounts | Yes | |
| workspace_name | No | |
| is_team_workspace | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without description help. The description adds only the workspace scoping and the downstream id usage; it says nothing about ordering, volume, or freshness of the returned accounts.
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 sentences, no filler. The core purpose is front-loaded and the second sentence earns its place by explaining what to do with the output.
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 zero-parameter read tool with a full output schema and complete annotation coverage, the description supplies everything an agent needs: what is listed, its scope, and how the results feed create_post. Return-value detail is correctly delegated to the 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 tool takes zero parameters, so the baseline is 4 and the description has nothing to disambiguate. The implicit point that results are scoped to the current Fuxux workspace is the only relevant framing and it is stated.
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?
States a specific verb and resource (list connected social accounts) and scopes it to the Fuxux workspace, which cleanly separates it from sibling list tools like list_posts. The second sentence links the returned ids to create_post targets, making the tool's role 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?
It explains the motivating context for calling it โ retrieving account ids to use as create_post targets when a platform has multiple accounts โ which is clear when-to-use guidance. It stops short of explicit when-not-to-use or naming a sibling alternative, but no plausible alternative exists for this resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_postsList postsARead-onlyInspect
List posts (calendar / queue). Optional filters: month (YYYY-MM), status. Pass limit to get only what you need (e.g. limit 5 + order "newest" for the most recent posts). Page with offset while hasMore is true.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max posts to return (1-50). Defaults to 20, or the whole month when month is set | |
| month | No | Calendar month, e.g. "2026-04" | |
| order | No | upcoming (default): by scheduled time, soonest first. newest: most recently created first. recently_published: latest published first. recently_updated: most recently changed first | |
| offset | No | Skip this many posts (for paging) | |
| status | No | Filter by status; omit for no status filter |
Output Schema
| Name | Required | Description |
|---|---|---|
| posts | Yes | |
| counts | No | Workspace-wide totals per status |
| hasMore | No | |
| nextOffset | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral detail beyond that: the default limit (20, or the whole month when month is set), the order default of 'upcoming', and the hasMore/offset paging loop.
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?
Three sentences, no filler, with the core purpose front-loaded and filters/paging ordered by likely importance. Every sentence carries actionable information.
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 read-only list tool with an output schema (so return values need no explanation) and full schema coverage, the description supplies everything needed: filter semantics, ordering defaults, limit guidance, and pagination termination. Nothing an agent needs to call it correctly 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 coverage is 100%, so the baseline is 3; the description still earns credit by adding usage semantics the schema lacks, such as combining limit with order 'newest' to fetch the most recent posts and restating the month format. It does not, however, explain offset behavior beyond the paging hint.
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?
Specific verb+resource ('List posts') with the scope hinted by '(calendar / queue)'. It is easy to distinguish from get_post (single item) and the create/update/delete siblings, though the description never explicitly contrasts 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?
Gives clear operational context: optional month/status filters, a limit-tuning tip ('limit 5 + order "newest"'), and the paging rule ('Page with offset while hasMore is true'). It does not state when this tool should NOT be used or name an alternative, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_postUpdate postADestructiveIdempotentInspect
Edit a draft or scheduled post before it publishes: reschedule (scheduled posts only; scheduled_at must be in the future), change captions, or replace media. Published or publishing posts can't be edited. Provide at least one of scheduled_at, variant_updates, media_urls.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Post id (from list_posts or create_post) | |
| media_urls | No | Replaces the post's media (public https URLs) | |
| scheduled_at | No | New ISO datetime in the future (scheduled posts only) | |
| variant_updates | No | Caption changes, one entry per variant |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| post | No | The post after the update |
| success | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true; the description adds real context beyond them: media_urls REPLACES existing media, rescheduling is restricted to scheduled posts with a future timestamp, and published posts are immutable. It stops short of stating permission/auth requirements or whether prior media is recoverable.
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 sentences, front-loaded with the scope and eligibility window, then the payload requirement. Every clause carries an actionable constraint; no 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?
An output schema exists so return values need no explanation, and annotations cover the safety profile. The description supplies the eligibility rules, per-field constraints, and the 'at least one field' precondition, which is everything an agent needs to invoke 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?
Schema coverage is 100%, so baseline is 3, but the description adds a constraint the schema does not encode: at least one of scheduled_at, variant_updates, or media_urls must be supplied (schema only requires id). It also restates the future-timestamp rule for scheduled_at, reinforcing the field's semantics.
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?
Specific verb+resource ('Edit a draft or scheduled post') with the three editable surfaces enumerated (reschedule, captions, media). Clearly distinguishable from siblings create_post, delete_post, and get_post.
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?
States the operative window explicitly ('draft or scheduled post before it publishes') and the exclusion ('Published or publishing posts can't be edited'), plus a minimum-payload rule. It does not name delete_post or get_post as alternatives for other states, but the when/when-not boundary is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whoamiWho am IARead-onlyInspect
Return the email, name and plan of the Fuxux account this connection is signed in to. Use it to confirm the connection works.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| plan | No | free | creator | growth | pro |
| No | ||
| full_name | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds that this validates the connection/auth state, which is genuine behavioral context beyond the annotations, though it says nothing about failure modes when the connection is invalid.
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 short sentences, front-loaded with the returned payload and followed by the motivating use case. Every clause earns its place with no repetition of schema or annotation data.
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?
An output schema exists so return values need no elaboration, and annotations carry the safety profile. The description is sufficient for a zero-param identity tool, with only minor gaps around error/auth-failure behavior.
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 takes zero parameters, so per the baseline this is a 4. The description correctly implies no inputs are needed to identify the account.
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?
States a specific verb (return) and resource (the signed-in account's email, name, plan) with the exact fields it yields. An agent can tell this apart from sibling list_connected_accounts, which enumerates multiple connections rather than the current identity.
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?
Explicitly gives a when-to-use case: 'confirm the connection works.' It does not name an alternative tool or state when not to use it, but the context is unambiguous for a zero-arg identity probe.
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.
2 tool updates
- Changed
list_connected_accounts7 fields changed- removed
Output schema / properties / accounts / items / properties / created_atRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] -} - added
Output schema / properties / accounts / items / properties / id / descriptionAdded value: +"Use as account_id in create_post targets" - removed
Output schema / properties / accounts / items / properties / platform_avatar_urlRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] -} - removed
Output schema / properties / accounts / items / properties / scopesRemoved value: -{ - "anyOf": [ - { - "items": { - "type": "string" - }, - "type": "array" - }, - { - "type": "null" - } - ] -} - removed
Output schema / properties / accounts / items / properties / token_expires_atRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] -} - added
Output schema / properties / accounts / items / properties / via_reminder / descriptionAdded value: +"True for a reminder-only entry: Fuxux reminds the user to post, it does not publish" - removed
Output schema / properties / workspace_idRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] -}
- Changed
whoami8 fields changed- removed
Output schema / properties / created_atRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] -} - removed
Output schema / properties / has_api_accessRemoved value: -{ - "anyOf": [ - { - "type": "boolean" - }, - { - "type": "null" - } - ], - "description": "Whether this account can use API keys" -} - removed
Output schema / properties / idRemoved value: -{ - "type": "string" -} - removed
Output schema / properties / onboarding_completedRemoved value: -{ - "anyOf": [ - { - "type": "boolean" - }, - { - "type": "null" - } - ] -} - added
Output schema / properties / plan / descriptionAdded value: +"free | creator | growth | pro" - removed
Output schema / properties / subscription_statusRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] -} - removed
Output schema / properties / trial_endRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] -} - removed
Output schema / requiredRemoved value: -[ - "id" -]
1 tool update
- Changed
create_post2 fields changed- changed
Input schema / properties / captions / descriptionPrevious value: -"Map of platform id to caption text. Platform ids: twitter, instagram, linkedin, facebook, tiktok, youtube, bluesky, threads, pinterest, google-business, discord, kick, twitch"New value: +"Map of platform id to caption text. Platform ids: twitter, instagram, linkedin, facebook, tiktok, youtube, bluesky, threads, pinterest, discord, kick, twitch" - changed
Input schema / properties / targets / items / properties / platform / enumPrevious value: -[ - "twitter", - "instagram", - "linkedin", - "facebook", - "tiktok", - "youtube", - "bluesky", - "threads", - "pinterest", - "google-business", - "discord", - "kick", - "twitch" -]New value: +[ + "twitter", + "instagram", + "linkedin", + "facebook", + "tiktok", + "youtube", + "bluesky", + "threads", + "pinterest", + "discord", + "kick", + "twitch" +]
1 tool update
- Changed
create_post5 fields changed- changed
Input schema / properties / captions / descriptionPrevious value: -"Map of platform id to caption text. Platform ids: twitter, instagram, linkedin, facebook, tiktok, youtube, bluesky, threads, pinterest, google-business, reddit, discord, kick, twitch"New value: +"Map of platform id to caption text. Platform ids: twitter, instagram, linkedin, facebook, tiktok, youtube, bluesky, threads, pinterest, google-business, discord, kick, twitch" - changed
Input schema / properties / targets / descriptionPrevious value: -"Which accounts to post to. Without it, each captioned platform posts to its first connected account. Required for reddit (subreddit)."New value: +"Which accounts to post to. Without it, each captioned platform posts to its first connected account. Reddit is not available here: Reddit posts are created in the Fuxux web app only." - removed
Input schema / properties / targets / items / properties / flair_idRemoved value: -{ - "description": "reddit only: post flair id, if the subreddit requires one", - "type": "string" -} - changed
Input schema / properties / targets / items / properties / platform / enumPrevious value: -[ - "twitter", - "instagram", - "linkedin", - "facebook", - "tiktok", - "youtube", - "bluesky", - "threads", - "pinterest", - "google-business", - "reddit", - "discord", - "kick", - "twitch" -]New value: +[ + "twitter", + "instagram", + "linkedin", + "facebook", + "tiktok", + "youtube", + "bluesky", + "threads", + "pinterest", + "google-business", + "discord", + "kick", + "twitch" +] - removed
Input schema / properties / targets / items / properties / subredditRemoved value: -{ - "description": "reddit only: subreddit name without r/ (required for reddit)", - "type": "string" -}
1 tool update
- Changed
create_post1 field changed- added
Input schema / properties / targets / items / properties / board_idAdded value: +{ + "description": "pinterest only: board id to pin to; defaults to the account's first public board", + "type": "string" +}
1 tool update
- Changed
create_post2 fields changed- changed
Input schema / properties / captions / descriptionPrevious value: -"Map of platform id to caption text"New value: +"Map of platform id to caption text. Platform ids: twitter, instagram, linkedin, facebook, tiktok, youtube, bluesky, threads, pinterest, google-business, reddit, discord, kick, twitch" - added
Input schema / properties / targetsAdded value: +{ + "description": "Which accounts to post to. Without it, each captioned platform posts to its first connected account. Required for reddit (subreddit).", + "items": { + "properties": { + "account_id": { + "description": "Connected account id from list_connected_accounts", + "format": "uuid", + "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", + "type": "string" + }, + "flair_id": { + "description": "reddit only: post flair id, if the subreddit requires one", + "type": "string" + }, + "format": { + "description": "instagram and facebook only; defaults to feed", + "enum": [ + "feed", + "story" + ], + "type": "string" + }, + "platform": { + "description": "That account's platform; needs a caption in captions", + "enum": [ + "twitter", + "instagram", + "linkedin", + "facebook", + "tiktok", + "youtube", + "bluesky", + "threads", + "pinterest", + "google-business", + "reddit", + "discord", + "kick", + "twitch" + ], + "type": "string" + }, + "subreddit": { + "description": "reddit only: subreddit name without r/ (required for reddit)", + "type": "string" + } + }, + "required": [ + "account_id", + "platform" + ], + "type": "object" + }, + "type": "array" +}
2 tool updates
- Changed
create_post1 field changed- added
Input schema / properties / draftAdded value: +{ + "description": "Save as a draft instead of publishing or scheduling (can't be combined with scheduled_at)", + "type": "boolean" +}
- Changed
list_posts4 fields changed- added
Input schema / properties / limitAdded value: +{ + "description": "Max posts to return (1-50). Defaults to 20, or the whole month when month is set", + "maximum": 50, + "minimum": 1, + "type": "integer" +} - added
Input schema / properties / offsetAdded value: +{ + "description": "Skip this many posts (for paging)", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" +} - added
Input schema / properties / orderAdded value: +{ + "description": "upcoming (default): by scheduled time, soonest first. newest: most recently created first. recently_published: latest published first. recently_updated: most recently changed first", + "enum": [ + "upcoming", + "newest", + "recently_published", + "recently_updated" + ], + "type": "string" +} - changed
Input schema / properties / status / enumPrevious value: -[ - "scheduled", - "published", - "draft", - "all" -]New value: +[ + "scheduled", + "published", + "draft", + "failed", + "all" +]
8 tool updates
- Changed
create_post3 fields changed- added
Input schema / properties / media_urls / descriptionAdded value: +"Up to 4 public https image/video URLs to attach" - added
Input schema / properties / prompt / descriptionAdded value: +"Optional note on the idea behind the post (max 500 chars). Stored with the post for reference; it is not published." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": {}, + "properties": { + "post": { + "additionalProperties": {}, + "description": "The created post", + "properties": { + "id": { + "type": "string" + }, + "scheduled_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "status": { + "description": "draft | scheduled | published | failed", + "type": "string" + } + }, + "required": [ + "id", + "status" + ], + "type": "object" + }, + "results": { + "anyOf": [ + { + "items": { + "additionalProperties": {}, + "properties": { + "account_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "account_label": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "error": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "inbox_pending": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "platform": { + "type": "string" + }, + "platform_post_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "still_processing": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "success": { + "type": "boolean" + } + }, + "required": [ + "platform", + "success" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "Per-platform outcome; present only when published immediately" + } + }, + "required": [ + "post" + ], + "type": "object" +}
- Changed
delete_post1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": {}, + "properties": { + "success": { + "type": "boolean" + } + }, + "required": [ + "success" + ], + "type": "object" +}
- Changed
get_dashboard1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": {}, + "properties": { + "needsAttention": { + "anyOf": [ + { + "items": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "Accounts that need reconnecting" + }, + "platforms": { + "anyOf": [ + { + "items": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "Per-platform connection status and post counts" + }, + "profile": { + "anyOf": [ + { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + { + "type": "null" + } + ] + }, + "stats": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "accountsNeedingAttention": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "connectedAccounts": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "healthyAccounts": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "momChange": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "postsLastMonth": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "postsThisMonth": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "totalPublished": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "upcomingThisWeek": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + } + }, + "type": "object" + }, + { + "type": "null" + } + ] + }, + "upcomingPosts": { + "anyOf": [ + { + "items": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "Next posts due to publish" + } + }, + "type": "object" +}
- Changed
get_post1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": {}, + "properties": { + "post": { + "additionalProperties": {}, + "properties": { + "created_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "media_urls": { + "anyOf": [ + { + "items": { + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "post_variants": { + "anyOf": [ + { + "items": { + "additionalProperties": {}, + "properties": { + "connected_account_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "content": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Caption for this platform/account" + }, + "error_message": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "platform": { + "description": "Platform id, e.g. instagram, linkedin", + "type": "string" + }, + "platform_post_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "published_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "status": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "platform" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "One entry per platform/account" + }, + "published_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "raw_prompt": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "scheduled_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "status": { + "description": "draft | scheduled | publishing | published | failed", + "type": "string" + } + }, + "required": [ + "id", + "status" + ], + "type": "object" + } + }, + "required": [ + "post" + ], + "type": "object" +}
- Changed
list_connected_accounts1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": {}, + "properties": { + "accounts": { + "items": { + "additionalProperties": {}, + "properties": { + "created_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "platform": { + "type": "string" + }, + "platform_avatar_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "platform_username": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "scopes": { + "anyOf": [ + { + "items": { + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "status": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "connected | expired" + }, + "token_expires_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "via_reminder": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "platform" + ], + "type": "object" + }, + "type": "array" + }, + "is_team_workspace": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "workspace_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "workspace_name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "accounts" + ], + "type": "object" +}
- Changed
list_posts1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": {}, + "properties": { + "counts": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "drafts": { + "type": "number" + }, + "failed": { + "type": "number" + }, + "published": { + "type": "number" + }, + "scheduled": { + "type": "number" + }, + "total": { + "type": "number" + } + }, + "required": [ + "total", + "scheduled", + "published", + "drafts", + "failed" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "Workspace-wide totals per status" + }, + "hasMore": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "nextOffset": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "posts": { + "items": { + "additionalProperties": {}, + "properties": { + "created_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "media_urls": { + "anyOf": [ + { + "items": { + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "post_variants": { + "anyOf": [ + { + "items": { + "additionalProperties": {}, + "properties": { + "connected_account_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "content": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Caption for this platform/account" + }, + "error_message": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "platform": { + "description": "Platform id, e.g. instagram, linkedin", + "type": "string" + }, + "platform_post_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "published_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "status": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "platform" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "One entry per platform/account" + }, + "published_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "raw_prompt": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "scheduled_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "status": { + "description": "draft | scheduled | publishing | published | failed", + "type": "string" + } + }, + "required": [ + "id", + "status" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "posts" + ], + "type": "object" +}
- Changed
update_post1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": {}, + "properties": { + "id": { + "type": "string" + }, + "post": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "created_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "media_urls": { + "anyOf": [ + { + "items": { + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "post_variants": { + "anyOf": [ + { + "items": { + "additionalProperties": {}, + "properties": { + "connected_account_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "content": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Caption for this platform/account" + }, + "error_message": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "platform": { + "description": "Platform id, e.g. instagram, linkedin", + "type": "string" + }, + "platform_post_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "published_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "status": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "platform" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "One entry per platform/account" + }, + "published_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "raw_prompt": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "scheduled_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "status": { + "description": "draft | scheduled | publishing | published | failed", + "type": "string" + } + }, + "required": [ + "id", + "status" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "The post after the update" + }, + "success": { + "type": "boolean" + } + }, + "required": [ + "success", + "id" + ], + "type": "object" +}
- Changed
whoami1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": {}, + "properties": { + "created_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "email": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "full_name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "has_api_access": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ], + "description": "Whether this account can use API keys" + }, + "id": { + "type": "string" + }, + "onboarding_completed": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "plan": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "subscription_status": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "trial_end": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id" + ], + "type": "object" +}
3 tool updates
- Added
delete_post - Added
get_post - Added
update_post
5 tool updates
- First observed
create_post - First observed
get_dashboard - First observed
list_connected_accounts - First observed
list_posts - First observed
whoami
Publisher details
- Operator
- Fuxux ยท Publisher source
- Operator website
- https://www.fuxux.com ยท Publisher source
- Vendor relationship
- First-party ยท Publisher source
- Documentation
- https://www.fuxux.com/mcp/docs ยท Publisher source
- Trust center
- Not available
- Restrictions
- Requires a Fuxux account. Sign in with your Fuxux account (OAuth) when you connect, or send a Fuxux API key (created under Settings > API keys) as a Bearer token. Every call, including listing the tools, needs one of the two. ยท Publisher source
Related MCP Connectors
Schedule, publish and manage social media posts across platforms.
Schedule and publish social posts across platforms, with drafts, media uploads and analytics.
Schedule and publish social posts to 12 platforms with first comments, analytics, and listening.
Draft, validate, publish, schedule, and manage social posts across connected accounts.
Related MCP Servers
AlicenseAqualityBmaintenanceSchedule, publish, and measure social posts on Facebook, Instagram, TikTok, LinkedIn, Threads, Pinterest, and X for one brand or many.34MIT- -

OwlStack MCPofficial
AlicenseAqualityCmaintenanceManages social media posts, accounts, and AI usage from MCP-aware clients. Supports scheduling, editing, canceling, AI caption generation, and repurposing URLs into platform-optimized content.14MIT- AlicenseNot gradedqualityDmaintenanceEnables posting and managing content across 13+ social media platforms with scheduling, analytics, AI generation, and approval workflows through natural language.2MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.