Skip to main content
Glama

agents_list

Read-only

Read AI teammates/operators, readiness and schedules. Hosted runs cost AWT.

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": {
      "workspace": "<workspace>"
    },
    "name": "agents_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNo
agentNo
limitNo
queryNo
cursorNo
statusNo
run_modeNo
workspaceYes
include_configNo
include_schedulesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.4/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only a cost note about hosted runs (a sibling operation) and vague hints at "readiness and schedules"; it says nothing about pagination behavior, default page size, or what readiness means.

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?

Two short sentences, front-loaded with the core action and no padding. The terseness is efficient, though it comes at the cost of the missing detail noted elsewhere.

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

Completeness2/5

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

A 10-parameter, paginated list tool with three enums, no output schema, and zero schema descriptions needs far more than two sentences. Filter semantics, pagination via cursor/limit, and the include_config/include_schedules flags are all left for the agent to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 10 parameters, so the description carries the full burden and largely fails it. "Teammates/operators" loosely maps to the kind enum and "schedules" hints at include_schedules, but agent, query, cursor, limit, run_mode, workspace, and include_config get no explanation anywhere.

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

Purpose3/5

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

"Read AI teammates/operators" gives a verb and a resource, which is more than a tautology, but appending "readiness and schedules" makes the actual payload ambiguous — does it list agents, return their status, or return schedule objects? It also does not distinguish itself from near neighbors like agents_templates_list, agent_runs_list, or members_list.

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?

There is no guidance on when to call this versus agents_save, agents_templates_list, or agent_runs_list. The only usage-flavored sentence, "Hosted runs cost AWT," concerns running agents rather than listing them, so it does not help select this tool.

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