Skip to main content
Glama

Sliq

by com.getsliq
OverviewDiscussionsAdmin

Search Social Posts

search_social_posts
Read-only

Search social listening posts created by the webhook listening pipeline. Use for notifications and ad-hoc questions about social listening results.

Returns a dict with total (full match count), truncated (True when more rows exist past this page — page with offset to reach them), and posts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax results (default 50, max 200)
sinceNoISO datetime or natural language like 'last 24 hours' (optional)
offsetNoRows to skip for paging (default 0). When `truncated` is True, re-call with offset += limit to fetch the next page.
channelNoFilter by channel, for example 'reddit' or 'hacker_news' (optional)
agent_idNoFilter by specific social listening agent. Omit to search across all your agents (inside an agent run, an omitted agent_id defaults to that run's agent).
only_unnotifiedNoOnly return posts not yet included in a digest (default False)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / agent_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Filter by specific social listening agent. Omit to search across\nall your agents (inside an agent run, an omitted agent_id defaults to that\nrun's agent)."
+}
    • removedInput schema / properties / task_id
      Removed value: -{
-  "anyOf": [
-    {
-      "type": "integer"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Filter by specific social listening task. Omit to search across\nall your tasks (inside a task run, an omitted task_id defaults to that\nrun's task)."
-}
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations include readOnlyHint=true, so the safe-read nature is already known. The description adds valuable behavior beyond that: it explains the return structure (dict with `total`, `truncated`, `posts`) and how pagination works (`truncated` indicates more rows and suggests using offset). This goes beyond the schema and helps the agent handle results correctly.

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

Conciseness5/5

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

The description is compact and front-loaded: it states the purpose in the first sentence, usage context in the second, and return contract in the third. No word is wasted, and the structure makes it easy to scan.

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?

Given 6 optional parameters and no output schema, the description covers the essential return shape and pagination behavior. It does not explicitly mention default time window or sort order, but those are not critical for basic invocation finduse. It is complete enough for an agent to call the tool correctly.

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

Parameters3/5

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

Schema description coverage is 100%, with all six parameters documented in the input schema (defaults, types, examples). The tool description itself does not add extra parameter-level nuance, so it stays at the baseline 3 for fully covered schema parameters.

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

Purpose4/5

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

The description clearly states the verb and resource: 'Search social listening posts created by the webhook listening pipeline.' It is specific about the source (webhook pipeline) and distinguishes it from generic post searches, though it does not explicitly name sibling tools to differentiate from them.

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?

Provides explicit usage context: 'Use for notifications and ad-hoc questions about social listening results.' This tells the agent when to invoke it, but it does not mention exclusions or alternative tools, leaving some room for confusion among many search siblings.

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

All Sliq toolsInspect
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