AutoPoster AI

Server Details

Multi-platform social media post creation, scheduling, and publishing.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-10-08 03:14
Transport: Streamable HTTP · MCP 2024-11-05
URL

TDQS

A3.8/5.0

Scored 2026-10-07 15:30 across 13 tools

Disambiguation4/5

Most tools target a distinct resource+action, but autoposter_get_post and autoposter_get_post_status overlap significantly—both return post state and live link receipts, making it hard to know which to call. The media tools (autoposter_upload_media vs autoposter_get_media_upload_url) are related but distinguishable by their size/flow descriptions.

Naming Consistency4/5

Twelve of thirteen tools follow a clean autoposter_verb_noun pattern (list_posts, get_post, delete_post, etc.). The lone get_profile breaks the prefix convention and uses a different style, a minor but noticeable deviation.

Tool Count5/5

13 tools is well within the ideal 3-15 range and each tool covers a distinct step in the posting workflow (draft, schedule, publish, delete, media, accounts, rules). No tool feels redundant or tacked on.

Completeness4/5

The surface covers create/draft/schedule, read (get, get_status, list), delete, plus media and account management—solid lifecycle coverage. The main gap is an update/edit-post operation for existing drafts, forcing delete-and-recreate workarounds.

Available Tools

13 tools

autoposter_delete_postDelete PostA

Destructive

Inspect

Deletes or cancels a draft, scheduled, or pending post by ID.

ParametersJSON Schema

Name	Required	Description	Default
`postId`	Yes	The post ID to delete or cancel.

Output Schema

ParametersJSON Schema

Name	Required	Description
`postId`	Yes	Deleted post ID.
`message`	No	Confirmation message.
`success`	Yes	Whether the post was deleted successfully.

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this mutates state. The description adds genuinely useful scope (draft/scheduled/pending only, and that it can 'cancel' rather than only hard-delete), but says nothing about irreversibility, permissions, or what happens to a post mid-publish.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the verb, with the eligible-state qualifier and key attached compactly. Nothing is redundant or padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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 not be described, and annotations carry the safety profile. The description covers the resource and eligible states; only minor gaps remain, such as whether cancelling a scheduled post is recoverable and what occurs if the post is already published.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single postId parameter, and the description adds nothing beyond 'by ID' — no format, prefix, or accepted-ID-source detail. Baseline 3 applies when the schema already carries the full parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb pair ('deletes or cancels') and the resource ('draft, scheduled, or pending post') plus the lookup key ('by ID'). It scopes which post states are eligible, but never names a sibling tool, so an agent must infer the boundary against autoposter_publish_draft or autoposter_get_post on its own.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the state list: draft/scheduled/pending posts are deletable, which weakly signals that published posts are not. There is no explicit when-to-use versus when-not, no alternative tool named for other cases, and no prerequisites stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

autoposter_draft_postCreate Post DraftAInspect

Creates a draft post for human review. If API key lacks direct publish, post is saved as pending_approval and notifications are sent to workspace approvers. Accepts mediaUrls (public URLs) or files (AI-generated images or uploaded files from chat up to 100MB). For large video files over 100MB, tell the user to provide a direct public file URL or use autoposter_get_media_upload_url.

ParametersJSON Schema

Name	Required	Description
`files`	No	Optional files generated in chat or uploaded by user to attach to the post.
`content`	Yes	Base text content of the post.
`mediaIds`	No	Optional list of existing media IDs from workspace media library (from autoposter_list_media).
`mediaUrls`	No	Optional public image or video URLs to attach (e.g. from autoposter_upload_media).
`accountIds`	Yes	List of account IDs from autoposter_list_accounts.
`platformContent`	No	Optional platform-specific content overrides (e.g. twitter, linkedin).

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	Yes	Status message indicating draft creation.
`draftPosts`	Yes	List of created draft posts per account.
`instructions`	No	Instructions for approving or viewing the draft.

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the write/safety profile is already covered. The description adds genuine context beyond that: the pending_approval fallback, approver notifications, the 100MB file ceiling, and accepted media sources. It still doesn't say what happens to the draft afterward or mention auth requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the core action and followed by the approval behavior and the size-limit fallback. Every sentence carries actionable content, though the density of three separate concerns in one paragraph makes it slightly less scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be described, and the description covers the approval workflow, media inputs, size limits and escalation path. It leaves minor gaps around account selection and the effect of platformContent, but nothing that would cause a misfire.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning for mediaUrls (public URLs) and files (AI-generated or chat-uploaded up to 100MB) that the schema alone does not convey. It adds nothing about accountIds, mediaIds, content, or platformContent beyond what the schema states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Creates a draft post for human review'), and the 'draft ... for human review' framing implicitly separates it from the publish/schedule siblings. It does not name autoposter_publish_draft or autoposter_schedule_post explicitly, so sibling differentiation is inferential rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear conditions: when the API key lacks direct publish the post goes to pending_approval, and for media over 100MB it routes the agent to a public file URL or autoposter_get_media_upload_url. There is no explicit guidance on when to choose draft over schedule_post or publish_draft, so the routing is partial.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

