Mark

Update Connection Settings

update_connection_settings

Idempotent

Saves a Google Search Console or GA4 property, or Drive folders to watch. Removing a Drive folder takes its files out of the Library on the next sync; removing the last one takes every Drive file out at once. Posts, the brand logo and claims that use them keep them, and adding the folder back returns them. Pass connectionId from list_connections (search_console, ga4, google, or google_drive). Related: list_connections, sync_connections.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "connectionId": "<connectionId>"
    },
    "name": "update_connection_settings"
  }
}

Input Schema

Name	Required	Description
`product`	No	Required when connectionId is google and you set a property.
`property`	No	Search Console site URL or GA4 property id.
`addFolders`	No	Google Drive folder links or ids to watch.
`connectionId`	Yes	Provider from list_connections, e.g. search_console.
`removeFolderIds`	No	Stored Drive folder ids to stop watching.

Output Schema

Name	Required	Description	Default
`added`	Yes
`appUrl`	Yes
`connectionId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 1, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only say this is a non-read-only, idempotent, non-destructive write; the description goes much further by disclosing the delayed effect of folder removal ('on the next sync'), the cascading case ('removing the last one takes every Drive file out at once'), and that the change is reversible with content retention ('adding the folder back returns them'). This is exactly the side-effect detail an agent needs before mutating watched-folder state.

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?

The core action is front-loaded and there is little waste, but the middle sentence about posts, logo, and claims is dense and slightly hard to parse on first read. The trailing 'Related:' line is compact and useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations, a full-coverage schema, and an output schema, the description covers the remaining burden: consequences of removal, reversibility, and where connectionId comes from. Minor gaps remain around combining addFolders with removeFolderIds in one call and how to discover folder ids.

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 value by enumerating the connectionId values (search_console, ga4, google, google_drive) more completely than the schema's 'e.g. search_console' example, and by framing the property/folder intent. It does not clarify addFolders vs removeFolderIds interplay, which the schema leaves implicit.

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 verb and resource set: saving a Search Console/GA4 property or Drive folders to watch. It is clearly distinguishable from nearby siblings like update_channel_settings, save_site, and sync_connections, which it names as related rather than duplicating.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It tells the agent to pass connectionId from list_connections and lists the accepted providers, and points to sync_connections as the follow-up. It does not explicitly state when to prefer this over update_channel_settings or disconnect_connection, so it stops short of full when/when-not guidance.

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

All Mark tools Inspect

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

Need Help?