Skip to main content
Glama

export_all_conversations

Read-onlyIdempotent

Export conversations for an agent (Postgres mirror). Requires a paid workspace (hasEverPaid === true); billed against monthly export quota. Supports cursor pagination via cursor/nextCursor/hasMore, or selected mode via convoIds. Formats: json|csv.

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": {
      "agentId": "<agentId>"
    },
    "name": "export_all_conversations"
  }
}

Input Schema

NameRequiredDescriptionDefault
sortNoSort order (API-defined)
toTsNoUnix timestamp upper bound (inclusive)
limitNoMax conversations in this export page
cursorNoOpaque cursor from previous export nextCursor
formatNoExport format (default: json)
fromTsNoUnix timestamp lower bound (inclusive)
agentIdYesThe agent ID
convoIdsNoIf set, export only these conversation IDs

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), but the description adds material context the annotations cannot convey: the paid-workspace prerequisite and quota billing, plus the two pagination/selection modes. It doesn't mention limits like max page size or whether exports are synchronous, which would be valuable given quota billing.

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 compact sentences, front-loaded with purpose, then prerequisite/cost, then modes and formats. Every clause carries decision-relevant information with no 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?

With 8 params, no output schema, and an export that can be large and quota-billed, the description covers prerequisites, cost, modes, and partial return shape. Missing are practical limits (page size caps, sync vs. async behavior) that would matter before launching a bulk export.

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 the baseline is 3; the description adds value by naming nextCursor/hasMore, which are not in the input schema and no output schema exists. It otherwise mostly restates convoIds and format, which the schema already documents.

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 with scope ('Export conversations for an agent') plus the storage source ('Postgres mirror'). It does not distinguish itself from near-siblings like export_conversation (singular) or list_conversations, so an agent must infer the difference.

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

Usage Guidelines4/5

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

Gives clear context: requires a paid workspace and is billed against monthly export quota, and it explains two operating modes (cursor paging vs. selected convoIds). It stops short of explicit exclusions, e.g. when to prefer export_conversation or list_conversations instead.

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