Skip to main content
Glama
Sign In

Connections

by icu.connections
OverviewDiscussionsAdmin

Search the Connections operator catalog

connections_search_catalog
Read-only

Use this when the member asks for anything Connections holds that has no dedicated tool in this roster - their contacts and people, notes and memories, events and guest lists, deals, bookings, email, orders and payments, connected services - or when you need an endpoint by name. Searches every API endpoint the member can call in the Connections operator catalog (our own first-party OpenAPI: https://studio.connectionsapi.com/v1/openapi.json, per-plane specs at https://studio.connectionsapi.com/connect) plus your connected third-party services. Returns runnable recipes; pass a result's endpoint_id to connections_execute. A query that IS an endpoint's or a Script Vault instrument's exact tool_name returns that row first, ahead of every fuzzy hit, so naming a row you already know is the cheapest possible query. Blank/omitted query → a BROWSE VIEW: service names + endpoint counts across this whole catalog (too large - tens of thousands of rows - to ever list individually); pass service alongside a blank query to instead list that ONE service's actual endpoint rows (small enough to list directly).

Input Schema

NameRequiredDescriptionDefault
limitNoMax results (1–25, default 8).
queryNoPlain-English description of what you want to do. Blank/omitted → the browse view (service + endpoint counts) instead of a search.
personNoLinked person to run this call as (first name). Omit to run as the connection's holder.
projectNoWorkspace to run this call in (id or name).
serviceNoOptional: restrict to one service (e.g. 'connections', 'aws'). With a blank query, lists that service's endpoints directly.
verboseNoDefault false: each hit lists param NAMES only (compact recipe). true: return each hit's FULL parameters schema (types/locations/required) - use only when you need the exact shape to build a call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / person
      Added value: +{
+  "description": "Linked person to run this call as (first name). Omit to run as the connection's holder.",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / project
      Added value: +{
+  "description": "Workspace to run this call in (id or name).",
+  "type": "string"
+}
  3. Changed1 schema field changed
    • addedInput schema / required
      Added value: +[]
  4. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/openWorld/non-destructive, and the description adds real behavioral context: results are runnable recipes, exact-name queries outrank fuzzy hits, and the full catalog is too large (tens of thousands of rows) to list individually. It doesn't discuss rate limits or pagination beyond the `limit` cap, which keeps it just 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?

The primary use case is front-loaded in the first clause and the rest is dense with load-bearing detail, with no filler sentences. It is a single long paragraph though, and the browse/verbose mechanics buried at the end could be more scannable.

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?

No output schema exists, and the description compensates fully by describing what comes back (runnable recipes with endpoint_id, or a service/count browse view) and the handoff to connections_execute. Given the openWorld, high-cardinality nature of the catalog, this covers everything an agent needs to invoke it correctly.

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 schema already documents all six parameters; the baseline would be 3. The description goes further by explaining the interaction semantics — blank/omitted query yields the browse view, `service` with a blank query lists that one service's endpoints, and `verbose` toggles param names vs full schemas — adding genuine meaning beyond the field descriptions.

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 (search) and resource (every API endpoint in the Connections operator catalog), and explicitly carves out its niche as the catch-all for data with no dedicated tool in the roster. An agent can immediately tell it apart from the many domain-specific siblings like connections_contacts_search or connections_deals_search.

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?

Gives explicit when-to-use (anything Connections holds without a dedicated tool, or needing an endpoint by name), names the downstream alternative (pass endpoint_id to connections_execute), and describes a third mode — passing an exact tool_name to get a deterministic first hit. It even explains how to switch between browse and single-service listing via a blank query plus `service`.

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

All Connections 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