autoposter_get_media_upload_urlGet Direct S3 Upload URLAInspect

Generates a presigned S3 upload URL for direct, high-speed upload of videos or images up to 5GB without size limits or timeouts. Returns direct PUT url, POST upload fields, and public CDN URL.

ParametersJSON Schema

Name	Required	Description	Default
`fileName`	Yes	Name of the file including extension (e.g. 'promo_video.mp4', 'photo.jpg').
`contentType`	Yes	MIME type of the media (e.g. 'video/mp4', 'image/jpeg', 'image/png').

Output Schema

ParametersJSON Schema

Name	Required	Description
`key`	Yes	S3 object key for the media file.
`cdnUrl`	Yes	Public CDN URL after upload.
`success`	Yes	Whether the upload URL was successfully created.
`uploadPost`	No	Presigned POST fields if using multipart upload.
`directPutUrl`	Yes	Presigned S3 PUT URL for direct upload.
`instructions`	No	Instructions for completing the direct upload.

TDQS

A3.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true); the description adds meaningful context beyond them by clarifying that the tool only generates a presigned URL rather than performing the upload, and by disclosing the 5GB ceiling and the returned credential shapes. It stops short of stating URL expiration, which matters operationally for a presigned credential.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight, front-loaded sentences that lead with the action and then the return payload. Minor redundancy/marketing tone in 'high-speed' and the slightly self-contradictory framing 'up to 5GB without size limits' costs it the top score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description need not explain return values, and it correctly avoids the 2 well-documented params. However, for a presigned-credential tool it omits how long the URL remains valid and does not route the agent between this and autoposter_upload_media, leaving a real operational gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both parameters carry examples, so the schema already does the heavy lifting. The description adds no syntax, constraint, or format detail beyond what the schema provides, which is the expected baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Generates a presigned S3 upload URL' and enumerates what it returns (PUT url, POST fields, CDN URL). It does not distinguish itself from the closely related sibling autoposter_upload_media, which an agent could easily confuse with this.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied through the size/capability framing ('up to 5GB without size limits or timeouts'), which hints at large-file or direct-client uploads. There is no explicit when-to-use, when-not-to-use, or comparison against autoposter_upload_media, the obvious alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

autoposter_get_postGet Post DetailsB

Read-only

Inspect

Retrieves a single post by ID including its state (drafts, pending_approval, queued, posted) and live link receipts.

ParametersJSON Schema

Name	Required	Description	Default
`postId`	Yes	The post ID to fetch.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Post ID.
`state`	Yes	Current post state.
`postLink`	No	Live platform URL link if posted.
`postedAt`	No	ISO timestamp when post was published.
`errorMessage`	No	Failure error message if any.

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false and a closed-world scope, so safety is covered. The description adds the post state vocabulary and the presence of live link receipts, which is modest added context. It says nothing about behavior for missing/invalid IDs or non-owned posts, so it is adequate rather than rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler; the core operation comes first and the returned facets follow compactly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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 not be explained, and read-only annotations carry the safety profile; the single required param is fully documented. The only real gap is sibling disambiguation against autoposter_get_post_status, which leaves the definition slightly short of complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With a single parameter at 100% schema description coverage, the schema already documents postId fully. The phrase 'by ID' restates the schema without adding format, source, or validation semantics, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Retrieves a single post by ID') plus the returned facets (state values, live link receipts), so the agent knows exactly what it gets. However, it never differentiates itself from the sibling autoposter_get_post_status, and the enumerated state values overlap with what that sibling likely does, which could cause ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no condition selecting this over autoposter_get_post_status or autoposter_list_posts, and no stated prerequisites. The agent must infer the use case 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.

