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_slug (the LinkedIn company page's lowercase slug: 'acme-corp' for linkedin.com/company/acme-corp), 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>".

For how many companies are in each industry or location, or which companies are in one of those groups, call list_companies: it reads the Companies table the way the user sees it, over every company without paging for the counts. A dict with count, truncated, and items array (each row {id, display_name, domain, linkedin_company_id, owner_email, linkedin_slug, 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}).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "query_companies"
  }
}

Input 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.
`order_by`	No	SQL ORDER BY (default: created_at DESC).	created_at DESC
`on_behalf_of`	No	A teammate's email, 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.
`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 changedNov 6, 2026

changedInput schema / properties / on_behalf_of / description

Previous value: -"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."New value: +"A teammate's email, 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."

Changed1 schema field changedOct 27, 2026

removedInput schema / properties / group_by

Removed 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."
-}

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?

Beyond the readOnlyHint annotation, the description discloses that rows accrue from contacts' employers, company searches, and domain lookups, so a company may have zero linked people — a non-obvious data-quality caveat. It also flags that firmographic columns are blank/NULL until enrichment, preventing an agent from misinterpreting empty fields as absent data, and documents the JSONB query idiom.

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?

It is long but well front-loaded: canonical-entity definition and sibling exclusions come first, with columns, JSONB syntax, firmographics, and cross-tool routing as clearly separated blocks. The one inefficiency is enumerating the full column list in the description and then again verbatim in the <returns> block.

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?

There is no output schema, but the embedded <returns> block specifies the dict shape (count, truncated, items) and every row field, so return values are covered. Combined with the enrichment caveats, paging notes, and cross-tool routing, an agent has everything needed to call this correctly on the first try.

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, and the description adds genuine meaning on top: it explains the JSONB access pattern (`data->>'some_key' ILIKE '%...%'`) and clarifies the filterable columns by listing them explicitly, which helps an agent write a valid where_clause. It stops short of discussing on_behalf_of or order_by semantics, which remain schema-only.

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 first sentence names a specific verb and resource ('Query your canonical companies (`company_profiles`)') and immediately defines the entity as one deduped row per real-world company. It explicitly differentiates itself from siblings: 'This is the canonical company entity, NOT the LinkedIn post-monitoring list — for companies whose posts an agent watches, use query_monitored_companies.'

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?

It gives concrete use cases ('find the company row for stripe.com', list tracked companies) and routes each adjacent need to the correct alternative: query_monitored_companies for watched companies, query_deals/query_crm_tasks for CRM status, query_people for linked people, and list_companies for grouped counts. Nothing about when-to-use is left 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?