Skip to main content
Glama

Connections

by icu.connections
OverviewDiscussionsAdmin

The member's registered MCP servers

connections_mcp_servers
Idempotent

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.6/5.0
Behavior5/5

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

Far beyond what the annotations convey: retire disables the registration exactly as Studio does and drops it out of the unassigned count, restore reverses it, 'nothing here ever deletes', retiring a recently-seen server errors unless force:true because an agent may be running on it, and every write requires the member's bypass-permissions setting or returns studio_only. That is rich operational context the annotations (readOnlyHint=false, idempotentHint=true) cannot express.

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?

Dense but front-loaded: the list trigger comes first, then the assign/retire decision rule, then edge-case behavior and the permissions gate. Nearly every sentence carries a distinct operational fact, though the assign/retire guidance is stated twice in slightly different words.

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 still explains what the reply contains ('leads with how many are unassigned'), covers every failure mode the caller will hit (10-minute force guard, studio_only permission reply), and states that listing always works. Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all four parameters, including the array-of-ids form and the workspace companyId/name choice. The description adds workflow meaning ('an id from the list') and the rationale for array batching, but largely restates what the schema provides, so baseline applies.

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 description names the resource precisely ('Every MCP server this account has registered - each assistant, machine or connector - and which workspace it runs in') and enumerates the four lifecycle actions, so an agent knows this is the registration-management tool rather than a connector discovery tool like connections_explore_connectors. It is distinguishable from siblings without opening any 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?

It gives explicit activation triggers ('whenever the member asks what is connected, why an assistant is in the wrong place, or why a server is not doing anything'), names the default action, and routes to the specific alternative action for each condition. It also warns when NOT to act ('An unassigned server is not automatically one to assign - read the name first'), which is unusually strong guidance.

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