Skip to main content
Glama

Connect a social account

social_connect

Connect one of the business's own accounts as a channel. For a link network (LinkedIn, Mastodon, Discord, Slack, Facebook, Instagram...) you get connect_url: hand it to the owner, who approves Conecto on the network and sees "Channel connected"; social.channel_connected tells you, and social_channels lists it (the link works for an hour; a key that only reads or drafts gets it as "[redacted]"). For a login network pass the login: Bluesky (username and an app password), WordPress (service, username, application password), Medium, Dev.to and Hashnode (api_key), Lemmy (username, password), Nostr (password: the private key); it connects at once and the login is never kept by Conecto. Without the password or api_key it answers with a link instead, where the owner types it on a Conecto page, so it never passes through the chat (from_a_terminal does the same from a terminal). service is a public https:// address. Telegram: call without code to get one; the owner adds Conecto's bot to the channel as an admin and posts "/connect " there; then call with code. Only channels (groups can't be), and a channel connected to another Conecto account stays theirs. Or with the business's own bot: Telegram with bot_token (from @BotFather) and chat (@channel or the chat's number), the bot an admin of the channel or a member of the group, and posts come from their bot; Discord or Slack with webhook_url (a channel webhook), and posts carry its name and picture. Without bot_token (Telegram, with chat) or webhook_url (Discord or Slack, with own_bot), the answer is a link for the owner to type it. Those are checked with the network at once, kept encrypted, and their channel_ids start with own_; account.credential_added says when a link's channel connected. Connecting again refreshes a channel that needs it. Free. Free.

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": {
      "network": "<network>"
    },
    "name": "social_connect"
  }
}

Input Schema

NameRequiredDescriptionDefault
chatNoTelegram, with bot_token: the channel (@name) or the chat's number.
codeNoTelegram: the code social_connect gave, once the owner posted it.
api_keyNo
networkYes
own_botNoDiscord or Slack: through a channel webhook of the business's own, whose address the owner types on the link this answers with.
serviceNoThe server or site address, for networks that have one.
passwordNo
usernameNo
bot_tokenNoTelegram: the business's own bot's token, from @BotFather.
webhook_urlNoDiscord or Slack: a channel's webhook address.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / own_bot
      Added value: +{
      +  "description": "Discord or Slack: through a channel webhook of the business's own, whose address the owner types on the link this answers with.",
      +  "type": "boolean"
      +}
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations give the safety profile (readOnly=false, destructive=false, openWorld=false), yet the description layers on genuinely non-obvious behavior: connect links expire after an hour, read-only keys receive '[redacted]' URLs, logins are never retained by Conecto and own-bot credentials are stored encrypted with own_ channel_ids, channels owned by another Conecto account stay theirs, and connecting again refreshes a channel. It also discloses the async confirmation path (social.channel_connected / account.credential_added) and that the operation is free.

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?

Nearly every clause carries real information, but it is delivered as an undifferentiated run-on paragraph mixing four distinct setup flows, and the duplicated 'Free. Free.' is a defect. Front-loading the primary distinction (link network vs login network vs bot) would make it far more navigable without cutting content.

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 10-parameter, multi-mode tool with no output schema, the description covers what you get back (connect_url, a typed-in link, or an immediate connection), the out-of-band confirmation events, credential handling, and ownership constraints. An agent can pick the right mode and know what to expect from the response without any additional tooling.

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?

With 60% schema coverage, the description compensates well: it maps network-to-credential pairs (Bluesky app password, WordPress application password, Medium/Dev.to/Hashnode api_key, Lemmy username+password, Nostr private key), explains that service is a public https:// address, and clarifies chat/bot_token/webhook_url/own_bot interplay. The one gap is that username and password are only bound to specific networks implicitly, leaving some combinations to inference.

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 gives a specific verb and resource: connect one of the business's own accounts as a channel, and the branches that follow (link network, login network, Telegram code, own bot) make the scope concrete. It is clearly distinguishable from social_disconnect and social_channels in the sibling list, since this is the only tool that establishes a channel.

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 gives explicit selection logic per network: link networks return a connect_url, login networks take username/password or api_key, Telegram takes a code round-trip, and bot/webhook paths need bot_token or webhook_url. It even names the fallback ('from_a_terminal does the same from a terminal') and when a link is returned instead. It stops short of pointing at siblings such as social_channel_lookup or social_disconnect for follow-up steps, so it is strong but not fully self-routing.

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