Skip to main content
Glama

List agency clients

list_agency_clients
Read-only

The client accounts the caller works as an agency, their own and their teammates', with each client's credit balance and Slack reply alerts and each person's LinkedIn sending state. Pass any member's email but your own as on_behalf_of on a Sliq tool to run that call in their account.

Returns {'groups': [{'key', 'name', 'operator_email', 'members': [{'email', 'display_name', 'linkedin'}], 'credits': {'available', 'level' (0 ok, 1 low, 2 almost out)} | None, 'reply_alerts'}, ...]}. The first group (key 'team') is the caller's own team, with operator_email and reply_alerts None. On every other group operator_email is the client's main operator, and reply_alerts is which of the members' LinkedIn replies post to the agency's Slack channel: 'all', 'interested' (a reply classified interested or meeting booked, or any reply from a prospect already at meeting booked), or 'off'. A member's linkedin is None when they have no LinkedIn account connected, else {'linkedin_reason' ('needs_reconnect' | 'auto' paused by LinkedIn limits until linkedin_until | 'manual' paused by the user | None sending), 'linkedin_until', 'connection_request_until' (connection requests alone held until then, or None)}. A caller who works no clients gets only the 'team' group, or {'groups': []} with no teammates either.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_agency_clients"
  }
}

Input Schema

NameRequiredDescriptionDefault
on_behalf_ofNoA teammate's email, or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / on_behalf_of / description
      Previous value: -"An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."New value: +"A teammate's email, or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
  2. Changed1 schema field changed
    • addedInput schema / properties / on_behalf_of
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
      +}
  3. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true, so the safety profile is covered; the description then adds genuine behavioral context beyond that — the ordering guarantee that the first group is always key 'team', that operator_email and reply_alerts are None on it, and the exact degradation cases (only a 'team' group with no clients, {'groups': []} with no teammates either). What it omits is any hint about size/volume or permission requirements for seeing teammate accounts.

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?

Because there is no output schema, the return-shape prose earns its place, but it is delivered as a dense run-on dict literal with inline parenthetical enums, which is hard to parse and buries the important 'first group is team' fact mid-paragraph. The opening fragment is not front-loaded with a clear action statement.

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

Completeness4/5

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

With no output schema, the description carries the full burden of explaining the return value, and it does so thoroughly, including the nested linkedin state machine (needs_reconnect / auto with linkedin_until / manual) and reply_alerts modes. It is complete enough to call correctly and interpret the result, with only volume/pagination expectations left unstated.

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 baseline is 3, but the description adds real meaning: it clarifies that the eligible emails are 'any member's email but your own' drawn from this tool's output, tying the parameter to a concrete source. The exclusion of the caller's own email is a nuance the schema does not spell out as sharply.

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?

The description identifies a specific resource — the agency client accounts the caller manages, plus their own team group — and distinguishes the 'team' group from client groups, which separates it from siblings like list_teammates. It never states the verb explicitly (the opening is a noun phrase: 'The client accounts the caller works as an agency'), so the agent must infer 'list' from the tool name, but the scope is unambiguous.

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

Usage Guidelines3/5

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

Usage is only implied: the sentence about passing a member's email as `on_behalf_of` signals that this tool is the lookup you use to obtain valid account identifiers before acting on behalf of someone. There is no explicit when-to-use/when-not statement and no naming of alternatives such as list_teammates or get_credit_usage, so the agent must infer the 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