chat-export-server

Overview Schema Source Related Servers Discussions Admin

containers_list

Read-onlyIdempotent

Lists projects or folders across supported AI platforms through the bound browser, with optional name filtering and pagination.

Instructions

Legacy alias identical to projects_list. Prefer projects_list for new agents; same args and result. Lists projects/folders on a platform via the bound browser.

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": {
      "platform": "<platform>"
    },
    "name": "containers_list"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Max projects to return (1-100)
`query`	No	Optional name filter when the provider supports it
`cursor`	No	Opaque pagination cursor; null/omit for first page
`platform`	Yes	Provider id: chatgpt \| grok \| grok-x \| claude \| copilot \| qwen \| deepseek \| perplexity

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.0.4Nov 11, 2026

addedInput schema / properties / cursor / description

Added value: +"Opaque pagination cursor; null/omit for first page"

addedInput schema / properties / limit / description
```
Added value: +"Max projects to return (1-100)"
```

addedInput schema / properties / platform / description

Added value: +"Provider id: chatgpt | grok | grok-x | claude | copilot | qwen | deepseek | perplexity"

addedInput schema / properties / query / description

Added value: +"Optional name filter when the provider supports it"

First observedv1.0.3Nov 11, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and openWorld, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: results are fetched 'via the bound browser' (a session/auth prerequisite) and behavior is identical to projects_list. It stops short of describing pagination or failure modes, which keeps it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, zero filler, and the most decision-relevant fact (legacy alias; prefer projects_list) is front-loaded before the functional description. Nothing could be removed without losing information.

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 simple read-only list tool with a fully documented four-parameter schema and rich annotations, this covers what an agent needs: purpose, alternative routing, and the browser-binding prerequisite. It only lightly gestures at output ('same result') and omits pagination behavior, but no output schema exists to lean on, so a small gap remains.

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%, with limit, query, cursor, and an enumerated platform all documented in the schema. The description adds no parameter-level meaning beyond 'same args and result,' so the baseline 3 for high-coverage schemas applies.

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 names a specific verb and resource ('Lists projects/folders on a platform') and immediately positions itself relative to its sibling by declaring itself a legacy alias identical to projects_list. An agent can distinguish it from the newer tool and the other *_list siblings without opening any schema.

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?

It gives an explicit routing instruction: 'Prefer projects_list for new agents' while stating this tool has the same args and result, which implies it should only be chosen for legacy/back-compat situations. The alternative and the condition selecting it are both named outright.

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