Ayrshare Safe Publishing

# Ayrshare Safe Publishing

## Loadout capabilities

Use <integration-tag>mcp:ayrshare_mcp</integration-tag> for an account owner's Ayrshare workflows after their personal Ayrshare API key is connected through Aident Loadout Vault.

- Use <action-tag>mcp:ayrshare_mcp:get_platform_history</action-tag> to inspect posts made directly on a social network, including posts not created through Ayrshare.
- Use <action-tag>mcp:ayrshare_mcp:get_post_history</action-tag> for posts that were created through Ayrshare.
- Use <action-tag>mcp:ayrshare_mcp:validate_media</action-tag> to check a public media URL before a media post.
- Use <action-tag>mcp:ayrshare_mcp:validate_post</action-tag> to dry-run a complete post before publishing.
- Use <action-tag>mcp:ayrshare_mcp:create_post</action-tag> only after immediate, explicit approval of the exact post, platforms, account, and timing.
- Use <action-tag>mcp:ayrshare_mcp:retry_post</action-tag> only for a confirmed failed post and never as a substitute for checking whether an ambiguous write succeeded.
- Use <action-tag>mcp:ayrshare_mcp:get_comments</action-tag> to inspect comments before proposing a reply.
- Use <action-tag>mcp:ayrshare_mcp:reply_comment</action-tag> only after showing the exact reply and obtaining immediate approval.
- Use <action-tag>mcp:ayrshare_mcp:explain_error</action-tag> whenever Ayrshare returns a structured error code.

## Scope

Use this Skill when the user is operating their own brand through their own Ayrshare account. It begins after the Ayrshare connection is available in Aident Loadout. Do not install an Ayrshare SDK, edit project configuration, request secrets in chat, or create profiles and customer linking flows.

For a platform or reseller workflow where customers connect their own social accounts, stop and explain that a separate multi-profile design is required. Do not silently turn an own-brand workflow into a multi-tenant workflow.

## 1. Confirm readiness

Before planning a workflow:

1. Confirm that `mcp:ayrshare_mcp` is connected with a personal credential and is ready.
2. Identify the target social platforms and whether the request is read-only, a draft, or a real mutation.
3. Inspect the exact Action schema before supplying arguments. Platform-specific options and provider requirements differ.
4. Treat provider plan or account-entitlement errors as real workflow boundaries. Explain the missing entitlement instead of repeatedly retrying.

Never ask the user to paste an API key into the conversation. Connection setup belongs in Aident Loadout Vault.

## 2. Read before writing

Start with existing content whenever the user wants analysis, recommendations, or proof that the connection works.

- Prefer `get_platform_history` for content published directly on a network. Request one platform at a time and keep the first pass bounded, normally at or below 100 records.
- Use `get_post_history` when the task concerns posts created through Ayrshare.
- Name the metrics used for any ranking. Do not invent a hidden engagement formula.
- If the provider returns a partial result, clearly label the dataset incomplete. Do not present a definitive ranking from partial data.
- If no usable history exists, report that honestly and offer another read-only check rather than fabricating results or publishing a test post.

## 3. Prepare and validate a post

Draft content without publishing it. Collect the exact post text, target platforms, media URLs, platform-specific options, and immediate or scheduled timing.

When media is present, run `validate_media` for every public media URL. Then run `validate_post` with the same payload intended for publishing. Treat validation as a dry run, not proof that every network will accept the eventual post.

If validation is unavailable on the user's Ayrshare plan, report the gate and continue only if the user understands the limitation. Never claim validation passed when the provider did not run it.

## 4. Approval immediately before publication

Immediately before `create_post`, show a compact approval preview containing:

- the exact text;
- every target platform;
- the connected account or profile context;
- all media URLs;
- immediate versus scheduled timing;
- any first comment, auto-schedule, repost, or platform-specific option;
- the consequence that this creates a real public or scheduled post.

Ask for one explicit approval covering that exact preview. Earlier approval to connect Ayrshare, draft content, validate content, or publish this Skill is not approval to publish a social post. If any material field changes after approval, show the revised preview and ask again.

## 5. Publish once and preserve per-platform results

Call `create_post` once with the approved payload. Use an idempotency key when the Action schema supports it.

Inspect and report every platform result separately. A multi-platform request can partially succeed, so never collapse the response to a single success boolean. Record the top-level Ayrshare Post ID and any platform-native IDs returned.

If the response is ambiguous, do not call `create_post` again. Reconcile first with history or the returned post ID. A blind retry can duplicate a post on platforms that already accepted it.

Use `retry_post` only when the original post has a confirmed error state, the failure is plausibly transient, and the Action's one-retry constraint is satisfied. Do not retry permission errors, invalid media, plan gates, or rate-limit responses as though they were transient.

## 6. Review and reply to comments

Use `get_comments` to inspect comments for a known Ayrshare Post ID or platform-native Social Post ID. Preserve the distinction between those ID types and provide the required platform when using a platform-native identifier.

Before `reply_comment`, show the exact reply, the account it will come from, and the post and comment it answers. Obtain one explicit approval immediately before the reply. Never approve a batch of replies through one vague confirmation.

## 7. Errors, degraded states, and rate limits

When a response contains an Ayrshare error code, call `explain_error` and report the cause, classification, and proposed recovery. Keep provider errors distinct from Aident input validation, authentication, or acknowledgement errors.

Every loop must have a maximum number of attempts, bounded batch size, explicit stop condition, and backoff with jitter. Treat HTTP 429 as a stop signal. Honor `Retry-After` when available and do not fan retries across platforms.

For write timeouts or 5xx responses, first determine whether the mutation happened. Reads may be retried when bounded; writes must be reconciled before any resend.

## Completion criteria

The workflow is complete only when the agent has reported:

- the connected account context used;
- the exact read or write Actions executed;
- the provider result for every target platform;
- any plan, network, partial-result, or authentication limitation;
- any post IDs, social IDs, or comment IDs required for later reconciliation;
- whether no mutation occurred, approval is still required, or the approved mutation completed.

For current provider details, use the [Ayrshare Action MCP documentation](https://www.ayrshare.com/docs/additional/mcp-action-server), [Ayrshare documentation](https://www.ayrshare.com/docs), and [Ayrshare pricing](https://www.ayrshare.com/pricing).