autoposter_get_post_statusGet Post StatusA

Read-only

Inspect

Checks delivery status of a post and returns live platform links/receipts once published.

ParametersJSON Schema

Name	Required	Description	Default
`postId`	Yes	The post ID to query.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Post ID.
`state`	Yes	Current status: drafts, pending_approval, queued, posted, or failed.
`postLink`	No	Live URL link to the published post on the platform.
`postedAt`	No	ISO timestamp when the post was published.
`errorMessage`	No	Error message if post failed.

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, so the safety profile is covered. The description adds useful timing context ('once published') for when links/receipts become available, but says nothing about caching, freshness, or polling behavior for posts still in flight.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with zero filler. The operation and the result are both stated up front, and no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema, annotations covering safety, and a fully documented single required parameter, the definition supplies enough for an agent to call it correctly. The only mild gap is that it does not clarify behavior for pending/failed posts, which would have been helpful for a status-check tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is one parameter with 100% schema description coverage ('The post ID to query.'), so the schema fully documents it. The description adds no extra meaning about the postId format or origin, which is the expected baseline when the schema does the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('checks delivery status of a post') and adds the return payload ('live platform links/receipts once published'). It implicitly distinguishes itself from autoposter_get_post by focusing on delivery/publication state, but never names a sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent can infer this is the tool for post-delivery checks, but there is no explicit when-to-use, when-not-to-use, or alternative routing versus autoposter_get_post or autoposter_list_posts. No prerequisites or context conditions are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

autoposter_get_rulesGet Platform Rules and LimitsA

Read-only

Inspect

Returns platform publishing constraints including character limits, media format requirements, and guidelines.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`guidelines`	Yes	Publishing guidelines and tips.
`captionLimits`	Yes	Character limits per platform.
`mediaRequirements`	Yes	Platform media requirements and constraints.
`automatedSafeguards`	No	Automated media and caption processing safeguards.

TDQS

A3.7/5.0

Behavior3/5

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 the substantive content of the response (limits, formats, guidelines), but says nothing about whether rules vary per platform, how fresh they are, or auth requirements — modest added value against an already-covered safety profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence naming the return payload and its three components, with no filler, preamble, or redundancy. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description need not enumerate return fields, and annotations cover the read-only safety stance. The only gap is the absence of any usage context (e.g., call before drafting/publishing), which for a simple zero-param getter is a minor omission rather than a blocking one.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the baseline there is no parameter semantics for the description to explain. It correctly does not invent parameter behavior, leaving the empty schema to speak for itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Returns') and a well-defined resource ('platform publishing constraints'), then enumerates the content: character limits, media format requirements, guidelines. No sibling tool in the list retrieves rule/constraint data, so the distinction is implicit, but the description never names an alternative to make it explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent can infer this should be consulted before drafting or publishing, but the description never says when to call it, whether it must precede autoposter_draft_post/publish_draft, or that it is platform-scoped. No exclusions or alternatives are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

autoposter_list_accountsList Connected AccountsA

Read-only

Inspect

Lists all connected social media accounts (X, LinkedIn, Instagram, TikTok, YouTube, Threads, Bluesky, Pinterest, Facebook) in the current Autoposter workspace.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`accounts`	Yes	List of active connected accounts in the workspace.
`timezone`	No	Default timezone for the workspace.

TDQS

A4.1/5.0

Behavior3/5

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 genuine value by scoping results to the 'current Autoposter workspace', which the annotations do not convey. It stops short of describing result shape, but an output schema exists to carry that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that identifies the resource, its platform coverage, and its workspace scope with no filler. Nothing in it is redundant with the title or name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only list operation with an output schema and full annotation coverage, the description supplies everything an agent needs to select and call it. Return values are legitimately delegated to the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is no parameter semantics to document; the baseline of 4 applies. The description correctly avoids inventing filters that the schema does not support.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Lists') and resource ('connected social media accounts') with an explicit scope ('current Autoposter workspace') and enumerates the supported platforms. This clearly separates it from sibling list tools such as autoposter_list_posts and autoposter_list_media.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: an agent can infer this is the discovery step for obtaining account handles/IDs before drafting or scheduling posts. There is no explicit when-to-use guidance, no mention of prerequisites, and no named alternative, but for a zero-parameter read tool the space of alternatives is narrow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

