Skip to main content
Glama

Start provider connection

provider_connect_handoff

Creates a connection link for the person represented by the current actor.

The link carries only an attempt ID and grants nothing: the browser signs in, refuses anyone but this person, then runs provider consent and required choices. No dashboard is needed. Each call creates a new attempt, valid for 30 minutes. Only read scope is required because the link is inert: the person's browser session authorizes every step. provider_status exposes configuration; configured=false means required deployment configuration is missing. browser_url is the person's connection page. readback_tool with readback_arguments reports that exact attempt after browser completion. Google Drive ends with file selection in Google Picker; Gmail ends with support-address selection. Meta connects only Facebook accounts with a role on Replai's Meta app until Meta grants Advanced Access. No provider code, state, token or secret is accepted or returned. LINE credentials belong only on the connect page, never in chat.

Input Schema

NameRequiredDescriptionDefault
localeNoLanguage of the person's provider-connection page.en
agent_idYesAgent ID from agents_list or agent_create.
providerYesProvider for the new browser connection attempt.

Output Schema

NameRequiredDescriptionDefault
cancelYes
resumeYes
statusYes
expiredYes
agent_idYes
providerYes
attempt_idYes
expires_atYes
browser_urlYes
browser_pathYes
workspace_idYes
readback_toolYes
workspace_nameYes
readback_argumentsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / agent_id / description
      Added value: +"Agent ID from agents_list or agent_create."
    • addedInput schema / properties / locale / description
      Added value: +"Language of the person's provider-connection page."
    • addedInput schema / properties / provider / description
      Added value: +"Provider for the new browser connection attempt."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

It discloses that the link is inert, carries only an attempt ID, grants nothing, expires in 30 minutes, creates a new attempt each call, requires only read scope, and refuses anyone but the represented person. It also describes provider-specific completion behavior for Google Drive, Gmail, Meta, and LINE, plus security constraints around provider secrets.

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 dense but front-loaded and every sentence adds operational or security-relevant information. There is no filler, repeated boilerplate, or unnecessary restatement of the input schema.

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?

An output schema exists, so return-value documentation is not required. With annotations covering safety hints and the description covering link mechanics, expiry, auth behavior, provider quirks, and secret-handling constraints, an agent has enough information to invoke the tool 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 100%, so the schema already documents agent_id, provider, and locale. The description adds provider-specific meaning beyond the enum values, such as Google Picker ending, Gmail support-address selection, Meta limited Facebook-account access, and LINE credentials staying on the connect page.

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 opening sentence states a specific verb and resource: creates a connection link for the person represented by the current actor. It is clearly distinguishable from sibling tools such as provider_status, provider_connect_attempt_read, and provider_disconnect.

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?

The description explains the intended flow, points to provider_status for configuration checks, states that configured=false means deployment configuration is missing, and says readback_tool reports the exact attempt after browser completion. It stops short of an explicit 'use this when / do not use when' comparison, but the operational context is clear.

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