Skip to main content
Glama

Copy a connected service into another of the member's workspaces

connections_copy_connection
Destructive

Copy one connected service (Cloudflare, GitHub, AWS, ...) from one of the member's workspaces into another, so the receiving workspace uses the same account without a new sign-in. The copy SHARES the source's credential - nothing secret is duplicated, read into this conversation or returned. Allowed when BOTH workspaces are the member's own; otherwise the reply is cross_workspace_refused with a reason - say that and do not retry; when the member asked you to do it, mint a one-tap link with connections_copy_connection_link and send them that instead. Name the source EXACTLY ONE way: connectionId (the source row's id, from GET /v1/connected-services in the source workspace), or service (the connector slug, e.g. "ssh") + instance (that connection's instance name) - naming both forms together returns conflicting_source, and naming neither returns missing_source. fromProject defaults to whichever of the member's own workspaces holds that connection, the one this assistant is bound to included; pass it when service + instance matches in more than one workspace (the reply is ambiguous_source, listing each candidate's project_id) or to search only one. A not_found names the workspace searched - pass fromProject, or switch to service + instance, rather than guessing. Pass overwrite with a connection id in the TARGET workspace to replace a dead or duplicate connection in one act: the copy lands first, the old row is disconnected, and the copy takes its name. Returns {connectionId, projectId, instanceName, sharesCredential}.

Input Schema

NameRequiredDescriptionDefault
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).
serviceNoWith `instance`, instead of connectionId: the connector slug of the connection to copy (e.g. "ssh").
instanceNoWith `service`, instead of connectionId: that connection's instance name in the source workspace.
overwriteNoOptional: a connection id IN THE RECEIVING WORKSPACE to replace; the copy takes its name.
toProjectYesThe receiving workspace's project id, ref or company id.
fromProjectNoThe source workspace's project id, ref or company id. Omit to use whichever of the member's own workspaces holds the connection.
connectionIdNoThe SOURCE connection's id (a UUID from /v1/connected-services). Or omit it and pass service + instance instead - exactly one of the two forms.

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. Changed5 schema fields changed
    • changedInput schema / properties / connectionId / description
      Previous value: -"The SOURCE connection's id (a UUID from /v1/connected-services)."New value: +"The SOURCE connection's id (a UUID from /v1/connected-services). Or omit it and pass service + instance instead - exactly one of the two forms."
    • changedInput schema / properties / fromProject / description
      Previous value: -"The source workspace's project id, ref or company id. Omit for the workspace this connection is bound to."New value: +"The source workspace's project id, ref or company id. Omit to use whichever of the member's own workspaces holds the connection."
    • addedInput schema / properties / instance
      Added value: +{
      +  "description": "With `service`, instead of connectionId: that connection's instance name in the source workspace.",
      +  "type": "string"
      +}
    • addedInput schema / properties / service
      Added value: +{
      +  "description": "With `instance`, instead of connectionId: the connector slug of the connection to copy (e.g. \"ssh\").",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "connectionId",
      -  "toProject"
      -]New value: +[
      +  "toProject"
      +]
  4. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the destructiveHint/readOnlyHint annotations: it discloses that the copy SHARES the credential (nothing secret duplicated, read, or returned), describes the overwrite sequence (copy lands first, old row disconnected, copy takes the name), and enumerates the failure codes with their meanings. This is unusually rich mutation semantics for a destructive tool.

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 core action and the share-credential fact, then structured into naming rules, defaults, and overwrite. It is dense and long, but nearly every clause carries either a constraint or an error-handling instruction an agent needs; only the redundancy with the schema's exclusive-form wording is mild waste.

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?

For an 8-parameter, destructive, cross-workspace tool with no output schema, the description covers authorization preconditions, source-naming resolution, ambiguity and not-found recovery, overwrite behavior, and even spells out the return shape {connectionId, projectId, instanceName, sharesCredential}. Nothing an agent needs to invoke 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, but the description adds real meaning: the exactly-one-naming-form rule with its conflicting_source/missing_source consequences, fromProject's default and when to pass it (ambiguous_source), and overwrite's target-workspace requirement. It largely duplicates the built-in schema hints on connectionId/service/instance exclusivity, keeping it from a 5.

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+scope: copy a connected service (Cloudflare, GitHub, AWS) from one member workspace into another, sharing the source credential. It also distinguishes itself from the sibling connections_copy_connection_link by naming that tool for the link-minting case.

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?

Explicit when-to-use (both workspaces must be the member's own) and when-not (cross_workspace_refused — say it and do not retry), and it routes the agent to connections_copy_connection_link when the member asked for a one-tap link. The error-driven alternatives (not_found, ambiguous_source) also tell the agent exactly what to do next.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources