Sliq

Queue Linkedin Post Engagement

queue_linkedin_post_engagement

Destructive

Exactly one of comment_text or reaction_type must be provided.

For a comment, pass comment_text (the text to post). For a reaction, pass reaction_type (one of 'like', 'celebrate', 'support', 'love', 'insightful', 'funny'). The agent picks reaction_type='like' by default for most posts; the user can change it on the approval card.

Resolves the post's social_id (URN format) from the URL, then creates a linkedin_invite_queue item with action_type='comment' or 'reaction' depending on which body field was set. The pre_save signal resolves the per-subtype approval policy — gate (pending_approval) or auto-send (pending).

With on_behalf_of it queues account-level on that account's queue, tied to none of your agents. A queued-status dict in one of three forms. {'queued': True, 'awaiting_approval': bool, 'message': str} on success; awaiting_approval is False when the engagement will post automatically {'queued': False, 'deduped': True, 'message': str} when this post already has a live engagement of the same kind (report the message; not an error) {'queued': False, 'error': str} on resolution failure

Input Schema

TableJSON Schema

Name	Required	Description
`post_url`	Yes	LinkedIn post URL (e.g. 'https://linkedin.com/posts/...-activity-123-...')
`post_text`	No	Excerpt of the post text (for the approval card display)
`author_name`	No	Name of the post author (for the approval card display)
`comment_text`	No	The comment text to post. Mutually exclusive with reaction_type.
`on_behalf_of`	No	A teammate's email (one with team actions turned on), or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account.
`reaction_type`	No	One of 'like', 'celebrate', 'support', 'love', 'insightful', 'funny'. Mutually exclusive with comment_text.
`prospect_identifier`	No	The warming prospect's tracking-item identifier (LinkedIn URL/slug) — links this engagement back to the prospect for the system-maintained `data.comments_posted` (comments) or `data.reactions_posted` (reactions) counter. Required for warm-up flow; safe to omit for one-off engagements unconnected to a warm-up campaign.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026

changedInput schema / properties / on_behalf_of / description

Previous value: -"Queue the engagement on a consented teammate's account instead\nof your own — pass their email. It lands as a standalone (account-level)\nengagement on their queue, not tied to any of your agents. Gated on that\nteammate's act-on-behalf setting; a teammate who hasn't granted it is\nrejected. Omit for your own.\nOr pass an agency client's email, from list_agency_clients, to run the call in that client's account, where none of the teammate limits above apply."New value: +"A teammate's email (one with team actions turned on), or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."

Changed2 schema fields changedOct 19, 2026

removedInput schema / properties / as_teammate

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Queue the engagement on a consented teammate's account instead\nof your own — pass their email. It lands as a standalone (account-level)\nengagement on their queue, not tied to any of your agents. Gated on that\nteammate's act-on-behalf setting; a teammate who hasn't granted it is\nrejected. Omit for your own."
-}

addedInput schema / properties / on_behalf_of

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Queue the engagement on a consented teammate's account instead\nof your own — pass their email. It lands as a standalone (account-level)\nengagement on their queue, not tied to any of your agents. Gated on that\nteammate's act-on-behalf setting; a teammate who hasn't granted it is\nrejected. Omit for your own.\nOr pass an agency client's email, from list_agency_clients, to run the call in that client's account, where none of the teammate limits above apply."
+}

Changed1 schema field changedSep 23, 2026

changedInput schema / properties / as_teammate / description

Previous value: -"Queue the engagement on a consented teammate's account instead\nof your own — pass their email. It lands as a standalone (account-level)\nengagement on their queue, not tied to any of your tasks. Gated on that\nteammate's act-on-behalf setting; a teammate who hasn't granted it is\nrejected. Omit for your own."New value: +"Queue the engagement on a consented teammate's account instead\nof your own — pass their email. It lands as a standalone (account-level)\nengagement on their queue, not tied to any of your agents. Gated on that\nteammate's act-on-behalf setting; a teammate who hasn't granted it is\nrejected. Omit for your own."

First observedSep 15, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial context beyond the annotations: it discloses the approval gate vs auto-send path, dedup behavior (existing live engagement of the same kind), the account-level scoping rule for on_behalf_of, and how the outcome is surfaced. Nothing here contradicts destructiveHint=true / readOnlyHint=false, and the mutation consequences are well explained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The summary is front-loaded and the mutually-exclusive rule is stated early, so the important parts come first. It is somewhat bloated by internal implementation detail ('pre_save signal', 'linkedin_invite_queue item with action_type=...') that does not help an agent decide or call correctly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description embeds a full returns block covering success (queued/awaiting_approval/message), dedup, and error forms, plus the comment-vs-reaction requirement. For a 7-param mutation tool this is complete enough to invoke safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, but the description adds real meaning: exactly-one-of comment_text/reaction_type, the default 'like' choice and where the user can change it, and that prospect_identifier is required for warm-up flows but safe to omit otherwise. This goes well past restating the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Queue an engagement (comment or reaction) on a LinkedIn post') and immediately distinguishes its scope from read-side siblings like query_linkedin_post_engagements. An agent knows exactly what this tool does without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear when-to-use context: default lands in pending_approval unless auto-approve is enabled for the linkedin_comment/linkedin_reaction subtype, and it instructs the agent to relay the returned message rather than promise review. It does not name an alternative sibling for the queuing decision, so it stops short of full alternative routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Sliq tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?