Skip to main content
Glama
Sign In
KevinChu1110

driftnet

by KevinChu1110
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Star, note, tag, vote on or trash an item

driftnet_update_item
Idempotent

Change one saved item's reader state: star it, set its note or tags, vote it up or down, trash or restore it, or roll back to an earlier version.

Instructions

Change how the reader keeps one item: star it, write its note, set its tags, vote on it, or move it to or from the trash. Returns one line saying what changed, e.g. "Item 42: starred, note saved." To file it into a folder use driftnet_move_items; to change its summary use driftnet_refresh_item. Pass only the fields to change, at least one. note replaces the whole note, so read the current one with driftnet_get_item first if you mean to add to it; an empty string clears it. tags replaces the whole tag list of the summary, so pass the full list you want ([] clears it); it fails on an item with no summary yet. vote counts once per agent per item, and a new vote replaces yours; down-votes lower the publisher's reputation and two net down-votes hide the item from search. vote_reason is stored only together with a vote. So for a wrong or spammy summary prefer vote down, and trash only what the reader asked to remove. trashed=true hides the item everywhere without deleting it; trashed=false brings it back with its folder, note and favorite. restore_version puts an earlier version back (alone; a wrong version id lists the valid ones). Setting a value it already has changes nothing. Fails if the item does not exist.

Input Schema

NameRequiredDescriptionDefault
idYesItem id from driftnet_search_items (view 'trash' lists trashed ones), a positive integer such as 42
noteNoThe whole new note, plain text up to 5000 chars; '' clears it
tagsNoThe whole new tag list, up to 8; [] clears it
voteNoup: useful and accurate; down: spam, outdated, wrong or polluted
trashedNotrue to move to the trash, false to restore from it
favoriteNotrue to star, false to unstar
vote_reasonNoShort reason for the vote, e.g. 'summary describes the wrong tool'
restore_versionNoVersion id of an earlier state of this item to put back; cannot be combined with other fields

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.0
    • addedInput schema / properties / tags
      Added value: +{
+  "description": "The whole new tag list, up to 8; [] clears it",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 8,
+  "type": "array"
+}
  2. Changed1 schema field changedv0.10.0
    • addedInput schema / properties / restore_version
      Added value: +{
+  "description": "Version id of an earlier state of this item to put back; cannot be combined with other fields",
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}
  3. Addedv0.7.0

TDQS

A4.5/5.0
Behavior3/5

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

Annotations already declare idempotentHint=true, destructiveHint=false and readOnlyHint=false, so the description's semantics-rich content is a genuine bonus rather than a burden-lifter: it discloses replace-not-append semantics, per-agent vote counting, the reputation/hiding effect of down-votes, and that no-op writes change nothing. It also discloses the failure mode for nonexistent items. The one substantive gap is that trash is described as reversible, consistent with destructiveHint=false, but the description never states that the tool returns a confirmation without side effects at the item level — a 3 reflects that annotations already carry the safety profile and the description mostly reinforces rather than extends it.

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

Conciseness4/5

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

Front-loaded with purpose and sibling routing before the detailed field semantics, and nearly every sentence carries non-obvious operational information. It runs long and unstructured, with field semantics packed into semicolon-chained clauses, but there is little genuinely removable content.

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?

Covers all 8 parameters at 100% schema coverage, describes the return shape inline ('one line saying what changed') despite the absence of an output schema, and includes failure and no-op conditions. 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.

Parameters5/5

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

Although schema coverage is 100% and the baseline would be 3, the description adds meaning the schema cannot express: note and tags are whole-value replacements (not merges), [] clears tags, vote_reason is only persisted alongside a vote, and restore_version must be used alone and lists valid ids when wrong. These are exactly the semantics an agent would otherwise get wrong.

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?

Opens with a specific verb set and scope ('Change how the reader keeps one item') and enumerates the exact mutations (star, note, tags, vote, trash). It explicitly names the two adjacent siblings it is not (driftnet_move_items for folders, driftnet_refresh_item for summaries), so an agent can route correctly without opening schemas.

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?

Gives explicit when-to-use routing to alternatives, plus selection guidance between competing fields: 'for a wrong or spammy summary prefer vote down, and trash only what the reader asked to remove.' It also states the prerequisite for partial updates ('at least one field') and the read-first workflow for notes.

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

Deploy Server

Other Tools