Sliq

Query Monitored Companies

query_monitored_companies

Read-only

mode="search" (default): individual company rows. mode="stats": aggregate counts, with optional group_by for analytics.

Columns: display_name, domain, stage ('active'/'removed'), data (JSONB), agent_id, created_at, updated_at. JSONB queries: data->>'last_sweep_status' = 'error'. For outreach prospects, call query_prospects. In search mode, {count, truncated, items array}. In stats mode, {total, by_stage: {active: N, removed: M}, groups?: {: {total, by_stage}}}.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`mode`	No	"search" to list rows, "stats" for aggregate counts.	search
`limit`	No	Max results (default 50, capped at 100). Search mode only.
`offset`	No	Rows to skip for paging (default 0, search mode only). When the result is truncated, re-call with offset += limit for the next page.
`agent_id`	No	Filter to a specific agent. Omit for cross-agent queries.
`group_by`	No	(stats mode only) JSONB data key to group by; each group carries the same by_stage map as the top-level stats.
`order_by`	No	SQL ORDER BY (default: created_at DESC). Search mode only.	created_at DESC
`where_clause`	No	SQL WHERE condition (default: all). Examples: "stage = 'active'", "domain ILIKE '%.io'"	1=1

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 23, 2026

addedInput schema / properties / agent_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Filter to a specific agent. Omit for cross-agent queries."
+}

removedInput schema / properties / task_id

Removed value: -{
-  "anyOf": [
-    {
-      "type": "integer"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Filter to a specific task. Omit for cross-task queries."
-}

First observedSep 15, 2026

TDQS

A4.3/5.0

Behavior4/5

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

The readOnlyHint annotation already establishes the safety profile, and the description adds useful behavior beyond it: mode-specific return shapes, a truncation signal, the columns list, and a JSONB query example. It does not mention auth or rate limits, but those are less critical for an explicitly read-only query tool.

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 well-structured: modes and scope are front-loaded, followed by return shapes. The columns and JSONB note earn their place because they directly help agents construct valid where_clause and group_by arguments.

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?

With no output schema, the description supplies complete return shapes for both modes, including the truncated paging flag. It covers mode selection, grouping, JSONB filtering, pagination-relevant return data, and the prospect alternative, making the tool usable end-to-end.

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%, so the baseline is 3 even without extra parameter detail. The description adds a useful JSONB where_clause example and clarifies mode/group_by interplay, but most parameter semantics are already fully documented in the input 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?

The description opens with a specific verb and resource: 'Query an agent's monitored companies.' It clearly distinguishes two modes (search vs stats) and explicitly routes outreach-prospect queries to query_prospects, which separates it from a closely related sibling.

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?

The description gives clear mode-selection guidance: search for individual rows, stats for aggregate counts, and group_by for analytics. It also explicitly tells agents to use query_prospects for outreach prospects, though it does not contrast with sibling query_companies.

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?