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.

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.

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.

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.

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.

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.

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

With no annotations provided, the description must carry the full behavioral burden. It does disclose the return shape (a Dict with a channels list containing id, server_id, server_name, name, last_message_id) and implies a read-only list operation. However, it omits auth requirements, rate limits, pagination, and whether results are cached or live, leaving clear gaps for an unannotated tool.

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

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

The description is front-loaded with its purpose, then uses compact Args and Returns sections. Every line serves a purpose: the parameter explanation and return shape are useful given the absent output schema. There is no redundant or filler text.

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

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

There is no output schema, but the description compensates by documenting the return dictionary structure. For a simple one-parameter list tool with no annotations, the description covers purpose, parameter semantics, and return shape. It still lacks operational details like auth, rate limits, or pagination, keeping it from a top score.

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

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

Schema coverage is 0%, so the description must define the only parameter. It does so adequately: 'server: optional server ID or name to restrict to' explains that the parameter is optional, accepts an ID or name, and filters the result. It could add format examples or default behavior, but it compensates well for the missing schema description.

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

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

The description opens with 'List channels known to the archive', giving a specific verb (List) and resource (channels). It also scopes the result with the optional server filter, so an agent can understand the operation without reading the schema. However, it does not explicitly differentiate this tool from sibling tools like servers or search, so it falls short of a 5.

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

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

The description only explains the optional server parameter; it offers no guidance on when to choose channels over siblings such as servers, recent, or search. There are no prerequisites, exclusions, or alternatives mentioned, so an agent receives minimal routing help. This matches the rubric's 'no guidance' level.

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

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

With no annotations, the description carries the full burden and does well: it discloses the sandboxing constraint (paths confined to DMINE_EXPORT_DIR, absolute paths and '..' rejected) and the return shape (dict with path and message_count). It stops short of covering failure modes (missing channel, empty archive) or auth requirements.

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

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

Front-loaded with the core action and format, then structured Args/Returns sections. Every line adds information; the only minor cost is the docstring-style formatting overhead.

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

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

For a 4-parameter tool with no annotations and no output schema, the description covers the operation, path safety rules, all parameters, and the return shape. The main gap is guidance on when this tool is the right choice versus its siblings.

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

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

Schema description coverage is 0%, so the Args section is doing all the work, and it defines each of the four parameters meaningfully: channel accepts an ID or full URL, format enumerates 'jsonl'/'md', since is an exclusive id lower bound, and out is a filename relative to the export dir with a documented default. This meaningfully compensates for the bare schema.

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

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

States a specific verb ('Export') and resource ('a channel from the archive') plus the output formats (jsonl or markdown). It is clearly distinguishable from siblings like status, capture, recent, search, and channels, which are non-file-producing operations.

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

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

The description never says when to choose export over siblings such as recent, search, or capture, nor does it state any exclusions or preconditions for use. The purpose is inferable, but no routing guidance is provided.

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

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

With no annotations, the description carries the full burden and does disclose meaningful traits: where files are stored under DMINE_MEDIA, that some entries are URL-only and may already be expired, and how to re-fetch them. It omits auth/permission requirements and any rate/scope caveats, keeping it just shy of 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.

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

Front-loaded purpose sentence, then storage/expiry context, then a clean Args/Returns block. The structured layout is efficient, though it is slightly verbose for a simple listing tool.

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

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

Documents all arguments and describes the return dict shape (media_dir, count, attachments with per-entry fields), which compensates for the absent output schema. Only missing element is any note on permissions or error behavior, but the definition is otherwise complete for a read-only listing tool.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: channel is a 'channel ID or full URL', limit is 'max messages to scan (default 200)', and message_since restricts to 'messages with id > this message ID'. All three params gain clear meaning beyond the bare schema.

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

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

States a specific verb (list) and two distinct resource types (attachments AND embed images) scoped to a channel. This distinguishes it from siblings like remedia, which it explicitly references for downloading, so an agent can route confidently.

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

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

Clearly points to remedia() as the alternative for (re-)downloading while links are valid, and notes that entries without local_path only hold an expirable CDN URL. That gives strong contextual guidance, though it stops short of explicit when-not-to-use conditions.

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

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

With no annotations, the description carries the full burden. It implies read-only ('Read', 'archived') and adds useful context that it needs no browser, but it does not disclose auth/permission requirements or rate limits, and errors are unaddressed.

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

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

Purpose is front-loaded, then clean Args/Returns sections. Nearly every line earns its place, though the Returns block partially restates what the field names already imply.

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

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

No output schema exists, but the description documents the returned dict shape and all four parameters well. For a simple read tool this is largely complete, missing only auth/error behavior and pagination nuance beyond limit.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it defines channel as ID or full URL, explains 'since' semantics with a concrete example, states limit is a max, and explains include_embeds carries tweet payloads. This adds real meaning beyond the bare schema titles.

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

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

The description gives a specific verb and resource: 'Read the most recent archived messages of a channel'. The parenthetical '(no browser needed)' meaningfully scopes it against browser-dependent siblings like capture. It does not explicitly name a sibling it differs from (e.g. search), so it stops short of 5.

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

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

Usage is implied rather than stated. The 'since' arg notes it takes 'the watermark from status() before a capture, to see what's new', which hints at a workflow, but there is no explicit when-to-use-this-vs-search-or-capture guidance or exclusion conditions.

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

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

With no annotations, the description carries the full behavioral burden and does a good job: idempotency ('skips existing files'), retry semantics for failed downloads, and the async continuation contract after `wait` seconds, including re-invocation to collect the final result. It omits auth/permission requirements and any rate-limit or failure-mode detail.

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

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

Front-loads the core purpose, then the async contract, then Args/Returns. The Args section duplicates schema fields, but that duplication is warranted given the 0% schema description coverage. No wasted filler.

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

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

No output schema exists, so the description supplies the return dict keys ('channel_id', 'messages_with_media', 'media_entries') and explains the running-status case. Complete for correct invocation, though permissions and progress/pagination behavior for very large channels are unaddressed.

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

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

Schema description coverage is 0%, so the description must define all three parameters, and it does: channel accepts an ID or full URL, limit takes the N most recent messages (None = all), and wait is the synchronous seconds before a running summary is returned. This meaningfully exceeds the bare schema types.

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

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

States a specific verb and resource ('Re-download media (attachments + embed images)') scoped to 'ALREADY archived messages', which implicitly distinguishes it from a first-time capture. The contrast with capture() is reinforced by the background-execution comparison.

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

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

Clear usage context: run it over already-archived messages, and it doubles as a retry path for entries whose prior download failed. It does not explicitly frame when NOT to use it (e.g. 'use capture() for new messages'), so the alternative selection is left partly to inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses that % and _ match literally (no wildcard semantics), that server matching is case-insensitive with unique-substring tolerance, that hit count is capped by limit (default 50), and what each hit contains. It does not explicitly label the operation read-only or describe truncation/ordering behavior when hits exceed limit.

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

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

Front-loads the core behavior and scoping rule in two sentences before the Args/Returns blocks, which are well structured. The Returns section partially duplicates what the parameter list already implies, but nothing is wasted enough to be a problem.

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

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

With no output schema and no annotations, the description is complete enough for a correct call: it documents all arguments, the scoping model, and the return dictionary shape. The remaining gap is behavioral detail around result truncation and ordering when limit is hit, which an agent would need for large archives.

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

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

Schema coverage is 0%, so the description must compensate, and it does: query is a substring match with literal % and _, server accepts ID or case-insensitive name/unique substring, channel accepts an ID or URL and applies within the server scope, and limit documents its default of 50. Every parameter gains meaning beyond the bare schema types.

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

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

States a specific verb ('substring search') and resource ('the archive'), and enumerates what is searched: message content, embeds, author. It is clear this is the discovery tool, distinct from listing-style siblings like recent or media, though it never names an alternative outright.

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

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

Explicitly explains that without scope the search spans every archived server, and directs the agent to server= or channel= to restrict, including how channel interacts with server scope. It stops short of stating when NOT to use it (e.g., versus recent) or any rate/result-ceiling guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'List' implies a read-only operation and the parenthetical enumerates returned fields, but nothing is said about pagination, result size, ordering, auth requirements, or how 'known to the archive' is determined.

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

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

A single tight sentence with the action front-loaded and the returned data folded into a parenthetical. No filler or redundancy.

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

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

For a zero-parameter, no-output-schema listing tool, naming the returned fields (id, name, channels, messages) covers most of what an agent needs. The remaining gap is the lack of any indication of result set size or pagination behavior.

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

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

The schema declares zero parameters, so there are no parameter semantics to document; per the rubric this yields a baseline of 4. The description correctly implies the tool is callable with no arguments.

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

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

The description states a specific verb and resource ('List Discord servers') and scopes it to 'known to the archive', which is clearer than a tautology. It does not explicitly distinguish itself from siblings such as 'channels' or 'search', both of which could plausibly return server-adjacent data.

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

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 tool versus alternatives like 'channels', 'search', or 'export'. An agent must infer from the name and sibling names alone that this is the top-level enumeration entry point.

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

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

With no annotations, the description carries the full burden. It does usefully disclose the return structure and that active_captures reflects background jobs holding the capture lock, which is real behavioral context. However, it never states that this is a non-mutating read, nor any auth or cost characteristics, so it only partially covers the no-annotation gap.

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

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

Front-loaded purpose followed by compact Args/Returns blocks; every line is informative. The pseudo-header formatting is slightly heavier than needed for such a small surface, but nothing is wasted.

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

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

No output schema exists, and the description compensates by enumerating the returned dict fields (totals, per-channel rows with id/name/msgs/watermark, active_captures). For a single-parameter read tool this is close to complete, lacking only an explicit read-only assurance.

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

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

Schema coverage is 0% for the single parameter, so the description must compensate, and it does: 'channel: optional channel ID/URL to show only that channel' explains both optionality and acceptable forms. That is meaningful beyond the schema's bare anyOf string/null.

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

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

The description opens with a specific resource and scope: 'Archive status: total messages, per-channel watermark and counts.' That is a concrete verb+resource and clearly distinct from siblings like export, capture, recent, or search. It stops short of naming an alternative, so it is clear but not sibling-differentiating.

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

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

There is no statement of when to call this versus siblings such as channels, servers, or recent. The channel argument implies a narrowing use case, but the agent is left to infer that this is the read-only inspection tool for archive progress.

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