Skip to main content
Glama
Sign In

Connections

by icu.connections
OverviewDiscussionsAdmin

Explore connectable services (the connector registry)

connections_explore_connectors
Read-only

Use this to see what services Connections can connect - the whole connector registry (Stripe, GitHub, Cloudflare, AWS, Discord, ...) - and which of them THIS workspace already has. Search it like a package registry: pass a query to narrow by name or purpose, or leave it blank to list everything. Each connector returns its lanes (oauth / key / provision / broker), whether it is connected here, its public page, and a connect_url. A connected connector's endpoints are searchable with connections_search_catalog; an unconnected one's are NOT, by design - so when a task needs a service that is missing, hand the human its connect_url. If one of the human's OTHER workspaces already holds it, the result carries copyable_from with a copy_url - hand them that instead, to open while they are in the workspace that should receive it; the console copies the connection with one click. When both workspaces are the member's own, copy it yourself with connections_copy_connection instead of handing over the link. You cannot connect anything yourself and must never ask a human to paste a credential to you.

Input Schema

NameRequiredDescriptionDefault
limitNoMax connectors to return (1–50, default 50).
queryNoOptional name or purpose to narrow by (e.g. 'payments', 'github'). Blank → the whole registry.
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).
connectedNoOptional filter: true → only connectors this workspace has connected; false → only ones it could connect.

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. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/non-destructive, but the description adds substantive behavior: it discloses each result's fields (lanes, connected flag, page, connect_url, copyable_from), the design rule that unconnected endpoints are NOT searchable, and hard constraints — the agent cannot connect anything and must never ask a human to paste a credential.

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 purpose before the operational detail, and nearly every clause carries information. It is dense and slightly run-on in the connect_url/copyable_from section, but no sentence is filler.

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 takes on the burden of describing return values and does so fully (lanes, connected status, connect_url, copyable_from/copy_url). For a read-only registry lookup with fully documented params, nothing an agent needs to call 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 100%, so the baseline is 3; the description still adds meaning by explaining that query matches name OR purpose and that blank means the whole registry, which is behavior the schema only hints at. The connected and person/project parameters are left to 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: see the whole connector registry and which ones this workspace already holds, with concrete examples (Stripe, GitHub, Cloudflare). It is clearly distinguishable from connections_search_catalog (endpoint search) and connections_copy_connection (copying), so an agent can route without opening schemas.

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?

Explicitly says when to use it (task needs a service that's missing), how to query it (pass a query or leave blank for everything), and names the alternatives: connections_search_catalog for connected endpoints, connections_copy_connection when both workspaces are the member's own, and hand over connect_url/copy_url otherwise.

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