Skip to main content
Glama

elaichi__connection__create

Start connecting a third-party account. Creates the connection with status "pending" and returns { connection, connect_url }. Elaichi cannot finish the provider’s login on the user’s behalf — connect_url is a one-time connect session a HUMAN opens in a browser, and the connection only becomes "active" once they have. Never ask for, accept, or repeat a credential in chat — no operation here takes one. When you already know which app the user means, resolve connector_slug with connector.list first; whether you may omit it otherwise depends on the surface, see below. shares defaults to empty, which makes the connection private to the caller (needing only connection:create); passing any entries shares it with a person, a team, or the whole organization in the same call and additionally requires the connection:share permission — refused, not silently dropped, without it. Prefer leaving shares empty unless the user actually asked for a shared account; access can always be granted afterwards from the “Manage access” action on the Connections page in the Elaichi web app, which this catalog does not expose as its own operation. There is no Connect button and no connector picker here, so connector_slug is required — resolve it with connector.list before calling. Handing the link over is your job. The result repeats connect_url on its own line in a second content block. Put that URL in your reply, as a clickable link if you can, and tell the user to open it. Do not wait for them in this turn: end your reply, and call connection.get later to see whether status became "active".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoDisplay name. Defaults to the connector’s label.
sharesNoOptional grants to create the connection with, applied as part of the same create: if any entry names someone who cannot be granted access (a suspended member, a team from another organization, or yourself) the whole call is refused and NO connection is created. Defaults to empty (private to the caller). Each entry additionally requires the connection:share permission on the whole call.
connector_slugNoProvider slug from connector.list, e.g. "slack". Resolve it with connector.list rather than guessing. Whether it may be omitted depends on the surface, see this tool’s description.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only say the operation is not read-only, destructive, or idempotent, so the description carries the behavioral burden. It discloses the pending status, the one-time human-opened session, the inability of Elaichi to finish login, the permission requirement and failure mode for shares, and the fact that the connection only becomes active later.

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

Conciseness3/5

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

The description is information-dense and front-loaded with the core result, but it is lengthy and repeats the 'connector_slug is required / resolve with connector.list' instruction twice, and the 'depends on the surface, see below' clause is never fully resolved. Most sentences earn their place, but the redundancy and one dangling reference make it more verbose than necessary.

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 a high-stakes connection-creation flow with no output schema and minimal annotations, the description covers prerequisites, side effects, permissions, output shape, required follow-up (handoff, later polling), and common failure conditions. Nothing an agent needs to execute the tool 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 schema already defines each parameter. The description adds real meaning beyond it: connector_slug must be resolved from connector.list, shares defaults to private and requires connection:share when present, and name defaults to the connector label. The prose is slightly ambiguous about when connector_slug may be omitted, preventing 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?

The description begins with a specific action ('Start connecting a third-party account') and states the exact result: a pending connection plus { connection, connect_url }. It also clarifies the browser handoff, distinguishing this tool from any provider-login or listing 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 gives explicit preconditions and sequencing: resolve connector_slug with connector.list first, hand the connect_url to the user, do not wait, and poll with connection.get afterwards to detect 'active'. The security guidance (never ask for credentials) and the advice to prefer empty shares over sharing in this call are also actionable when-to/how-to instructions.

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