Skip to main content
Glama
Beever-AI

Beever Atlas

Official

list_connections

Retrieve all your platform connections (Slack, Discord, file imports) with metadata including status, platform, and last sync time. Use this before listing channels.

Instructions

List the platform connections (Slack workspaces, Discord servers, file imports, etc.) this principal owns, with each connection's metadata.

Use this when you need a connection's platform, status, or sync metadata — not just its id. If you only need the connection ids, whoami is cheaper. After picking a connection here, call list_channels(connection_id) to see its actual channels. Results are ownership-filtered: you only see your own.

Latency: instant (read-only; no sync triggered).

Returns {"connections": [<entry>, ...]} (empty list if none). Each entry:

  • connection_id (str): e.g. "conn_abc123" — pass to list_channels.

  • platform (str): e.g. "slack", "discord", "file".

  • display_name (str): human label, e.g. "Acme Workspace".

  • status (str): connection health, e.g. "connected".

  • last_synced_at (str|null): ISO timestamp of the most recent sync of a PICKED channel; null when the pick-list is empty (see caveat below).

  • selected_channel_count (int): size of the sync pick-list (see caveat).

  • source (str): how the connection was created, e.g. "oauth".

Caveats (do NOT misread): selected_channel_count is the user's opted-in sync pick-list, NOT how many channels exist. A value of 0 does not mean the connection is empty — a Slack workspace with 0 picks can still have dozens of bot-readable channels. last_synced_at is scoped to the same pick-list, so an empty pick-list yields null even if channels were synced another way. For ground-truth channel availability, always call list_channels(connection_id) — never infer it from these counts.

Error modes: returns {"error": "authentication_missing"} when no valid principal is attached. Never raises access-denied (output is self-scoped).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations, the description fully discloses behavior: ownership-filtered results, read-only instant latency, error modes (authentication_missing), and important caveats about selected_channel_count and last_synced_at to prevent misinterpretation.

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?

Well-structured with clear sections: purpose, usage, output fields, caveats, errors. All sentences add value, though could be slightly more compact.

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?

Thorough coverage: return format, field descriptions, caveats, error handling, and usage flow. No gaps given the tool simplicity (no params, explicit output schema described).

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?

No parameters exist, so the description adds no parameter info. Baseline 4 as per calibration for 0-param tools.

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 clearly states it lists platform connections owned by the principal, with specific verb ('list') and resource ('connections'). It distinguishes itself from sibling tools like 'whoami' and 'list_channels' by specifying when to use each.

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?

Explicitly states when to use (need metadata beyond id) and when not (use whoami for just ids). Provides next step after picking a connection (call list_channels). Gives clear usage context.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Beever-AI/beever-atlas'

If you have feedback or need assistance with the MCP directory API, please join our Discord server