Skip to main content
Glama

List Social Connections

aidelly_list_social_connections
Read-onlyIdempotent

List available social connections for publishing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNoOptional query overrides for endpoints with sparse parameter schemas.
brand_idNo
workspace_idNoWorkspace to operate in: the `id` of a workspace returned by aidelly_list_workspaces. Optional for read operations; required when creating content.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / workspace_id / description
      Previous value: -"Workspace to operate in. Do not ask the user for this UUID — call aidelly_list_workspaces and use the `id` of the matching workspace. Optional for read operations; required when creating content."New value: +"Workspace to operate in: the `id` of a workspace returned by aidelly_list_workspaces. Optional for read operations; required when creating content."
  2. Changed1 schema field changed
    • addedInput schema / properties / workspace_id / description
      Added value: +"Workspace to operate in. Do not ask the user for this UUID — call aidelly_list_workspaces and use the `id` of the matching workspace. Optional for read operations; required when creating content."
  3. First observed

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only the 'for publishing' purpose framing and discloses nothing extra about return contents, pagination, or auth needs; with annotations carrying the load, this is an adequate but thin contribution.

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?

A single front-loaded sentence with zero waste. It is efficiently sized, though its extreme brevity borders on under-specification for a tool whose purpose overlaps several siblings.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only listing tool with annotations covering the safety profile and no output schema, the definition is minimally sufficient to invoke. It nonetheless omits what a connection represents versus an account, what the nested query override does, and why brand_id is needed.

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 67%: workspace_id and the nested query object are documented in the schema, while brand_id carries no description anywhere. The description adds no parameter meaning at all, so it fails to compensate for the brand_id gap, but the moderate coverage keeps this at the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (List) and resource (social connections) with a scope qualifier (for publishing). However, it does not distinguish itself from nearby siblings like aidelly_list_accounts or aidelly_list_connect_link_connections, so an agent could plausibly confuse the resources without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'for publishing' hints at context but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g., list_accounts, list_connect_link_connections). The agent is left to infer the selection criteria entirely.

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.