Skip to main content
Glama

Connections

by icu.connections
OverviewDiscussionsAdmin

The member's registered MCP servers

connections_mcp_servers
DestructiveIdempotent

Every MCP server this account has registered - each assistant, machine or connector - and which workspace it runs in. CALL IT WITH action:'list' whenever the member asks what is connected, why an assistant is in the wrong place, or why a server 'is not doing anything': an UNASSIGNED server is bound to no workspace, so its tools answer no_company_assigned and it looks broken. The reply leads with how many are unassigned. An unassigned server is not automatically one to assign - read the name first. A real project whose workspace exists gets action:'assign' with server (an id from the list) and workspace (a companyId or the exact name). A dead end - a scratch folder, a machine name, a browser version, a throwaway agent codename last seen weeks ago - gets action:'retire', which disables the registration exactly as switching it off in Studio does and drops it out of the unassigned count. Binding a dead row to a workspace invents a fact and cleans nothing. Both assign and retire take an ARRAY in server too, so a whole backlog is one call. 'restore' undoes a retire; nothing here ever deletes. Retiring a server seen in the last 10 minutes returns an error unless force:true, because an agent is probably running on it - pass force:true only if you mean to cut that session off. Every write needs the member's bypass-permissions setting to be ON; when it is off the reply is studio_only with the link, so say that rather than retrying. Listing always works.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoFor retire: act even on a server seen in the last 10 minutes. Default false.
actionNo'list' (default), 'assign' a real project to a workspace, 'retire' a dead registration, or 'restore' a retired one.
serverNoThe server id from the list, or an array of ids to act on in one call.
workspaceNoFor assign: companyId (preferred) or the exact workspace name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / required
      Added value: +[]
  2. Changed6 schema fields changed
    • changedInput schema / properties / action / description
      Previous value: -"'list' (default) or 'assign'."New value: +"'list' (default), 'assign' a real project to a workspace, 'retire' a dead registration, or 'restore' a retired one."
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "list",
-  "assign"
-]New value: +[
+  "list",
+  "assign",
+  "retire",
+  "restore"
+]
    • addedInput schema / properties / force
      Added value: +{
+  "description": "For retire: act even on a server seen in the last 10 minutes. Default false.",
+  "type": "boolean"
+}
    • addedInput schema / properties / server / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  }
+]
    • changedInput schema / properties / server / description
      Previous value: -"For assign: the server id from the list."New value: +"The server id from the list, or an array of ids to act on in one call."
    • removedInput schema / properties / server / type
      Removed value: -"string"
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark it destructive and idempotent, but the description adds substantial context beyond them: retire disables the registration, nothing ever deletes, restore undoes retire, the 10-minute recent-use guard with force:true, and the bypass-permissions requirement producing a studio_only reply. These are non-obvious behaviors an agent needs.

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?

Long, but front-loaded with the action framing and each clause carries distinct operational content (list semantics, assign criteria, retire criteria, guard rail, auth failure mode). Slightly dense to the point of being a wall of text, but no wasted sentences.

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, yet the description describes the reply shape ('leads with how many are unassigned') and the two error/refusal modes (force guard, studio_only), plus confirms listing always works. Complete for a 4-param stateful admin tool.

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 baseline is 3, but the description adds meaning beyond the schema: `server` accepts an ARRAY for backlog operations, `workspace` takes a companyId or exact name, and force only applies to retire on recently-seen servers. Marginal but genuine added value.

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+resource ('every MCP server this account has registered... and which workspace it runs in') and enumerates the action surface (list/assign/retire/restore). Clearly distinguishable from sibling tools like connections_accounts or connections_list_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?

Gives explicit triggers ('CALL IT WITH action:list whenever the member asks what is connected, why an assistant is in the wrong place, or why a server is not doing anything') and explicit selection rules between assign and retire, including the 'an unassigned server is not automatically one to assign' exclusion.

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