Agent Rules

Agent Rules

Safety and correctness rules for AI agents acting on a user's behalf through the Pharlo MCP server or REST API. Following these keeps actions predictable, avoids wasted credits, and protects user accounts.

These rules are the behavioral contract behind the Agent Workflows and the error catalog (opens in a new tab). When a rule and a tool description disagree, prefer the tool's live response.

Publishing

  • Never publish without an explicit platform and connection. Resolve the target channel via list_connections and confirm it with the user before calling create_assignment. Do not guess which channel "they probably meant."
  • Confirm platform support before building a payload. Call get_platform_capabilities and shape payload to the fields it returns. Never invent fields the platform does not accept.
  • Do not assume a platform is live. Live platforms are YouTube and Facebook only. Platforms such as TikTok or Instagram may appear in list_platforms but are not publishable until get_platform_capabilities confirms it. Tell the user plainly when their target is not yet supported.

Scheduling

  • Require an explicit date, time, and timezone. Never schedule against a vague "later" or "tomorrow" without resolving an exact timestamp with the user. Echo back the resolved time before scheduling.
  • Cancel vs. reschedule. To change timing or content of a not-yet-published post, use update_assignment — do not cancel_assignment and recreate. Cancellation is irreversible.

Media

  • Use upload sessions for large local files. When the user has a local file and no public URL, create an upload session (create_assignment_upload_session), hand them the upload page, and poll get_assignment_upload_session until completed before publishing. See Large-file upload.
  • Never fabricate media metadata. Do not invent file names, MIME types, sizes, or placeholder URLs. The upload page detects file details from the user's selection.

Failure handling

  • Don't retry blindly. Before retry_assignment, read the failure reason via get_assignment and fix the root cause. Retrying an expired-token or insufficient-credits failure without fixing it will just fail again — and may consume credits.
  • On insufficient_credits (HTTP 402) — stop and tell the user to top up before retrying. Do not loop. See the error catalog (opens in a new tab).
  • On expired tokens — reconnect via get_oauth_connect_url (with the existing connectionId) and poll check_oauth_status; only then retry the action.

Verifying delivery

  • Confirm, don't assume. After publishing or scheduling, verify the result with get_assignment (status) or by inspecting webhook deliveries (list_webhook_deliveries). A returned assignmentId is not proof the post went live.

Secrets

  • Never expose or echo credentials. Do not print, log, or repeat back API keys (ds_live_...), OAuth tokens, or MCP Bearer tokens — not to the user, not in tool arguments, not in examples.
  • Never paste a user's secret into a third-party tool or send it to any endpoint other than Pharlo's documented surfaces.

Billing awareness

  • Surface credit costs. Some tools consume credits (see per-tool annotations in the tool reference). When an action will spend credits or has already failed on a spending limit, tell the user before proceeding rather than retrying silently.

Related docs

Agent Workflows · Tool reference · Error Handling guide · Error catalog (opens in a new tab)