driftnet

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

Goes well beyond the annotations (which only declare non-read-only, non-destructive, non-idempotent): it discloses that existing items are NOT re-sorted, states exact failure conditions (missing parent, empty name), and documents the return value (new folder id and parent). This is the kind of side-effect and error detail an agent needs.

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?

Four short sentences, each carrying distinct information (purpose, classifier guidance, non-re-sorting, return/failure behavior), with the core purpose front-loaded and 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?

Despite having no output schema, the description documents the return value and failure modes, and covers the non-obvious classifier semantics of the description field. Nothing an agent needs to invoke this 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 100%, so 3 is the baseline, but the description adds real meaning for the 'description' parameter by explaining it is read by a classifier and giving a concrete example rule ('MapleStory and Artale helper tools'). It also implies the parent/name constraints through the failure conditions.

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 ('Add a folder to the reader's tree') plus the immediate consequence ('new links will be sorted into it from then on'), which distinguishes it from sibling list/move tools. An agent can identify this as the folder-creation tool without opening the schema.

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 bounds scope by saying renaming and deleting are done by the reader on the web page, so the agent knows not to look for those here, and it points to driftnet_folders for parent ids. It does not explicitly contrast with driftnet_move, but the folder-creation context is clear.

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?

Annotations only flag this as a non-read-only, non-idempotent, open-world write. The description adds far more: server-side validation, prompt-injection rejection, silent dropping of primary_url when the address doesn't exist, GitHub lookup of mentioned open-source tools that creates new catalogue items, and the fact that a rejection leaves the item still leased so the call can be retried.

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 its side effect, then the validation/rejection behavior. It is dense with several clauses per sentence, but nearly every clause carries actionable information for an agent; a small amount of tightening is possible.

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, so the description carries the return contract — it explains the error-with-reason response on rejection and the side effect of creating new items from mentions. For a write tool with 10 parameters, nothing an agent needs in order to call 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 100%, so the baseline is 3, but the description adds real semantics beyond the schema: category is ignored when the reader already filed the item in a folder, primary_url is verified and dropped if nonexistent, and mentions with open_source=true trigger GitHub lookup and separate catalogue entries.

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 ('Store the summary you wrote for an item you leased with driftnet_pending') and adds the key effect ('ends your lease and takes the item off the queue'). Names the sibling tool it pairs with, so it is clearly distinguishable from driftnet_save and driftnet_pending.

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 to use it on an item leased via driftnet_pending, and states the exclusion: 'Only items that are still pending can be enriched: a second call for an item that already has a summary is refused.' The retry path after a rejection is also spelled out.

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?

Goes well past the annotations by disclosing downstream consequences: down-votes lower the publisher's reputation, future links from that publisher are stored without spending a model call, and heavily down-voted items drop out of search. It also documents the failure mode ('fails if no item has that id') and the replace-on-revote behavior, which is consistent with idempotentHint=true.

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?

Four compact sentences, front-loaded with the action and direction semantics, followed by the vote-count rule, the consequences, and the failure case in descending priority. No sentence is redundant with the name or title.

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?

A 3-parameter mutation tool with no output schema, fully covered by annotations and a schema that already documents every field — the description supplies exactly the missing layer: side effects, idempotency behavior, and the error condition. Nothing an agent needs before invoking it is absent.

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 100%, including an explicit enum of up/down and a documented reason field, so the schema carries the parameter burden and baseline is 3. The description reinforces the vote semantics and adds the replacement behavior, but says nothing about the optional reason parameter or its 300-char guidance.

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 (vote) and resource (item) and immediately qualifies the two directions with their meaning (up = useful/accurate, down = spam/outdated/wrong/polluted). No sibling tool performs voting, so the action is unambiguously distinct from driftnet_search, driftnet_get, driftnet_save, etc.

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 up/down criteria effectively define when each option applies, and 'one vote per agent per item: voting again replaces your earlier vote' tells the agent this is a re-callable, revisable action rather than a one-shot. It stops short of explicitly naming a workflow ('use after driftnet_get/search') or stating exclusions, so it sits clearly above minimum but not at the full 5.

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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive/non-open-world, so the safety profile is covered; the description reinforces it with 'Read-only.' Beyond that it discloses non-obvious data semantics — parent id null at top level, path includes the reader's own description text, and the count is of items held *directly* (not recursive). No pagination, scale, or ordering information is given.

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?

Three tight sentences: what it returns first, then the shape of each folder, then how to use the ids and the safety note. No filler and nothing buried at the end that an agent needs up front.

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-param, read-only listing tool with a full annotation set and an output schema, the description supplies everything needed: scope (reader's tree), hierarchy semantics, field meanings, and cross-tool linkage. Return-value details beyond that are covered by the output schema.

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 tool takes zero parameters, so there is nothing schema-wise to disambiguate and the baseline applies. The description spends its words on returned field semantics (id, parent id, path, direct item count) instead, which is the useful equivalent here.

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?

Specific verb+resource: 'List the reader's folder tree,' plus a clarifying equivalence to the category set driftnet sorts into. That distinguishes it from siblings like driftnet_get (retrieve one item), driftnet_create_folder (mutation), and driftnet_search (query items).

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?

'Use the ids with driftnet_move, driftnet_search and driftnet_recent' explicitly routes the agent to the downstream tools that consume this output, giving clear context for when to call it. It stops short of stating exclusions or prerequisites (e.g., call before saving if you need a folder id), so it is not a full when/when-not guide.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description reinforces read-only behavior. It adds useful behavioral detail beyond annotations by stating that it fails when no item has the given id and by describing the breadth of returned data.

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 the core operation, followed by contents, usage context, safety, and failure behavior. Every sentence contributes relevant information without 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 simple one-parameter read tool with no output schema, the description does enough: it explains what the item contains, when to call it, that it is read-only, and what happens on a missing id.

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 100%, so the single id parameter is already well documented. The description reinforces that lookup is by id and adds the failure condition, but it does not add new syntax or format details beyond the 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?

The description states a specific verb and resource: fetch a single catalogue item by id. It also enumerates what the item includes (summary fields, use cases, notes, chat context, embedded tools), which clearly distinguishes it from search and recent-list siblings.

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?

It explicitly says to use this after driftnet_search or driftnet_recent when details are needed, giving clear context for selection. It does not spell out when not to use it, but the intended usage path is unambiguous.

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?

Beyond the annotations, it discloses a real side effect — the placement is recorded as a human choice so automatic classification will not re-move the item — and states failure conditions when item or folder is missing. The no-op case when moving to the current folder usefully reinforces the idempotentHint rather than contradicting it.

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?

Four short sentences, each carrying distinct information: purpose, side effect, no-op case, and failure mode. The scenario example is front-loaded so an agent can decide quickly.

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 two-parameter mutation with annotations and no output schema, the description covers the important unknowns: persistence of the move, idempotency, and error conditions. It does not describe what the call returns on success, which is the only notable gap.

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 100%, and the schema already tells the agent that `folder` is a target folder id from driftnet_folders and `id` is the item to move. The description adds only the framing of a "reader's folder" and no syntax or format detail beyond the schema, so baseline 3 applies.

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 concrete verb and resource ("File an item into one of the reader's folders") and anchors it with a realistic scenario ("when it was sorted into the wrong one"). It distinguishes moving from automatic classification, though it never names a specific sibling such as driftnet_save or driftnet_enrich to contrast against.

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?

It gives a clear trigger condition (correcting a mis-sorted item) and rules out concern about re-classification. It stops short of explicit when-not guidance or naming which sibling to use for adjacent tasks like saving a new item.

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?

Adds substantial context beyond the annotations: a 30-minute exclusive lease with expiry and requeue semantics, the fact that an empty queue returns no items, the exact shape of the response (brief plus item fields), and an explicit prompt-injection warning about page content. These are exactly the behavioural traits annotations (readOnly=false, idempotent=false, destructive=false) cannot convey.

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 the lease rule before the follow-up workflow, and every sentence carries information. It is dense, with the return-value enumeration slightly packed into one long sentence, 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?

There is no output schema, and the description compensates by naming the returned fields (id, url, title, kind, category_guess, shared_with) and the accompanying brief. Combined with lease duration, empty-queue behaviour, and the next step, an agent has everything needed to call it correctly.

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 single 'limit' parameter is fully documented in the schema (1–10, defaults to 5), so the schema carries the load. The description never mentions batching at all, so it adds nothing on parameter meaning beyond the baseline.

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 — lease (not fetch) unsummarised links — and immediately scopes it with a parenthetical about login-walled posts the cheap path could not read. This clearly separates it from siblings like driftnet_get and driftnet_search, which retrieve rather than reserve work.

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?

Gives an explicit end-to-end workflow: lease, open with your own browser/video tools, identify the tool, then call driftnet_enrich. It also names the condition that brings items back to the queue (expired leases). It stops short of naming when to prefer a sibling (e.g. driftnet_get for already-summarised links), so it is strong but not a full when/when-not/alternative statement.

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?

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful behavior beyond that: results are ordered must-see then normal, capped at 30 items, and return the same fields as driftnet_search.

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 compact and front-loaded: it states the resource, ordering, cap, intended workflow, safety constraint, return shape, and alternative in a tight sequence.

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?

Given full schema coverage, an output schema, and annotations covering safety semantics, the description supplies the remaining decision-critical context: purpose, sorting, cap, return parity, and when to use search instead.

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 100%, so the schema already documents days, category, and min_worth in detail. The description adds only contextual hints like 'last few days' and 'best first', but does not further clarify parameter semantics.

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: listing recently shared items, sorted best-first, capped at 30. It also explicitly distinguishes this from driftnet_search by saying to use search for looking something up.

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?

It gives clear when-to-use guidance: call periodically to spot workflow-improving tools, and propose them to a human rather than installing anything. It also names the alternative for lookup use cases, driftnet_search.

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?

Goes far beyond the annotations with non-obvious traits: a 5–30 second blocking wait, dedup semantics for share-link and tracking-parameter variants (counts a share, returns the existing item), refusal of private/local addresses, and degraded behavior when no model is configured. These are exactly the operational facts an agent needs before committing to a slow call.

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 purpose and the latency expectation are front-loaded, and every clause carries information (dedup, refusal, no-model fallback). It is a single dense paragraph that would read better split into latency/dedup/fallback sentences, but no sentence is 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 mutating, open-world tool with an output schema already describing return fields, the description covers everything an agent must know: timing, idempotency mechanism, security refusals, and the missing-model path. Nothing material is left to inference.

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 100%, so both parameters are already documented, including tracking-parameter stripping and the note's classification role. The description adds only the consequence of URL normalization (no duplicate is created), not new syntax or semantics for either field; baseline 3 applies.

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?

Opens with a specific verb and resource ('Add a link ... to the reader's catalogue'), enumerates the link types it accepts, and describes the downstream pipeline (fetch, follow, file, rate, summarize). It is unmistakably the write/ingest entry point and clearly separable from retrieval siblings like driftnet_get and driftnet_search.

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?

Gives clear context for when this is the right call (saving a new link, waiting for processing) and routes the no-model case to driftnet_pending, with driftnet_search referenced for the return shape. It stops short of explicit exclusions, e.g. it never says to use driftnet_enrich to re-process an already-saved item or driftnet_search to check for duplicates first.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered; the description nonetheless adds real behavioral detail: field-level match scope, empty-query fallback, ranking order (best first, then recency) and exclusion rules (trashed, down-voted, injection-flagged). It repeats 'Read-only' (redundant with annotations) and enumerates return fields that the output schema already provides, so it adds context but doesn't fully focus on new information.

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 purpose and the call-before-choosing trigger, with no filler sentences. The trailing field enumeration ('id, name, url, folder, kind...') is the one element that doesn't fully earn its place given the output schema.

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 four-optional-parameter read tool with full schema coverage, an output schema and annotations, the description covers corpus scope, matching semantics, ranking, exclusions and sibling routing. The remaining redundancy (listing returned fields) is harmless.

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 100%, so a 3 is the baseline; the description earns extra by explaining what the query is matched against (names, summaries, tags, URLs, notes, chat text) and what an empty query does. It doesn't clarify category-as-folder-id or min_worth's enum ordering beyond what the schema already says.

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 ('Search the reader's catalogue of AI tools, repos, videos and guides'), plus the corpus's origin (shared in group chats). This clearly separates it from siblings like driftnet_recent (time-window) and driftnet_get (single item).

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?

Gives explicit when-to-use guidance ('Call it before choosing a tool or library for a task: someone may already have vetted one') and names the alternative for a different need ('Use driftnet_recent instead for a time-window feed'). The empty-query case is also bounded.

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