AI Team OS

Overview Schema Source Related Servers Discussions Admin

agent_list

List a team's live members and current tasks, with offline agents summarized and full history available on request. Supports pagination and compact or full fields.

Instructions

List a team's members - live roster first, offline history on request.

Default response is a COMPACT projection (view="compact" + hint - it is a trimmed view, NOT missing fields). Each member row keeps id / name / role / status / an 80-char current_task excerpt / last_active_at; system_prompt, config, the context watermark and the token ledger are omitted and come back with fields="all".

Offline members are folded into a count plus a short most-recent digest. An offline agent is a terminated process - it cannot be messaged and cannot be assigned work - and on a long-lived team offline rows are most of the payload. Nothing is deleted: the count is always reported and include_offline=True returns the full history.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	Max member rows to return after the offline split (default 50, capped at 200)
`fields`	No	"compact" (default, trimmed rows) / "all" (full agent rows)	compact
`offset`	No	Pagination offset into the member rows (default 0)
`team_id`	Yes	Team ID or name
`include_offline`	No	Include offline members as full rows instead of a count plus digest (default False)
`offline_preview`	No	How many most-recent offline members to show in the digest (default 5; ignored when include_offline is True)

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv1.11.2Aug 3, 2026

addedInput schema / properties / fields

Added value: +{
+  "default": "compact",
+  "description": "\"compact\" (default, trimmed rows) / \"all\" (full agent rows)",
+  "type": "string"
+}

addedInput schema / properties / include_offline

Added value: +{
+  "default": false,
+  "description": "Include offline members as full rows instead of a\ncount plus digest (default False)",
+  "type": "boolean"
+}

addedInput schema / properties / limit

Added value: +{
+  "default": 50,
+  "description": "Max member rows to return after the offline split (default 50,\ncapped at 200)",
+  "type": "integer"
+}

addedInput schema / properties / offline_preview

Added value: +{
+  "default": 5,
+  "description": "How many most-recent offline members to show in the\ndigest (default 5; ignored when include_offline is True)",
+  "type": "integer"
+}

addedInput schema / properties / offset

Added value: +{
+  "default": 0,
+  "description": "Pagination offset into the member rows (default 0)",
+  "type": "integer"
+}

First observedv1.9.0Jul 14, 2026

TDQS

A3.9/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full burden and does so: it discloses the projection contract (which fields are kept vs omitted), the retention guarantee ('Nothing is deleted: the count is always reported'), and the operational meaning of offline (terminated process, cannot be messaged or assigned work). This is exactly the kind of context an agent needs to interpret a truncated payload without assuming data loss.

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-loads the core purpose, then layers projection and offline semantics in short paragraphs. Slightly dense with parenthetical asides, but every sentence carries behavioral information rather than filler.

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?

For a six-parameter, output-schema-backed list tool with an unusual split-response design, the description supplies the projection, pagination-adjacent, and offline-handling context needed to call it correctly. An output schema exists so return shape needn't be restated, and the description wisely focuses on semantics instead.

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 description coverage is 100%, so the schema already documents all six parameters, setting the baseline at 3. The description reinforces intent (compact is a trimmed view, 'NOT missing fields') and explains that offline rows fold into a count plus digest, but adds little parameter syntax or format detail beyond the schema.

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 and resource ('Lift a team's members') with a scope qualifier ('live roster first, offline history on request'). It is clearly distinguishable from 'team_list' (which lists teams) and 'agent_update_status' (which mutates), though it never names a sibling to route the agent explicitly.

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?

Gives strong guidance on which parameters to use (default compact vs fields="all", include_offline for full history) but no guidance on when to choose this tool over alternatives like team_status, agent_activity_query, or team_list. Usage is implied by the payload semantics rather than stated as a selection rule.

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

Deploy Server