everyfeed

EveryFeed

Operate EveryFeed through its MCP tools when they are available. Use the EveryFeed CLI for terminal workflows and public API operations that MCP does not expose, such as connection lifecycle, analytics, post state changes, deletion, and local-file upload.

Choose the interface

1. Prefer MCP for conversational drafting, provider discovery, validation, media generation, and confirmed post creation.
2. Use the CLI when the user explicitly asks for terminal automation or needs a CLI-only operation. See references/cli.md.
3. Do not silently switch organizations, profiles, channels, or interfaces. Resolve identifiers again after switching context.
4. If MCP tools are unavailable, direct the user to EveryFeed → Settings → Developers → Access. Never ask the user to paste a token into chat.
5. If a requested feature is unavailable through MCP but is supported by the CLI, explain the switch before running the command.

Establish context

Before preparing content:

1. Call listConnectedChannels. If the user names a client group, call listChannelGroups first and pass only the returned matching group ID.
2. Call getCurrentDateTime before interpreting relative dates or scheduling. Treat its UTC value and returned channel time zones as authoritative.
3. Call getProviderRules before provider-specific wording, settings, media, threads, comments, or publishing decisions.
4. When the user names a project, resolve it with listProjects. When they ask to reuse a content set, resolve it with listContentSets, then call getContentSet. Treat loaded content as editable draft material.
5. Use only identifiers returned for the current organization. Never invent or reuse channel, group, project, media, content-set, or generation IDs.

See references/mcp-tools.md for all 26 MCP tool contracts and references/provider-workflows.md for provider-specific preparation.

Prepare content

• Resolve ambiguous destinations, dates, time zones, thread structure, media, project, short-link behavior, and draft/schedule/now mode with the user.
• Preserve the user's requested language and brand voice unless asked to adapt them per channel.
• Build provider settings only from getProviderRules output. Use executeProviderFunction only with a function and parameters advertised for that provider.
• Use ordered values for threads and comments. Keep each value's message, delay, and media explicit.
• Use findNextAvailableSlot only as a suggestion; it does not authorize a scheduled post.
• Follow the reusable patterns in references/workflows.md for threads, multi-platform campaigns, media, projects, content sets, and batch schedules.

Use media and AI generation

• Use listMedia and reference only returned organization media IDs.
• For a public remote image or MP4, show the exact URL and intended alt text, obtain confirmation, then call uploadMediaFromUrl once with a unique idempotency key.
• Show the exact prompt and options before any AI generation. Obtain explicit confirmation before generatePostDraft, generateImage, startVideoGeneration, or startNarratedSlideVideoGeneration.
• Call listVideoGenerationOptions before ordinary video generation and select only an available provider, duration, size, and reference-image count.
• Call listNarratedSlideVoices before narrated slide generation and use only a returned voice.
• Poll only jobs returned to the current user. Use list tools to recover a known job and resume tools only after confirmation; resuming changes workflow state.
• Attach generated media only after the generation completes and returns an EveryFeed media record.

AI-generated copy remains an editable draft. Generation never authorizes post creation.

Validate and review

Always call validateComposerDraft on the final payload before proposing any write. Accept an item only when:

• valid !== false;
• emptyContent !== true;
• tooLong !== true;
• errors === true;
• settingsError is empty when present.

Fix every invalid channel payload and revalidate after any change.

Present a compact final review containing:

• channel display names and providers;
• every post, thread item, or comment;
• attached or generated media;
• provider-specific settings;
• draft, immediate, or scheduled mode;
• exact scheduled timestamp and time zone;
• project and short-link behavior.

Ask for explicit confirmation tied to that exact review. An edit, question, silence, or approval of an earlier payload is not current approval.

Execute writes

After current explicit approval:

1. Generate one stable, unique idempotency key for the approved operation.
2. Call createPosts exactly once with confirmed: true.
3. Put only posts sharing the same mode and scheduled date in one call. Split different dates or modes into separately validated and approved calls with distinct keys.
4. Reuse a key only to retrieve an already completed result. If a response failed or its outcome is unknown, inspect state before attempting a new operation; never blindly replay it.
5. Report returned post IDs, states, provider identifiers, release URLs, and errors. Do not claim publication until EveryFeed reports it.

Apply the same review and idempotency discipline to CLI writes. Never invoke a CLI write with --yes unless the user has already approved the exact command and payload in the current conversation.

Manage and analyze

Use MCP listRecentPosts for a quick status check. Use the CLI for filtered post history, post details, state changes, deletion, connection management, notifications, connection analytics, top posts, post analytics, and missing release-ID recovery. Follow references/cli.md and references/troubleshooting.md.

Read-only inspection never authorizes a later write.