Skip to main content
Glama

capture

Archive a Discord channel into SQLite, incrementally fetching new messages or backfilling full history. Runs as a background job with optional wait and media download controls.

Instructions

Archive a Discord channel into the SQLite archive.

Incremental by default: only messages newer than the stored watermark (MAX message id per channel) are fetched. Use full=True for a one-time backfill. Requires the persistent Chrome daemon (auto-starts; the user must have logged into Discord in its profile at least once).

Long jobs run in the background: the call waits up to wait seconds (default 45) and returns the full result if the capture finished in time. If it is still running, it returns {"status": "running", ...} immediately and the capture continues — call capture() again for the same channel to fetch the final result, or watch progress via status()/recent(). Never fire captures for several channels in parallel: they queue on the global capture lock and serialize automatically (capture() reports waiting_for_lock while queued).

Args: channel: channel ID or full discord.com/channels/... URL. full: backfill the entire history instead of incrementing. since: explicit watermark message ID (overrides the stored one). limit: hard cap on messages (test runs). no_media: skip attachment + embed-image downloads (CDN links expire!). refresh: re-extract ALL visible messages, retrofitting embed images onto rows captured before image extraction existed (combine with full=True for the whole channel). wait: seconds to wait synchronously for completion before returning a "running" summary (keep below your client's request timeout (many clients cap it at ~60 s). Returns: Dict with new_messages, seen, stop_reason, total_in_db — or a {"status": "running", "job": {...}} summary for long backfills.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fullNo
waitNo
limitNo
sinceNo
channelYes
refreshNo
no_mediaNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so richly: it discloses the watermark-based incremental semantics, the persistent Chrome daemon dependency and login prerequisite, the background-job/lock-serialization model (waiting_for_lock, queued captures), the synchronous wait timeout caveat, and the running-status return shape. These are exactly the operational traits an agent cannot infer from the schema.

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?

Purpose is front-loaded in the first sentence, followed by mode semantics, prerequisites, concurrency behavior, and a structured Args/Returns block. Despite its length, every sentence adds decision-relevant information with no filler.

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

Completeness5/5

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

For a complex, long-running, stateful tool with no output schema and zero schema coverage, the description covers purpose, modes, prerequisites, concurrency, timeouts, parameter meanings, and return values. Nothing needed to invoke it correctly is missing.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate for all 7 parameters, and it does: channel accepts an ID or full URL, full backfills history, since overrides the stored watermark, limit is a test-run cap, no_media skips downloads with an expiry warning, refresh retrofits embed images onto old rows, and wait carries a client-timeout caveat. Each parameter gains meaning well beyond its bare type/default.

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?

States a specific verb and resource ('Archive a Discord channel into the SQLite archive') and immediately establishes scope (incremental by default vs. full backfill). This is clearly distinguishable from siblings like export, status, recent, and search, which handle different facets of the same archive.

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?

Explicitly says when to use full=True (one-time backfill) vs. the default incremental mode, names status()/recent() as alternatives for progress-watching, tells the agent to re-call capture() to fetch a finished job, and warns against parallel captures across channels. Both when-to-use and when-not-to-use are covered.

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