Skip to main content
Glama
Sign In

Connections

by icu.connections
OverviewDiscussionsAdmin

My 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

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.
personNoLinked person to run this call as (first name). Omit to run as the connection's holder.
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 / 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 / required
      Added value: +[]
  3. 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"
  4. Added

TDQS

A4.7/5.0
Behavior5/5

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

The description adds substantial behavioral context beyond the annotations: unassigned servers answer no_company_assigned, the reply leads with the unassigned count, retire disables rather than deletes, restore reverses retire, recent servers require force:true, and write actions need bypass-permissions enabled. These details materially help an agent interpret results and avoid unsafe retries.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but dense and front-loaded: it opens with what the tool covers and the first action to call, then proceeds through assignment, retirement, restoration, errors, and permissions. Every sentence carries operational information relevant to correct invocation.

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?

Given a multi-action tool with no output schema and potentially destructive retire behavior, the description covers return-shape hints, error behavior, permission prerequisites, batching, and irreversible-looking-but-restorable actions. Nothing essential to safe use appears 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 individual parameters are already well documented. The description reinforces the meaning of action, server arrays, workspace identifiers, and force, but does not add much beyond the schema and does not explain the person parameter. Baseline 3 is appropriate.

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 states a specific resource and scope: every MCP server registered to the account, its workspace binding, and the four actions (list, assign, retire, restore). This is much stronger than a tautological restatement of the name and lets an agent distinguish it from sibling connection/account tools.

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 explicitly says when to call with action:'list' — when the member asks what is connected, why an assistant is misplaced, or why a server appears broken. It also gives decision rules for assign versus retire, including how to distinguish a real project workspace from a dead-end registration, and explains restore.

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