@rolino/mcp 0.9.0 → 0.10.0

package/CHANGELOG.md

@@ -1,5 +1,23 @@
 # @rolino/mcp
 
+## 0.10.0
+
+### Minor Changes
+
+- 601eda2: Add Bluesky account and media policy discovery, confirmed future local schedule cancellation, and hosted MCP media upload preparation and verification. Keep OAuth approval with the account owner and reject cancellation when delivery may have started.
+
+  Add image alt text, confirmed untouched draft deletion, and confirmed Bluesky account disconnection with independent optional permissions. Preserve original media and prevent late token refresh from restoring disconnected authorization.
+
+- support for multiple social accounts under one brand
+
+### Patch Changes
+
+- Updated dependencies [601eda2]
+- Updated dependencies
+  - @rolino/contracts@0.10.0
+  - @rolino/sdk@0.10.0
+  - @rolino/local-auth@0.10.0
+
 ## 0.9.0
 
 ### Minor Changes

package/README.md

@@ -1,262 +1,279 @@
-# `@rolino/mcp`
-
-Rolino's Model Context Protocol adapter. Rolino supports hosted Streamable HTTP
-with client-owned OAuth and local STDIO with the shared CLI OAuth session. The
-hosted route is stateless and does not need this package on the caller's
-computer. This package supplies the local STDIO process and the shared MCP tool
-definitions used by both transports.
-
-## Installation
-
-Local STDIO MCP remains a separate, explicit installation so CLI-only and
-remote users do not receive MCP runtime dependencies:
-
-```bash
-npm install --global @rolino/cli @rolino/mcp
-```
-
-For hosted Streamable HTTP, run `rolino setup mcp --client codex --transport
-http`, then `codex mcp login rolino`. For local STDIO, the CLI handles standard
-OAuth Authorization Code with PKCE and writes token-free Codex or Claude Code
-configuration that points to this package's installed entry point.
-Headless operators may install only `@rolino/mcp` and provide a scoped
-`ROLINO_TOKEN` explicitly.
-
-Initial tools:
-
-- `whoami`
-- `list_projects`
-- `get_project`
-- `create_project`
-- `list_media_assets`
-- `get_storage_usage`
-- `preview_media_cleanup`
-- `execute_media_cleanup`
-- `get_media_cleanup_status`
-- `upload_media_asset`
-- `list_posts`
-- `get_post`
-- `create_draft_post`
-- `update_draft_post`
-- `get_post_readiness`
-- `preview_post_schedule`
-- `execute_post_schedule`
-- `preview_post_publish`
-- `execute_post_publish`
-- `list_integration_health`
-- `refresh_delivery_options`
-- `list_seo_opportunities`
-- `get_seo_opportunity`
-- `list_seo_reports`
-- `get_seo_report`
-- `start_backlink_discovery`
-- `get_backlink_discovery`
-- `list_backlink_prospects`
-- `get_backlink_prospect`
-- `research_backlink_contact`
-- `update_backlink_stage`
-- `update_backlink_outreach`
-- `list_backlink_contacts`
-- `verify_backlink`
-- `list_calendar_events`
-
-Backlink tools use independent opt-in scopes. Provider-calling tools are bounded and open-world. Stored reads are closed-world. No tool accepts an arbitrary search query or a user-supplied email. Rolino never sends email.
-
-The media tools discover reusable project assets and stream one explicitly
-approved local JPEG, PNG, WebP, MP4, or MOV file directly to configured
-storage. Rolino derives dimensions and video duration from the stored object.
-Uploading never creates, schedules, or publishes a post; the returned
-asset ID is passed into a later draft operation.
-
-`get_storage_usage` and `list_media_assets` are bounded closed-world reads.
-Cleanup requires the separate `media:delete` permission. Preview creates an
-exact confirmation but deletes nothing. Before execute, show the upload-age
-cutoff, candidate count, excluded in-use count, unknown-size count, and estimated
-space. A general request to free space is not execute approval. Execute queues
-only the unchanged confirmed files with an idempotency key. In-use files are
-never detached, and queued bytes remain counted until physical deletion succeeds.
-The deletion worker skips a file without contacting storage if its confirmed
-workspace, project, asset, storage identity, or version changed.
-
-The tool set includes discovery and inspection tools that are read-only.
-The four SEO tools require the exact optional `seo:read` capability. They are
-bounded, read-only, idempotent, and closed-world. They return canonical tasks,
-evidence, neutral provenance, separate topic-relevance and action-readiness
-confidence, and recommended actions. They cannot
-run analysis, change settings, delete data, enable reports, send email, or call
-an external provider.
-Opportunity detail also returns the bounded versioned task: exact decision,
-format, target, deliverables, research, safe URLs, evidence, limitations, and
-success metric. Ready can request final deliverables for human review. Research
-selects only `RESEARCH_TASK`, compares all reasonable formats without a
-preferred final format, and must return `VALIDATED` with a complete next task
-or `REJECTED` with evidence before any separately allowed draft
-action. Every copied task forbids publishing and other Rolino writes.
-`create_project` is an additive, closed-world mutation that requires
-`projects:write` and a caller-supplied idempotency key. It atomically saves the
-project and its paired brand without starting research, connecting accounts,
-scheduling posts, or publishing. The two draft tools can create or selectively
-update draft content but cannot schedule or publish it. Omitted update fields
-preserve current media, destinations, captions, and provider settings. Both require caller-supplied
-idempotency keys, and updates also require the version returned by `get_post`
-so stale writes fail safely. Every tool returns output-schema-validated
-`structuredContent` plus a JSON text fallback.
-YouTube drafts require exactly one stored video, explicit title/category/
-visibility/audience/declaration settings, and optional tags. The YOUTUBE caption
-override becomes the video description, with the shared caption as fallback.
-Unaudited Google API projects may be restricted to Private uploads; the tools
-do not infer audit approval from server configuration.
-Bluesky drafts can be text-only or contain up to four stored JPEG, PNG, or WebP
-images. The BLUESKY caption override accepts up to 300 graphemes, with the
-shared caption as fallback.
-Before preparing TikTok settings, call `refresh_delivery_options`. It contacts
-TikTok and returns secret-safe account choices: allowed delivery modes, exact
-visibility values, interaction availability, and maximum video duration.
-Direct drafts must make every declaration explicit and mark the choices
-reviewed only after inspecting this result. That review is distinct from MCP
-mutation consent. Changing TikTok content clears the prior review, and Rolino
-never silently turns off a requested interaction.
-For LinkedIn, `refresh_delivery_options` returns the connected member plus the
-strict text/single-image/multi-image/video policy and JPEG/PNG/MP4 limits.
-LinkedIn drafts can be text-only, contain up to ten stored images, or contain
-exactly one stored MP4 without mixing images and video. Native video must be
-75 KB to 500 MB and 3 seconds to 30 minutes, and execution remains in
-preparation until LinkedIn confirms upload and processing. An optional
-3,000-character LINKEDIN caption override uses the shared caption as fallback.
-The connected member is always the author; Company Page publishing is outside
-this contract.
-Google Business Profile drafts can be text-only or contain one stored JPEG or
-PNG image with a stable public URL. The optional 1,500-character
-GOOGLE_BUSINESS_PROFILE update override uses the shared caption as fallback.
-The tools use the location selected in Rolino, create only standard updates,
-and never choose or change a Business Profile location. If final creation has
-an unknown outcome, inspect the selected Business Profile before retrying.
-Integration health is cached and secret-safe, post
-readiness reuses Rolino's publishing checks, and calendar reads use bounded
-date windows with cursor pagination. After `rolino auth login`, configure `ROLINO_URL` and
-the server automatically obtains and refreshes the API-resource OAuth token saved for
-that exact host. `ROLINO_TOKEN` remains an explicit override for CI and other
-headless environments. `ROLINO_CONFIG_DIR` can override the portable credential
-directory, and `ROLINO_TIMEOUT` is optional. Stdout is reserved for MCP
-messages; startup failures go to stderr without secrets or stack traces.
-`ROLINO_TIMEOUT` accepts integer milliseconds or values such as `500ms`, `15s`,
-and `1m`, matching the CLI.
-
-Scheduling uses two separate tools. `preview_post_schedule` contacts the
-configured providers, validates the exact post version, time, timezone, and
-readiness, and returns a five-minute single-use confirmation without scheduling
-anything. `execute_post_schedule` is marked consequential and open-world; it
-requires the unchanged preview values, confirmation token, and a stable
-idempotency key. The server repeats readiness and live-health checks and rejects
-expired, consumed, stale, cross-credential, or mismatched confirmation.
-For YouTube, the preview explains that confirmed scheduling starts or resumes a
-private upload immediately so processing can complete before the Public target.
-Execution may return a typed `PENDING` result with phase
-`REMOTE_SCHEDULE_CONFIRMATION` after the upload completes while YouTube
-acknowledges the requested publish time. The video remains private, the result
-does not report it as published, and no second publish tool call is required.
-
-Immediate publishing also uses two tools. `preview_post_publish` checks the
-exact destination set, post version, readiness, live provider health, and retry
-safety without contacting a publish endpoint. `execute_post_publish` requires
-the unchanged preview values, confirmation token, and stable idempotency key,
-then durably queues the selected destinations for immediate delivery. Provider
-calls happen after that database commit, and Rolino's existing reconciliation
-rules block blind retries after ambiguous external results. YouTube remains
-`PREPARING` until upload and processing are provider-confirmed, and its exact
-configured Public, Unlisted, or Private visibility is reconciled before
-publication is reported. The preview reports `deliveryMode: "IMMEDIATE"` and
-`createsSchedule: false`; immediate publishing never enters schedule
-confirmation.
-
-MCP tools cannot enable YouTube, Bluesky, LinkedIn, or Google Business Profile,
-or bypass a deployment's provider approval boundary. Self-hosted operators
-should complete the
-[YouTube operations guide](https://github.com/deifos/rolino/blob/main/docs/integrations/youtube.md)
-and
-[Bluesky operations guide](https://github.com/deifos/rolino/blob/main/docs/integrations/bluesky.md),
-[LinkedIn operations guide](https://github.com/deifos/rolino/blob/main/docs/integrations/linkedin.md)
-and the
-[Google Business Profile operations guide](https://github.com/deifos/rolino/blob/main/docs/integrations/google-business-profile.md)
-before live testing.
-
-## Support, security, and license
-
-Stable releases are published only after the maintainer approves the release
-gate. Report bugs through the
-[Rolino issue tracker](https://github.com/deifos/rolino/issues) and security
-issues through the repository's
-[security policy](https://github.com/deifos/rolino/security/policy).
-
-`@rolino/mcp` is available under the MIT License.
-## Agent-first Blog Studio tools
-
-The local stdio server exposes Blog readiness, import, cadence planning,
-plan-item evidence and state, editable article creation, connection status,
-confirmed provisioning, signed revalidation testing, and these provider-neutral
-publishing reads:
-
-- `list_blog_publishing_providers` requires `blog:manage` and returns only
-  enabled providers, safe capabilities, and official documentation.
-- `list_blog_publishing_destinations` requires `blog:read` and returns safe
-  connection readiness without credentials or private provider data.
-- `list_blog_delivery_attempts` requires `blog:read`, accepts an optional exact
-  article ID, and returns safe delivery states, retry times, error codes, and
-  remote URLs.
-- `generate_blog_image`, `upload_blog_image`, and `review_blog_image` require
-  `blog:write`. They cannot approve an article or publish it. Upload reads only
-  the exact local JPEG, PNG, or WebP path supplied to the tool.
-- `preview_blog_plan_cadence` and `apply_blog_plan_cadence` require
-  `blog:write`. Preview first, show every editorial move and locked item, then
-  apply only the unchanged preview values with its confirmation and a stable
-  idempotency key.
-- These cadence tools never change `scheduledPublishAt` and never schedule,
-  publish, or unpublish an article.
-- `generate_blog_image` already accepts optional editorial direction through
-  `editorialBrief` with a 500-character limit.
-- `preview_blog_revision_approval` and `execute_blog_revision_approval` require
-  the independent `blog:approve` capability. Execution makes the confirmed
-  exact bundle eligible for a separate publication operation; it cannot
-  publish.
-- `preview_blog_schedule`, `execute_blog_schedule`,
-  `preview_blog_schedule_cancellation`, and
-  `execute_blog_schedule_cancellation` require the independent `blog:publish`
-  capability. Scheduling causes future external publication but does not grant
-  approval. Cancellation removes only the confirmed future schedule and never
-  unpublishes a live article.
-
-The three publishing-read tools are closed-world reads. They do not contact a provider or
-change content. They do not return draft content, prompts, evidence, secrets,
-or raw provider responses. Setup requires the
-independent optional `blog:manage` capability; it is never inferred from
-`blog:write` or `blog:publish` and is not added to existing credentials.
-
-Read tools are closed-world. The signed revalidation test is accurately marked
-as an open-world write. Connection execute is confirmed, destructive, and
-idempotent; its first success may return one-time values that must be written
-only to server-side environment configuration. Errors and replays never reveal
-those values. These tools remain available over local stdio. The remote profile
-omits both caller-local media and Blog image uploads, and the hosted route stays hidden while its
-deployment gate is off. Publication still requires a user-approved exact revision and the
-separate publish preview/execute tools.
-
-Use the Blog tools in this order: read setup and current article or plan state;
-ask for a missing website, cadence, destination, or access level; import and
-plan through polled durable jobs; present evidence before bounded plan
-acceptance; create one immutable revision with catalog-backed links; generate
-or upload and review one image with alt text; stop for user approval when
-`blog:approve` is missing; otherwise preview and execute exact-bundle approval
-with its confirmation token and a stable idempotency key; stop after approval
-when `blog:publish` is missing; otherwise preview and execute unchanged
-publication or scheduling; poll delivery and verify the live URL; and restart
-from approval preview after any content or image change. Existing credentials
-do not gain `blog:approve`, and a queued delivery is not published.
-
-
-## Existing delivery recovery
-
-`check_post_delivery` reads an existing upload and updates Rolino. It requires `posts:write` and does not publish. `UNKNOWN` requires manual review.
-
-`preview_post_recovery` verifies an existing YouTube video and returns the account, consequence, and a short-lived confirmation. After the user approves it, `execute_post_recovery` accepts identical action, video ID, publication time, post version, and token with a stable idempotency key. `ATTACH` cannot publish; `RESUME` requires an explicit future `publishAt` or `null` for publication now, plus `posts:schedule` or `posts:publish`. `QUEUED` is pending, not published. All recovery tools are marked as writes because they change local records. No recovery tool uploads another copy.
-
-The same tools are available through packaged and hosted MCP. Upgrade the server and packaged client before using them.
+# `@rolino/mcp`
+
+Rolino's Model Context Protocol adapter. Rolino supports hosted Streamable HTTP
+with client-owned OAuth and local STDIO with the shared CLI OAuth session. The
+hosted route is stateless and does not need this package on the caller's
+computer. This package supplies the local STDIO process and the shared MCP tool
+definitions used by both transports.
+
+## Installation
+
+Local STDIO MCP remains a separate, explicit installation so CLI-only and
+remote users do not receive MCP runtime dependencies:
+
+```bash
+npm install --global @rolino/cli @rolino/mcp
+```
+
+For hosted Streamable HTTP, run `rolino setup mcp --client codex --transport
+http`, then `codex mcp login rolino`. For local STDIO, the CLI handles standard
+OAuth Authorization Code with PKCE and writes token-free Codex or Claude Code
+configuration that points to this package's installed entry point.
+Headless operators may install only `@rolino/mcp` and provide a scoped
+`ROLINO_TOKEN` explicitly.
+
+Initial tools:
+
+- `whoami`
+- `list_projects`
+- `get_project`
+- `create_project`
+- `list_media_assets`
+- `get_storage_usage`
+- `preview_media_cleanup`
+- `execute_media_cleanup`
+- `get_media_cleanup_status`
+- `upload_media_asset`
+- `list_posts`
+- `get_post`
+- `create_draft_post`
+- `update_draft_post`
+- `get_post_readiness`
+- `preview_post_schedule`
+- `execute_post_schedule`
+- `preview_post_publish`
+- `execute_post_publish`
+- `list_integration_health`
+- `refresh_delivery_options`
+- `list_seo_opportunities`
+- `get_seo_opportunity`
+- `list_seo_reports`
+- `get_seo_report`
+- `start_backlink_discovery`
+- `get_backlink_discovery`
+- `list_backlink_prospects`
+- `get_backlink_prospect`
+- `research_backlink_contact`
+- `update_backlink_stage`
+- `update_backlink_outreach`
+- `list_backlink_contacts`
+- `verify_backlink`
+- `list_calendar_events`
+
+Backlink tools use independent opt-in scopes. Provider-calling tools are bounded and open-world. Stored reads are closed-world. No tool accepts an arbitrary search query or a user-supplied email. Rolino never sends email.
+
+The media tools discover reusable project assets and stream one explicitly
+approved local JPEG, PNG, WebP, MP4, or MOV file directly to configured
+storage. Rolino derives dimensions and video duration from the stored object.
+Uploading never creates, schedules, or publishes a post; the returned
+asset ID is passed into a later draft operation.
+
+`get_storage_usage` and `list_media_assets` are bounded closed-world reads.
+Cleanup requires the separate `media:delete` permission. Preview creates an
+exact confirmation but deletes nothing. Before execute, show the upload-age
+cutoff, candidate count, excluded in-use count, unknown-size count, and estimated
+space. A general request to free space is not execute approval. Execute queues
+only the unchanged confirmed files with an idempotency key. In-use files are
+never detached, and queued bytes remain counted until physical deletion succeeds.
+The deletion worker skips a file without contacting storage if its confirmed
+workspace, project, asset, storage identity, or version changed.
+
+The tool set includes discovery and inspection tools that are read-only.
+The four SEO tools require the exact optional `seo:read` capability. They are
+bounded, read-only, idempotent, and closed-world. They return canonical tasks,
+evidence, neutral provenance, separate topic-relevance and action-readiness
+confidence, and recommended actions. They cannot
+run analysis, change settings, delete data, enable reports, send email, or call
+an external provider.
+Opportunity detail also returns the bounded versioned task: exact decision,
+format, target, deliverables, research, safe URLs, evidence, limitations, and
+success metric. Ready can request final deliverables for human review. Research
+selects only `RESEARCH_TASK`, compares all reasonable formats without a
+preferred final format, and must return `VALIDATED` with a complete next task
+or `REJECTED` with evidence before any separately allowed draft
+action. Every copied task forbids publishing and other Rolino writes.
+`create_project` is an additive, closed-world mutation that requires
+`projects:write` and a caller-supplied idempotency key. It atomically saves the
+project and its paired brand without starting research, connecting accounts,
+scheduling posts, or publishing. The two draft tools can create or selectively
+update draft content but cannot schedule or publish it. Omitted update fields
+preserve current media, destinations, captions, and provider settings. Both require caller-supplied
+idempotency keys, and updates also require the version returned by `get_post`
+so stale writes fail safely. Every tool returns output-schema-validated
+`structuredContent` plus a JSON text fallback.
+YouTube drafts require exactly one stored video, explicit title/category/
+visibility/audience/declaration settings, and optional tags. The YOUTUBE caption
+override becomes the video description, with the shared caption as fallback.
+Unaudited Google API projects may be restricted to Private uploads; the tools
+do not infer audit approval from server configuration.
+Bluesky drafts can be text-only or contain up to four stored JPEG, PNG, or WebP
+images. The BLUESKY caption override accepts up to 300 graphemes, with the
+shared caption as fallback.
+Before preparing TikTok settings, call `refresh_delivery_options`. It contacts
+TikTok and returns secret-safe account choices: allowed delivery modes, exact
+visibility values, interaction availability, and maximum video duration.
+Direct drafts must make every declaration explicit and mark the choices
+reviewed only after inspecting this result. That review is distinct from MCP
+mutation consent. Changing TikTok content clears the prior review, and Rolino
+never silently turns off a requested interaction.
+For LinkedIn, `refresh_delivery_options` returns the connected member plus the
+strict text/single-image/multi-image/video policy and JPEG/PNG/MP4 limits.
+LinkedIn drafts can be text-only, contain up to ten stored images, or contain
+exactly one stored MP4 without mixing images and video. Native video must be
+75 KB to 500 MB and 3 seconds to 30 minutes, and execution remains in
+preparation until LinkedIn confirms upload and processing. An optional
+3,000-character LINKEDIN caption override uses the shared caption as fallback.
+The connected member is always the author; Company Page publishing is outside
+this contract.
+Google Business Profile drafts can be text-only or contain one stored JPEG or
+PNG image with a stable public URL. The optional 1,500-character
+GOOGLE_BUSINESS_PROFILE update override uses the shared caption as fallback.
+The tools use the location selected in Rolino, create only standard updates,
+and never choose or change a Business Profile location. If final creation has
+an unknown outcome, inspect the selected Business Profile before retrying.
+Integration health is cached and secret-safe, post
+readiness reuses Rolino's publishing checks, and calendar reads use bounded
+date windows with cursor pagination. After `rolino auth login`, configure `ROLINO_URL` and
+the server automatically obtains and refreshes the API-resource OAuth token saved for
+that exact host. `ROLINO_TOKEN` remains an explicit override for CI and other
+headless environments. `ROLINO_CONFIG_DIR` can override the portable credential
+directory, and `ROLINO_TIMEOUT` is optional. Stdout is reserved for MCP
+messages; startup failures go to stderr without secrets or stack traces.
+`ROLINO_TIMEOUT` accepts integer milliseconds or values such as `500ms`, `15s`,
+and `1m`, matching the CLI.
+
+Scheduling uses two separate tools. `preview_post_schedule` contacts the
+configured providers, validates the exact post version, time, timezone, and
+readiness, and returns a five-minute single-use confirmation without scheduling
+anything. `execute_post_schedule` is marked consequential and open-world; it
+requires the unchanged preview values, confirmation token, and a stable
+idempotency key. The server repeats readiness and live-health checks and rejects
+expired, consumed, stale, cross-credential, or mismatched confirmation.
+For YouTube, the preview explains that confirmed scheduling starts or resumes a
+private upload immediately so processing can complete before the Public target.
+Execution may return a typed `PENDING` result with phase
+`REMOTE_SCHEDULE_CONFIRMATION` after the upload completes while YouTube
+acknowledges the requested publish time. The video remains private, the result
+does not report it as published, and no second publish tool call is required.
+
+Immediate publishing also uses two tools. `preview_post_publish` checks the
+exact destination set, post version, readiness, live provider health, and retry
+safety without contacting a publish endpoint. `execute_post_publish` requires
+the unchanged preview values, confirmation token, and stable idempotency key,
+then durably queues the selected destinations for immediate delivery. Provider
+calls happen after that database commit, and Rolino's existing reconciliation
+rules block blind retries after ambiguous external results. YouTube remains
+`PREPARING` until upload and processing are provider-confirmed, and its exact
+configured Public, Unlisted, or Private visibility is reconciled before
+publication is reported. The preview reports `deliveryMode: "IMMEDIATE"` and
+`createsSchedule: false`; immediate publishing never enters schedule
+confirmation.
+
+MCP tools cannot enable YouTube, Bluesky, LinkedIn, or Google Business Profile,
+or bypass a deployment's provider approval boundary. Self-hosted operators
+should complete the
+[YouTube operations guide](https://github.com/deifos/rolino/blob/main/docs/integrations/youtube.md)
+and
+[Bluesky operations guide](https://github.com/deifos/rolino/blob/main/docs/integrations/bluesky.md),
+[LinkedIn operations guide](https://github.com/deifos/rolino/blob/main/docs/integrations/linkedin.md)
+and the
+[Google Business Profile operations guide](https://github.com/deifos/rolino/blob/main/docs/integrations/google-business-profile.md)
+before live testing.
+
+## Support, security, and license
+
+Stable releases are published only after the maintainer approves the release
+gate. Report bugs through the
+[Rolino issue tracker](https://github.com/deifos/rolino/issues) and security
+issues through the repository's
+[security policy](https://github.com/deifos/rolino/security/policy).
+
+`@rolino/mcp` is available under the MIT License.
+## Agent-first Blog Studio tools
+
+The local stdio server exposes Blog readiness, import, cadence planning,
+plan-item evidence and state, editable article creation, connection status,
+confirmed provisioning, signed revalidation testing, and these provider-neutral
+publishing reads:
+
+- `list_blog_publishing_providers` requires `blog:manage` and returns only
+  enabled providers, safe capabilities, and official documentation.
+- `list_blog_publishing_destinations` requires `blog:read` and returns safe
+  connection readiness without credentials or private provider data.
+- `list_blog_delivery_attempts` requires `blog:read`, accepts an optional exact
+  article ID, and returns safe delivery states, retry times, error codes, and
+  remote URLs.
+- `generate_blog_image`, `upload_blog_image`, and `review_blog_image` require
+  `blog:write`. They cannot approve an article or publish it. Upload reads only
+  the exact local JPEG, PNG, or WebP path supplied to the tool.
+- `preview_blog_plan_cadence` and `apply_blog_plan_cadence` require
+  `blog:write`. Preview first, show every editorial move and locked item, then
+  apply only the unchanged preview values with its confirmation and a stable
+  idempotency key.
+- These cadence tools never change `scheduledPublishAt` and never schedule,
+  publish, or unpublish an article.
+- `generate_blog_image` already accepts optional editorial direction through
+  `editorialBrief` with a 500-character limit.
+- `preview_blog_revision_approval` and `execute_blog_revision_approval` require
+  the independent `blog:approve` capability. Execution makes the confirmed
+  exact bundle eligible for a separate publication operation; it cannot
+  publish.
+- `preview_blog_schedule`, `execute_blog_schedule`,
+  `preview_blog_schedule_cancellation`, and
+  `execute_blog_schedule_cancellation` require the independent `blog:publish`
+  capability. Scheduling causes future external publication but does not grant
+  approval. Cancellation removes only the confirmed future schedule and never
+  unpublishes a live article.
+
+The three publishing-read tools are closed-world reads. They do not contact a provider or
+change content. They do not return draft content, prompts, evidence, secrets,
+or raw provider responses. Setup requires the
+independent optional `blog:manage` capability; it is never inferred from
+`blog:write` or `blog:publish` and is not added to existing credentials.
+
+Read tools are closed-world. The signed revalidation test is accurately marked
+as an open-world write. Connection execute is confirmed, destructive, and
+idempotent; its first success may return one-time values that must be written
+only to server-side environment configuration. Errors and replays never reveal
+those values. These tools remain available over local stdio. The remote profile
+omits both caller-local media and Blog image uploads, and the hosted route stays hidden while its
+deployment gate is off. Publication still requires a user-approved exact revision and the
+separate publish preview/execute tools.
+
+Use the Blog tools in this order: read setup and current article or plan state;
+ask for a missing website, cadence, destination, or access level; import and
+plan through polled durable jobs; present evidence before bounded plan
+acceptance; create one immutable revision with catalog-backed links; generate
+or upload and review one image with alt text; stop for user approval when
+`blog:approve` is missing; otherwise preview and execute exact-bundle approval
+with its confirmation token and a stable idempotency key; stop after approval
+when `blog:publish` is missing; otherwise preview and execute unchanged
+publication or scheduling; poll delivery and verify the live URL; and restart
+from approval preview after any content or image change. Existing credentials
+do not gain `blog:approve`, and a queued delivery is not published.
+
+
+## Existing delivery recovery
+
+`check_post_delivery` reads an existing upload and updates Rolino. It requires `posts:write` and does not publish. `UNKNOWN` requires manual review.
+
+`preview_post_recovery` verifies an existing YouTube video and returns the account, consequence, and a short-lived confirmation. After the user approves it, `execute_post_recovery` accepts identical action, video ID, publication time, post version, and token with a stable idempotency key. `ATTACH` cannot publish; `RESUME` requires an explicit future `publishAt` or `null` for publication now, plus `posts:schedule` or `posts:publish`. `QUEUED` is pending, not published. All recovery tools are marked as writes because they change local records. No recovery tool uploads another copy.
+
+The same tools are available through packaged and hosted MCP. Upgrade the server and packaged client before using them.
+
+### Bluesky and media transfer
+
+`refresh_delivery_options` accepts `BLUESKY` and returns account health, limits, and an owner OAuth handoff. `prepare_media_asset_upload` and `complete_media_asset_upload` work in local and hosted MCP. Transfer the approved bytes to the short-lived URL between these calls. Hosted MCP does not read caller-local paths. `preview_post_schedule_cancellation` and `execute_post_schedule_cancellation` require `posts:schedule`, exact user approval, the current version, confirmation, and a stable retry key. They reject started or uncertain delivery. See `docs/agent-platform/bluesky.md` in the repository.
+
+Bluesky workflows also support image alt text, confirmed deletion of untouched drafts (`posts:delete`), and confirmed account disconnection (`integrations:disconnect`). These permissions are optional and independent. See [the complete workflow map](../../docs/agent-platform/bluesky.md).
+
+
+## Multiple publishing accounts
+
+Use saved connection IDs from integration health, not account names. A draft's `destinations` array can select several accounts on the same network. Each item contains `integrationId`, `provider`, and optional `captionOverride`, `tiktokSettings`, and `youtubeSettings`. A null caption override uses the shared caption. Provide YouTube settings for every YouTube account. TikTok choices and consent belong to each account.
+
+Do not combine `destinations` with legacy `platforms` or provider-level settings. A legacy provider-only request is accepted only when its account is unambiguous. The server returns a selection error otherwise. Missing or changed account identity never selects a replacement account.
+
+Saved post destinations have their own `id`. Use these destination IDs for publish `destinationIds` and recovery `destinationId`; they are different from connection `integrationId`. Preview, version, confirmation token, and selected destination IDs must remain unchanged when confirming. A pending schedule response can contain several `destinations`, each with its own `mutationId`. Wait for each account's confirmed result.
+
+These contracts are staged with the multi-account database migrations. Deploy the server and worker with the same schema before using them. Existing remote receipts remain attached to their saved accounts. No live provider acceptance test is implied by local contract tests.