autoposter_list_mediaList Media LibraryB

Read-only

Inspect

Lists media files (images and videos) stored in the workspace media library with public CDN URLs.

ParametersJSON Schema

Name	Required	Description	Default
`type`	No	Optional filter by media type ('image' or 'video').
`limit`	No	Maximum number of media items to return (default 20, max 50).

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Number of media items returned.
`media`	Yes	List of media items in workspace.

TDQS

B3.4/5.0

Behavior3/5

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 that results carry public CDN URLs, a useful behavioral detail, but says nothing about pagination behavior or the workspace scoping beyond 'workspace media library'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler; the resource and the distinguishing return detail (public CDN URLs) come first and nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only list tool with an output schema and full parameter documentation, the description covers what is needed. It omits any note on result ordering or pagination beyond the limit param, but the output schema carries return-shape detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the type enum, limit default (20), and max (50) are all documented in the schema itself. The description adds no parameter semantics beyond what the schema provides, which is the expected baseline when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (lists) and resource (media files in the workspace media library), plus the fields returned (images/videos with public CDN URLs). It is clearly distinct from upload-oriented siblings, but it never explicitly differentiates itself from autoposter_upload_media or autoposter_get_media_upload_url.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as autoposter_get_media_upload_url for obtaining an upload target. The agent must infer usage purely from the one-line purpose statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

autoposter_list_postsList PostsA

Read-only

Inspect

Lists posts in the workspace. Supports filtering by state ('drafts', 'scheduled', 'queued', 'posted', 'failed', 'pending_approval'), caption text search, and limit.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of posts to return (default 20, max 50).
`state`	No	Optional filter by post state.
`search`	No	Optional keyword to search in post captions.

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Number of posts returned.
`posts`	Yes	List of matching posts.

TDQS

A3.5/5.0

Behavior3/5

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 only that filtering dimensions exist, without disclosing pagination behavior, result ordering, or how empty results are signaled. That is acceptable but thin against an already-safe read tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with the core scope front-loaded and no filler. The state enumeration partially duplicates the schema enum, which is mild redundancy but not bloat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Because an output schema exists, the description need not explain return values, and its coverage of the three optional filters aligns with the schema. For a simple zero-required-parameter list tool this is essentially sufficient; only the sibling routing guidance is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 limit (default 20, max 50), state, and search. The description restates the filterable fields and the state values, adding no format, default, or matching semantics beyond the schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Lists posts in the workspace') and enumerates the dimensions it can filter on, so the agent knows exactly what operation it performs. It does not, however, differentiate itself from siblings like autoposter_get_post or autoposter_get_post_status, which an agent must infer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the filtering capabilities (browse/filter posts in bulk), but there is no explicit statement of when to choose this over autoposter_get_post for a single post or get_post_status. No prerequisites or exclusions are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

autoposter_publish_draftPublish Draft PostAInspect

Approves and immediately publishes an existing draft or pending post. Requires an API key with direct publish permission.

ParametersJSON Schema

Name	Required	Description	Default
`postId`	Yes	The post ID returned by autoposter_draft_post.

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	Yes	Target status ('queued' or 'scheduled').
`message`	No	Status message or confirmation.
`success`	Yes	Whether the draft was approved and queued/published.

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description adds meaningful context annotations lack: the required auth scope (direct publish permission) and that publication is immediate and follows an approval step. It stops short of stating reversibility or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero waste; the publish action is front-loaded and the auth requirement follows. Nothing extraneous.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter mutation tool with an output schema and non-destructive annotations, the description covers purpose and the key auth prerequisite. A note on what happens to the draft afterward or error conditions would round it out, but it is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the only parameter (postId) is already fully documented as 'the post ID returned by autoposter_draft_post.' The description adds nothing beyond that, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('approves and immediately publishes') and resource ('existing draft or pending post'). The word 'immediately' implicitly distinguishes it from schedule_post, though it never names that sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a precondition (API key with direct publish permission) but no explicit when-to-use-vs-alternatives guidance. The 'immediately' phrasing hints at the schedule_post distinction, but the agent must infer that scheduling a future post uses a different tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

autoposter_schedule_postSchedule PostAInspect

