Sliq

Query Companies

query_companies

Read-only

Columns: id, display_name, domain (normalized bare host), linkedin_company_id, owner_email, data (JSONB), created_at, updated_at. Sliq's CRM is deals and tasks: to see whether a company has a deal or a task, use query_deals (status='all') / query_crm_tasks with company_id. JSONB queries: data->>'some_key' ILIKE '%...%'.

Firmographic columns (captured from company enrichment; blank/NULL until enriched): linkedin_url (bare slug), industry, description, location (HQ), logo_url, employee_count, follower_count, founded_year, company_type, annual_revenue, total_funding, latest_funding_stage.

To list the people you know at a company, take an id from here and call query_people with where_clause="company_profile_id = <id>".

Pass group_by for per-bucket counts over ALL your companies instead of a row list — a whole-set aggregate, never capped at the 200-row limit, so it answers "how many companies per industry/location" without paging. Ignores where_clause. In row mode (group_by omitted) — a dict with count, truncated, and items array (each row {id, display_name, domain, linkedin_company_id, owner_email, linkedin_url, industry, description, location, logo_url, employee_count, follower_count, founded_year, company_type, annual_revenue, total_funding, latest_funding_stage, data, created_at, updated_at}). In aggregate mode (group_by set) — a dict {group_by, groups} where groups is a list of {key, count} ordered by count descending.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	Max results (default 50, capped at 200).
`offset`	No	Rows to skip for paging (default 0). When the result is truncated, re-call with offset += limit for the next page.
`group_by`	No	Aggregate mode, returned instead of the row list — whole-set per-bucket counts over all your companies (not capped by `limit`), bucketed by "industry" or "location". Omit for the row list.
`order_by`	No	SQL ORDER BY (default: created_at DESC).	created_at DESC
`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 condition (default: all your companies). Examples: "domain = 'stripe.com'", "display_name ILIKE '%acme%'".	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."
+}

Changed1 schema field changedSep 16, 2026

addedInput schema / properties / group_by

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "industry",
+        "location"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Aggregate mode, returned instead of the row list — whole-set per-bucket counts\nover all your companies (not capped by `limit`), bucketed by \"industry\" or \"location\".\nOmit for the row list."
+}

First observedSep 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the readOnlyHint annotation: explains rows accrue from contacts' employers/searches/domain lookups, that a company may have no linked people, that firmographic columns are blank/NULL until enriched, and that group_by is a whole-set aggregate never capped by limit and ignores where_clause. This is exactly the kind of context annotations cannot carry.

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 with the core purpose, then logically grouped into columns, firmographics, relationships, and aggregation, with a separate returns block. It is lengthy, but each block (routing, column list, group_by semantics) carries distinct decision-relevant information, so almost every sentence earns its place.

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?

For a 6-parameter, heavily-siblinged query tool with no structured output_schema, the description supplies the return shape inline (row mode vs aggregate mode), paging behavior, and relationship navigation. Nothing an agent needs to select or invoke it correctly is missing.

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 already 100%, so the baseline is 3; the description adds real interpretation on top, clarifying that group_by returns per-bucket counts over ALL companies rather than a capped row list and that it ignores where_clause. It also documents the JSONB query pattern (data->>'key' ILIKE). Marginal but genuine value over 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 ('Query your canonical companies') and defines the entity precisely as 'one deduped row per real-world company.' It explicitly distinguishes this from the sibling query_monitored_companies ('NOT the LinkedIn post-monitoring list'), so an agent can route without opening either schema.

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?

Names concrete use cases (look a company up by domain, list tracked companies, answer company-entity questions) and explicitly routes adjacent needs to siblings: query_deals/query_crm_tasks for deal/task status and query_people for the people at a company. It also states the group_by alternative and its tradeoff, leaving little to inference.

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?