Skip to main content
Glama
Sign In

Antwork

by io.antwork
OverviewDiscussionsAdmin

get_connection_urls

Read-only

Get the links to connect or re-auth social accounts.

Returns an OAuth connect URL per platform, for the user to open. This is the tool for MANAGING connections — connecting a new account, reconnecting a stale one, or seeing the connect options. For reading what's already connected, list_social_accounts is the lighter call.

Args: workspace_id: Workspace ID or name. Optional if user has only one workspace.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_connection_urls"
  }
}

Input Schema

NameRequiredDescriptionDefault
contextNoThe user's underlying goal for this call, in one sentence without personal details. Used for product analytics only.
llm_modelNoThe model identifier of the calling assistant, or "unknown". Used for product analytics only.
workspace_idNo
conversation_idNoPass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.

Output Schema

NameRequiredDescriptionDefault
_mcp_instructionsNoServer-issued metadata for this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / required
      Previous value: -[
-  "context",
-  "llm_model"
-]New value: +[]
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already establish readOnly=true and destructive=false, and the description adds useful behavior beyond them: the output is a per-platform OAuth URL intended for the user to open, so the agent knows the next step is a user-facing handoff rather than server-side work. It does not mention expiry or whether URLs are single-use, which would have pushed this higher.

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 purpose and the routing to list_social_accounts are front-loaded in two short paragraphs, with only the workspace_id note deferred to an Args block. Very little waste; the Args heading is slightly heavier than necessary for a single described parameter.

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 an output schema present, return values need not be spelled out, yet the description still tells the agent what the payload conceptually is (one connect URL per platform). Combined with the sibling routing and the workspace_id rule, an agent has everything needed to call it correctly.

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 75%, and the description fills the main gap by explaining workspace_id accepts a name as well as an ID and is optional for single-workspace users — semantics the bare schema does not convey. The analytics parameters (context, llm_model) and conversation_id are already well documented in the schema and need no elaboration here.

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 first sentence states a specific verb and resource ('Get the links to connect or re-auth social accounts') and the second explains exactly what comes back: an OAuth connect URL per platform for the user to open. It is readily distinguishable from the read-oriented sibling list_social_accounts.

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 enumerates the three situations this tool serves — connecting a new account, reconnecting a stale one, viewing connect options — and names the alternative ('For reading what's already connected, `list_social_accounts` is the lighter call'). When-to-use and when-not-to-use are both covered.

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

All Antwork 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