Schedules a post for a future date/time. Automatically converts local time using workspace/user timezone into UTC. Accepts mediaUrls (public URLs) or files (AI-generated images or uploaded files from chat up to 100MB). For large video files over 100MB, tell the user to provide a direct public file URL or use autoposter_get_media_upload_url.

ParametersJSON Schema

Name	Required	Description
`files`	No	Optional files generated in chat or uploaded by user to attach to the post.
`content`	Yes	Base text content of the post.
`mediaIds`	No	Optional list of existing media IDs from workspace media library (from autoposter_list_media).
`timezone`	No	Optional IANA timezone (e.g. 'America/New_York'). If omitted, defaults to workspace or user timezone.
`mediaUrls`	No	Optional public image or video URLs to attach (e.g. from autoposter_upload_media).
`accountIds`	Yes	List of account IDs from autoposter_list_accounts.
`scheduledAt`	Yes	Scheduled ISO timestamp or local datetime string, e.g. '2026-10-05T14:00:00'.
`platformContent`	No	Optional platform-specific content overrides (e.g. twitter, linkedin).

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	Yes	Status of the scheduled post ('scheduled' or 'pending_approval').
`message`	No	Status message.
`success`	Yes	Whether the post was successfully scheduled.
`timezone`	No	Timezone applied.
`scheduledAt`	Yes	Scheduled time in UTC.
`scheduledPosts`	Yes	List of scheduled posts per target account.

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover the safety profile (readOnly=false, destructive=false, openWorld=true), so the description's added context is what counts: automatic local-to-UTC timezone conversion and the 100MB media size ceiling are genuine behavioral disclosures beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each front-loaded with the operative fact (schedule, timezone conversion, media handling) and no filler. The media sentence is dense but each clause adds distinct rules.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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 not be described. The description covers the non-obvious essentials (timezone handling, media sourcing, size limit), leaving only minor gaps such as multi-account behavior and scheduling-window constraints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description goes further by explaining that timezone is auto-resolved from workspace/user defaults and that files/mediaUrls carry a concrete 100MB limit, adding constraint semantics the schema alone does not convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Schedules a post for a future date/time') with clear temporal scope. It is distinguishable from siblings like autoposter_draft_post and autoposter_publish_draft by the 'future date/time' framing, though it never names an alternative to contrast against explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives actionable routing guidance: use mediaUrls for public URLs, files for AI-generated/uploads under 100MB, and redirect large videos to a public URL or autoposter_get_media_upload_url. It does not, however, clarify when to schedule vs. draft or publish immediately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

autoposter_upload_mediaUpload Media FileAInspect

Uploads an image or video to Auto Poster media library. Accepts files generated in ChatGPT (e.g. DALL-E images in /mnt/data/), uploaded files, or public image URLs. Direct chat download limit is 100MB. For larger videos or files (>100MB), tell the user to provide a direct public file URL or use autoposter_get_media_upload_url for direct S3 upload up to 5GB.

ParametersJSON Schema

Name	Required	Description
`url`	No	Optional public image or video URL or data URI to upload into media library.
`file`	No	File object provided by ChatGPT for AI-generated images or uploaded files.
`name`	No	Optional display name or title for the media file.

Output Schema

ParametersJSON Schema

Name	Required	Description
`url`	Yes	Public URL of the media file.
`name`	No	Display name or file name.
`type`	No	Media type ('image' or 'video').
`usage`	No	Guidance on using the media item in posts.
`mediaId`	Yes	ID of the newly uploaded media item.
`message`	No	Upload status message.
`mediaUrl`	No	Public URL of the media file to pass in posts.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare the write/open-world profile, so the description only needs to add operational context, which it does: the 100MB chat download limit and the 5GB direct-S3 path. It omits auth requirements and what happens on failure, but the size boundaries are meaningful behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with the core purpose, then sources, then the size constraint and fallback. Slight redundancy between the 100MB mention and the >100MB restatement, but nothing is padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation, and the description covers sources, size limits, and the escalation path to the sibling tool. It leaves auth/permission expectations unstated, which is the only real gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3; the description goes further by mapping scenarios to parameters (ChatGPT file objects vs. public URL/data URI) and by tying the url/file choice to a size threshold, which helps the agent pick the right input.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Uploads an image or video to Auto Poster media library') and enumerates the accepted source types, so the agent knows exactly what this tool does versus its sibling autoposter_get_media_upload_url.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use conditions (ChatGPT-generated files in /mnt/data/, uploaded files, public URLs), a hard threshold (>100MB), and a named alternative (autoposter_get_media_upload_url for S3 uploads up to 5GB). The routing decision is fully specified.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_profileA

