driftnet

Save a link

driftnet_save

Idempotent

Save a shared link to the catalogue: fetches the page, files it into a folder, rates it and summarizes it. Duplicates just add a share count.

Instructions

Add a link (GitHub repo, video, social post, product site, article) to the reader's catalogue and wait for it to be processed. driftnet fetches the page, follows a post to the tool it is actually about, files it into one of the reader's folders, rates it and, when a model is configured, writes a summary; this can take 5–30 seconds. Saving a link that is already catalogued (including share-link and tracking-parameter variants) does not duplicate it: it counts one more share and returns the existing item. Links to private or local addresses are refused. Without a model, the item comes back without a summary and waits in the queue (see driftnet_pending). Returns the saved item with the same fields as driftnet_search.

Input Schema

Name	Required	Description	Default
`url`	Yes	The http(s) link to save, exactly as shared; tracking parameters are stripped automatically
`note`	No	Why it is interesting, or the message it was shared with; helps classification

Output Schema

Name	Required	Description	Default
`items`	Yes
`notice`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.1.1Oct 28, 2026

changedInput schema / properties / note / description

Previous value: -"Why it is interesting / the text it was shared with"New value: +"Why it is interesting, or the message it was shared with; helps classification"

addedInput schema / properties / url / description

Added value: +"The http(s) link to save, exactly as shared; tracking parameters are stripped automatically"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "items": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "added": {
+            "type": "string"
+          },
+          "category": {
+            "type": "string"
+          },
+          "highlights": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "id": {
+            "type": "number"
+          },
+          "kind": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "one_liner": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "shared": {
+            "type": "number"
+          },
+          "tags": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "url": {
+            "type": "string"
+          },
+          "worth": {
+            "enum": [
+              "skip",
+              "low",
+              "normal",
+              "must-see"
+            ],
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "name",
+          "url",
+          "category",
+          "kind",
+          "worth",
+          "one_liner",
+          "highlights",
+          "tags",
+          "shared",
+          "added"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "notice": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "notice",
+    "items"
+  ],
+  "type": "object"
+}

First observedv0.1.0Oct 28, 2026

TDQS

A4.4/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server