Sliq

Query Linkedin Post Engagements

query_linkedin_post_engagements

Read-only

Use this to find warm leads, identify who engaged with specific posts, or filter engagers by role/company. Chain with query_linkedin_posts when drilling into a specific post, or filter on the post_analytics_id that fetch_post_engagers returns ("post_id = 42").

Columns: id, post_id, engagement_type ('reaction'|'comment'), reaction_value (LIKE|ENTERTAINMENT|EMPATHY|PRAISE|INTEREST|APPRECIATION, empty for comments), author_name, author_provider_id, author_headline, author_profile_url, comment_text, engaged_at, fetched_at, created_at. Dict with count, truncated, and engagements array (each row carries the columns above).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	default 50, max 200.
`offset`	No	Rows to skip for paging (default 0). When the result is truncated, re-call with offset += limit for the next page.
`order_by`	No	default "engaged_at DESC NULLS LAST" (comments have timestamps, reactions don't).	engaged_at DESC NULLS LAST
`on_behalf_of`	No	An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account.
`where_clause`	No	SQL WHERE. Examples: "engagement_type = 'comment'" "author_headline ILIKE '%VP%'" "post_id = 42" "engagement_type = 'reaction' AND reaction_value = 'PRAISE'"	1=1

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 19, 2026

addedInput schema / properties / on_behalf_of

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
+}

First observedSep 15, 2026

TDQS

A4.5/5.0

Behavior4/5

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

readOnlyHint=true already covers the safety profile, but the description adds real context beyond annotations: the source of the rows, the fact that comments carry timestamps while reactions don't (explaining the default ordering), and the shape of the return (count, truncated, engagements). It does not discuss rate limits or credit cost, so it falls short of a 5.

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?

Front-loaded summary, then usage/chaining, then a compact column glossary – a rational order with little waste. The column enumeration is dense but earns its place as the only place these fields are documented, though it makes the block longer than strictly necessary.

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

Completeness4/5

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

For a 5-param read tool with no output schema, the description plus inline <returns> covers paging (truncated/offset), default ordering, and row columns well. The only gap is the post_analytics_id vs post_id naming ambiguity, which could cause a wrong WHERE clause on first use.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: it enumerates engagement_type and reaction_value values and the author columns, and gives where_clause examples. It loses a point for a naming inconsistency – it points at 'post_analytics_id that fetch_post_engagers returns' then illustrates with 'post_id = 42', while the column list only defines post_id.

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?

Opens with a specific verb+resource ('Query individual reactions/comments on tracked LinkedIn posts') and immediately scopes the data source (own posts plus third-party posts from fetch_post_engagers). This distinguishes it cleanly from siblings like fetch_post_engagers (which fetches) and query_linkedin_posts (which returns posts, not engagers).

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

Usage Guidelines5/5

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

Explicit use cases ('find warm leads, identify who engaged with specific posts, filter engagers by role/company') plus explicit chaining guidance with query_linkedin_posts and the upstream producer fetch_post_engagers. An agent knows both when to reach for this tool and how to sequence it.

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?