Read-only

Inspect

Return the profile represented by this request's authenticated credentials. The opaque id is unique within this app and remains unchanged across token refresh, reconnection, and display-metadata changes.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Opaque profile identifier, unique within this app and unchanged across token refresh, reconnection, and display-metadata changes. Never reassigned to another profile.
`name`	No	Display name for the authenticated profile.
`email`	No	Email address for display; not used as the profile identity.
`nickname`	No	A useful label that helps users distinguish connected profiles.

TDQS

A3.8/5.0

Behavior4/5

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 real value beyond that by disclosing stability guarantees: the opaque id is unique within the app and unchanged across token refresh, reconnection, and display-metadata changes, which tells the agent the value is safe to cache and compare over time.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, front-loaded with the core action and followed by the one non-obvious behavioral guarantee. No filler, no repetition of the tool name or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value structure need not be restated, and annotations cover the safety profile. For a zero-parameter read tool, the description supplies everything an agent needs: what identity is returned and the stability semantics of the id.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 and the baseline of 4 applies. The schema itself has no properties to describe.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Return the profile') scoped to 'this request's authenticated credentials', which is precise and unambiguous. It does not name or contrast any sibling, but the autoposter_* siblings are all post/media operations, so the identity tool is naturally distinguishable without the description having to say so.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The phrase 'represented by this request's authenticated credentials' weakly implies 'use this to identify the calling account', but an agent gets no routing instruction and no stated prerequisites (e.g., what happens if credentials are invalid).

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.

12 tool updatesOct 7, 2026

Changedautoposter_delete_post1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "message": {
+      "description": "Confirmation message.",
+      "type": "string"
+    },
+    "postId": {
+      "description": "Deleted post ID.",
+      "type": "string"
+    },
+    "success": {
+      "description": "Whether the post was deleted successfully.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "success",
+    "postId"
+  ],
+  "type": "object"
+}

Changedautoposter_draft_post1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "draftPosts": {
+      "description": "List of created draft posts per account.",
+      "items": {
+        "properties": {
+          "accountName": {
+            "description": "Target account name.",
+            "type": "string"
+          },
+          "id": {
+            "description": "Draft post ID.",
+            "type": "string"
+          },
+          "platform": {
+            "description": "Target social media platform.",
+            "type": "string"
+          },
+          "scheduledAt": {
+            "description": "Scheduled timestamp if any.",
+            "type": "string"
+          },
+          "status": {
+            "description": "Current post status (drafts or pending_approval).",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "platform",
+          "status"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "instructions": {
+      "description": "Instructions for approving or viewing the draft.",
+      "type": "string"
+    },
+    "message": {
+      "description": "Status message indicating draft creation.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "message",
+    "draftPosts"
+  ],
+  "type": "object"
+}

Changedautoposter_get_media_upload_url1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "cdnUrl": {
+      "description": "Public CDN URL after upload.",
+      "type": "string"
+    },
+    "directPutUrl": {
+      "description": "Presigned S3 PUT URL for direct upload.",
+      "type": "string"
+    },
+    "instructions": {
+      "description": "Instructions for completing the direct upload.",
+      "type": "string"
+    },
+    "key": {
+      "description": "S3 object key for the media file.",
+      "type": "string"
+    },
+    "success": {
+      "description": "Whether the upload URL was successfully created.",
+      "type": "boolean"
+    },
+    "uploadPost": {
+      "description": "Presigned POST fields if using multipart upload.",
+      "type": "object"
+    }
+  },
+  "required": [
+    "success",
+    "key",
+    "cdnUrl",
+    "directPutUrl"
+  ],
+  "type": "object"
+}

Changedautoposter_get_post1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "errorMessage": {
+      "description": "Failure error message if any.",
+      "type": "string"
+    },
+    "id": {
+      "description": "Post ID.",
+      "type": "string"
+    },
+    "postLink": {
+      "description": "Live platform URL link if posted.",
+      "type": "string"
+    },
+    "postedAt": {
+      "description": "ISO timestamp when post was published.",
+      "type": "string"
+    },
+    "state": {
+      "description": "Current post state.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "state"
+  ],
+  "type": "object"
+}

