Skip to main content
Glama
Sign In

neonloops

by com.neonloops
OverviewDiscussionsAdmin

Connectors: begin

connectors_begin
Destructive

Starts connecting an app (Gmail, Slack, Google Sheets and more) to this neonloops workspace so a workflow can start when something happens in it, or act in it. It returns a URL that a person must open and finish in a browser: the call never completes a connection. For an OAuth app it is the provider's consent page, and the connection stays pending until they approve. For an API-key app nothing is created: the URL opens neonloops, where the person pastes the key themselves, so the key never passes through this tool. Find the app's slug and its actions with connectors_search; an unknown toolkit, or an enabled_tools slug that search did not return, is refused.

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": {
      "toolkit": "<toolkit>"
    },
    "name": "connectors_begin"
  }
}

Input Schema

NameRequiredDescriptionDefault
labelNoA name for the connection, up to 60 characters; defaults to the app's slug, capitalised. An API-key app ignores it: the person names the connection in the key step.
toolkitYesThe app's slug as connectors_search lists it, e.g. gmail.
enabled_toolsNoApp action slugs to enable, as connectors_search with that toolkit lists them. Omit or leave empty to enable all of them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / enabled_tools / description
      Previous value: -"Real tool slugs from connectors_catalog_toolkit_tools. Omit or empty for all tools."New value: +"App action slugs to enable, as connectors_search with that toolkit lists them. Omit or leave empty to enable all of them."
    • addedInput schema / properties / label / description
      Added value: +"A name for the connection, up to 60 characters; defaults to the app's slug, capitalised. An API-key app ignores it: the person names the connection in the key step."
    • changedInput schema / properties / toolkit / description
      Previous value: -"A real toolkit slug; connectors_catalog_list finds it."New value: +"The app's slug as connectors_search lists it, e.g. gmail."
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Adds substantial behaviour beyond the annotations: the return value is a URL a person must open, OAuth connections stay pending until approval, and API-key apps create nothing here because the key never passes through the tool. This explains the destructiveHint/openWorldHint profile in operational terms an agent needs before calling.

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 its key limitation, then split cleanly into OAuth versus API-key behaviour and the discovery prerequisite. It is dense with no filler, though the four-sentence block is near the upper bound of what is needed.

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?

No output schema exists, so the description correctly carries the return contract by explaining the URL and the pending/API-key distinction. Combined with the discovery prerequisite and refusal conditions, nothing an agent needs to invoke this safely is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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 all three parameters, making 3 the baseline. The description adds a little meaning, notably that enabled_tools slugs not returned by search are refused and that label defaults to the capitalised slug, but most parameter meaning still comes from the schema.

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 and resource: 'Starts connecting an app (Gmail, Slack, Google Sheets and more) to this neonloops workspace', and immediately bounds the scope with 'the call never completes a connection'. It clearly delineates itself from connectors_search, which is named as the lookup step rather than the connect step.

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?

Gives an explicit prerequisite flow: find the app's slug and actions with connectors_search before calling, and notes that an unknown toolkit or an unreturned enabled_tools slug will be refused. It lacks an explicit 'do not use this to complete a connection' alternative pointer, but the handoff to the browser step is clear.

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

All neonloops toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources