publish_pipeline_item
Publish approved INTERNAL content to configured output. ROUTING: team_update sends to all team members via Freedom OS, report sends to specified team member emails, customer_newsletter requires user Email MCP connection (Mailchimp, Resend, etc.), changelog publishes to public changelog page. ⚠️ S...
This record as markdown: /tools/com-getfreedomos-freedom-mcp/publish-pipeline-item.md
What publish_pipeline_item does on Freedom Mcp
AI agents use publish_pipeline_item to create or update resources in Freedom Mcp, usually the action step of a workflow, after the agent has gathered context. Every call changes real data in your Freedom Mcp environment.
| Parameter | Type | Required | Description |
|---|---|---|---|
item_id | string | Yes | ID of the approved pipeline output to publish (get from get_pending_approvals, must be approved status) |
companyId | string | Yes | FreedomOS company id to act within (you must be a member). Required for company-scoped tools. |
recipients | array | — | Optional. Specific team member emails to send to (must be in company_members). If not specified, sends to all team members. |
Parameters from the server's own tool schema.
Why publish_pipeline_item is rated Medium
This tool creates and distributes content across multiple channels (internal team updates, emails, newsletters, public changelog). It is Write category because it creates/publishes data reversibly (content can be retracted or modified in follow-up actions).
From the tool's definition Publish approved INTERNAL content to configured output. ROUTING: team_update sends to all team members via Freedom OS, report sends to specified team member emails, customer_newsletter requires user Email MCP connection (Mailchimp, Resend, etc.), changelog…
Attacks that exploit this kind of access
The rule that runs publish_pipeline_item safely
PolicyLayer is an MCP gateway: it sits between your AI agents and Freedom Mcp, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For publish_pipeline_item, this is the rule to start with:
publish_pipeline_item stays usable, but capped: an agent stuck in a loop can't make hundreds of changes a minute. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect Freedom Mcp, apply this rule, and every publish_pipeline_item call is checked against it from then on.
Questions about publish_pipeline_item
Publish approved INTERNAL content to configured output. ROUTING: team_update sends to all team members via Freedom OS, report sends to specified team member emails, customer_newsletter requires user Email MCP connection (Mailchimp, Resend, etc.), changelog publishes to public changelog page. ⚠️ SOCIAL POSTS (x/linkedin/instagram/facebook/threads) never send from this tool: declare the pipeline destination via update_pipeline and submit via submit_content_to_pipeline — the post queues for operator approval and publishes through the single gated owner on approve (in FreedomOS app chat, send_to_user with intent "publish" queues the same approval). Use when an approved non-social item — changelog, team update, report, or newsletter — is ready to send. [outbound-tier — first use may require a manager's approval; a from-now-on approval makes future calls seamless, a just-once approval re-asks next time.]. It is categorised as a Write tool in the Freedom Mcp MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.
publish_pipeline_item accepts 3 parameters: item_id, companyId, recipients. Required: item_id, companyId. The full parameter table on this page comes from the server's own tool schema.
Register the Freedom MCP server in PolicyLayer and add a rule for publish_pipeline_item: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Freedom Mcp. Nothing to install.
publish_pipeline_item is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.
Yes. Add a rate_limit block to the publish_pipeline_item rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for publish_pipeline_item. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
publish_pipeline_item is provided by the Freedom MCP server (https://twuluxmoognlwtmaoqgo.supabase.co/functions/v1/freedom-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on Freedom, and thousands of servers like it.
This server
Across the catalogue