Changedautoposter_get_post_status1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "errorMessage": {
+      "description": "Error message if post failed.",
+      "type": "string"
+    },
+    "id": {
+      "description": "Post ID.",
+      "type": "string"
+    },
+    "postLink": {
+      "description": "Live URL link to the published post on the platform.",
+      "type": "string"
+    },
+    "postedAt": {
+      "description": "ISO timestamp when the post was published.",
+      "type": "string"
+    },
+    "state": {
+      "description": "Current status: drafts, pending_approval, queued, posted, or failed.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "state"
+  ],
+  "type": "object"
+}

Changedautoposter_get_rules1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "automatedSafeguards": {
+      "description": "Automated media and caption processing safeguards.",
+      "type": "object"
+    },
+    "captionLimits": {
+      "description": "Character limits per platform.",
+      "type": "object"
+    },
+    "guidelines": {
+      "description": "Publishing guidelines and tips.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "mediaRequirements": {
+      "description": "Platform media requirements and constraints.",
+      "type": "object"
+    }
+  },
+  "required": [
+    "captionLimits",
+    "mediaRequirements",
+    "guidelines"
+  ],
+  "type": "object"
+}

Changedautoposter_list_accounts1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "accounts": {
+      "description": "List of active connected accounts in the workspace.",
+      "items": {
+        "properties": {
+          "id": {
+            "description": "Account ID.",
+            "type": "string"
+          },
+          "name": {
+            "description": "Account display name.",
+            "type": "string"
+          },
+          "platform": {
+            "description": "Platform name (e.g. twitter, linkedin, instagram).",
+            "type": "string"
+          },
+          "username": {
+            "description": "Account username or handle.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "platform",
+          "name"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "timezone": {
+      "description": "Default timezone for the workspace.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "accounts"
+  ],
+  "type": "object"
+}

Changedautoposter_list_media1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "count": {
+      "description": "Number of media items returned.",
+      "type": "number"
+    },
+    "media": {
+      "description": "List of media items in workspace.",
+      "items": {
+        "properties": {
+          "id": {
+            "description": "Media ID.",
+            "type": "string"
+          },
+          "name": {
+            "description": "File name or title.",
+            "type": "string"
+          },
+          "thumbnailUrl": {
+            "description": "Thumbnail image URL if available.",
+            "type": "string"
+          },
+          "type": {
+            "description": "Media type ('image' or 'video').",
+            "type": "string"
+          },
+          "url": {
+            "description": "Public URL of media file.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "name",
+          "type",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "count",
+    "media"
+  ],
+  "type": "object"
+}

Changedautoposter_list_posts1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "count": {
+      "description": "Number of posts returned.",
+      "type": "number"
+    },
+    "posts": {
+      "description": "List of matching posts.",
+      "items": {
+        "properties": {
+          "accountId": {
+            "description": "Target account ID.",
+            "type": "string"
+          },
+          "createdAt": {
+            "description": "Creation ISO timestamp.",
+            "type": "string"
+          },
+          "errorMessage": {
+            "description": "Failure reason if failed.",
+            "type": "string"
+          },
+          "id": {
+            "description": "Post ID.",
+            "type": "string"
+          },
+          "postLink": {
+            "description": "Live link receipt if posted.",
+            "type": "string"
+          },
+          "postedAt": {
+            "description": "Publish time if posted.",
+            "type": "string"
+          },
+          "scheduledAt": {
+            "description": "Scheduled time if scheduled.",
+            "type": "string"
+          },
+          "state": {
+            "description": "Current post state.",
+            "type": "string"
+          },
+          "text": {
+            "description": "Post caption or content.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "state"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "count",
+    "posts"
+  ],
+  "type": "object"
+}

Changedautoposter_publish_draft1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "message": {
+      "description": "Status message or confirmation.",
+      "type": "string"
+    },
+    "status": {
+      "description": "Target status ('queued' or 'scheduled').",
+      "type": "string"
+    },
+    "success": {
+      "description": "Whether the draft was approved and queued/published.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "success",
+    "status"
+  ],
+  "type": "object"
+}

Changedautoposter_schedule_post1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "message": {
+      "description": "Status message.",
+      "type": "string"
+    },
+    "scheduledAt": {
+      "description": "Scheduled time in UTC.",
+      "type": "string"
+    },
+    "scheduledPosts": {
+      "description": "List of scheduled posts per target account.",
+      "items": {
+        "properties": {
+          "accountName": {
+            "description": "Target account name.",
+            "type": "string"
+          },
+          "id": {
+            "description": "Post ID.",
+            "type": "string"
+          },
+          "platform": {
+            "description": "Target platform.",
+            "type": "string"
+          },
+          "scheduledAt": {
+            "description": "Scheduled timestamp.",
+            "type": "string"
+          },
+          "status": {
+            "description": "Post status.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "platform",
+          "status",
+          "scheduledAt"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "status": {
+      "description": "Status of the scheduled post ('scheduled' or 'pending_approval').",
+      "type": "string"
+    },
+    "success": {
+      "description": "Whether the post was successfully scheduled.",
+      "type": "boolean"
+    },
+    "timezone": {
+      "description": "Timezone applied.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "success",
+    "status",
+    "scheduledAt",
+    "scheduledPosts"
+  ],
+  "type": "object"
+}

Changedautoposter_upload_media1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "mediaId": {
+      "description": "ID of the newly uploaded media item.",
+      "type": "string"
+    },
+    "mediaUrl": {
+      "description": "Public URL of the media file to pass in posts.",
+      "type": "string"
+    },
+    "message": {
+      "description": "Upload status message.",
+      "type": "string"
+    },
+    "name": {
+      "description": "Display name or file name.",
+      "type": "string"
+    },
+    "type": {
+      "description": "Media type ('image' or 'video').",
+      "type": "string"
+    },
+    "url": {
+      "description": "Public URL of the media file.",
+      "type": "string"
+    },
+    "usage": {
+      "description": "Guidance on using the media item in posts.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "mediaId",
+    "url"
+  ],
+  "type": "object"
+}

13 tool updatesOct 7, 2026
- First observedautoposter_delete_post
- First observedautoposter_draft_post
- First observedautoposter_get_media_upload_url
- First observedautoposter_get_post
- First observedautoposter_get_post_status
- First observedautoposter_get_rules
- First observedautoposter_list_accounts
- First observedautoposter_list_media
- First observedautoposter_list_posts
- First observedautoposter_publish_draft
- First observedautoposter_schedule_post
- First observedautoposter_upload_media
- First observedget_profile

Related MCP Connectors

PostFlow BOAuth
app.postflow
Schedule, publish and manage social media posts across platforms.
Social Media
531
ViralCat
com.viral-cat
Schedule and publish social posts across platforms, with drafts, media uploads and analytics.
Social Media Marketing
1
SocialHive
pro.socialhive
Social media management, multi-platform publishing, AI generation, and cross-channel analytics.
Social Media Marketing
1
Sync SocialsOAuth
io.github.DamianoTobasco
Create, schedule and publish social posts to TikTok, Instagram, Facebook and YouTube.
Social Media Marketing
1

Related MCP Servers

Markaestroofficial
Social Media Marketing
markaestro
A
license
A
quality
B
maintenance
Schedule, publish, and measure social posts on Facebook, Instagram, TikTok, LinkedIn, Threads, Pinterest, and X for one brand or many.
Updated 7 days ago (2026-09-30 20:06 UTC)
34
MIT
faden
fadenhq
A
license
Not graded
quality
A
maintenance
Enables posting to multiple social media platforms (X, LinkedIn, Facebook, Instagram, etc.) via a unified API, handling OAuth, media, and scheduling for each network.
Updated 2 months ago (2026-08-02 08:57 UTC)
AGPL 3.0
Social Media MCP Server
Social Media Content Management Systems Autonomous Agents
tayler-id
A
license
B
quality
C
maintenance
Connects to multiple social media platforms (Twitter/X, Mastodon, LinkedIn), allowing users to create and publish content across platforms through natural language instructions.
Updated 2 years ago (2025-03-06 23:58 UTC)
3
14 npm
23
MIT
mcp-plus-tard
Social Media Marketing
boreales
F
license
A
quality
C
maintenance
Schedule posts around social networks
Updated 3 days ago (2026-10-04 18:35 UTC)
5
-