Skip to main content
Glama

SnapWidget

Connect Account

connect_account

Adds a social account to the user's SnapWidget account, for widgets to show its posts. A YouTube channel: send its link and it is added at once. Instagram, Facebook, TikTok or X: the answer is an approval link. Give it to the user: they, or the owner of the account, open it, sign in with the platform and click Allow (the platforms require this; no SnapWidget sign-in is needed). The link works once, for 24 hours; list_accounts then shows the account. To renew an expired account, use reconnect_account.

Input Schema

NameRequiredDescriptionDefault
serviceYesThe platform of the account.
channel_urlNoYouTube only: the channel's link, for example https://www.youtube.com/@channel.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare a non-read-only, non-destructive, open-world write, but the description adds what actually matters: the non-YouTube path returns an approval link rather than completing, the link is single-use and valid 24 hours, no SnapWidget sign-in is required, and list_accounts confirms success.

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 action, then the platform branching, then the link constraints, then the renewal pointer. The parenthetical "(the platforms require this; no SnapWidget sign-in is needed)" and stacked clauses make it dense but every sentence carries operational information.

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 must explain what comes back - and it does, distinguishing an immediately added YouTube account from an approval-link response. It also covers expiry, single-use, and how to verify or renew, leaving no operational gap.

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 enum and channel_url are already documented. The description nonetheless adds meaning the schema does not: channel_url is required in practice for YouTube ("send its link and it is added at once"), while the other services take no URL and instead produce an approval link.

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 ("Adds a social account to the user's SnapWidget account") plus the downstream effect on widgets. It is clearly separable from reconnect_account and list_accounts, which it names explicitly.

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?

Gives explicit when-to-use: connect a new account; and when-not: use reconnect_account for an expired account. It also branches usage by platform (YouTube vs Instagram/Facebook/TikTok/X), removing any inference about which path applies.

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.