driftnet

Save a link

driftnet_save_link

Idempotent

Save a new link to your catalogue: it fetches, files, rates, and summarizes the linked tool; strips tracking and merges duplicate shares.

Instructions

Add one link to the reader's catalogue and wait 5–30 s while driftnet fetches it, follows a post to the tool it is about, files it into a folder, rates it and, with a model configured, summarises it. Use it for a link that is new to you; to redo a card that already exists use driftnet_refresh_item, and to hand in your own summary for a queued card use driftnet_enrich_item. url: tracking parameters are stripped and share-link variants are recognised, so a link already in the catalogue gets one more share and the existing item comes back instead of a duplicate; private, local and blocked addresses are refused. note: why it matters or the message it came with; it guides the folder choice and is shown as chat context, and links inside it are ignored. Without a model the item waits for an agent to read it through driftnet_lease_items.

Input Schema

Name	Required	Description	Default
`url`	Yes	Public http(s) link exactly as shared, e.g. 'https://github.com/owner/repo'
`note`	No	Why it is interesting or the message it came with, up to 1000 chars

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.0.0Oct 30, 2026
- addedOutput schema / properties / corrected
```
Added value: +{
+  "type": "string"
+}
```

Changed3 schema fields changedv0.8.0Oct 29, 2026

addedOutput schema / properties / items / items / properties / health
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
addedOutput schema / properties / items / items / properties / stars
```
Added value: +{
+  "type": [
+    "number",
+    "null"
+  ]
+}
```

changedOutput schema / properties / items / items / required

Previous value: -[
-  "id",
-  "name",
-  "url",
-  "category",
-  "kind",
-  "worth",
-  "one_liner",
-  "demo",
-  "why",
-  "highlights",
-  "tags",
-  "shared",
-  "added",
-  "page_url",
-  "in_inbox",
-  "suggested_folders"
-]New value: +[
+  "id",
+  "name",
+  "url",
+  "category",
+  "kind",
+  "worth",
+  "one_liner",
+  "demo",
+  "why",
+  "highlights",
+  "tags",
+  "shared",
+  "added",
+  "page_url",
+  "in_inbox",
+  "health",
+  "stars",
+  "suggested_folders"
+]

Addedv0.7.0Oct 29, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Goes well past the annotations: discloses the 5–30 s blocking wait, the full fetch/follow/file/rate/summarise pipeline, URL normalisation (tracking params stripped, share-link variants recognised), the dedupe outcome (existing item returned, share count incremented), and refusal of private/local/blocked addresses. The dedupe behaviour is consistent with idempotentHint=true. Minor gap: it doesn't say what happens on a fetch failure or whether the wait is cancellable, so not quite 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.

Conciseness4/5

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

Front-loaded with the core action and the wait time, then alternatives, then a compact url:/note: breakdown. Every clause carries information, though the middle pipeline sentence is dense and could be split for faster scanning.

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?

An output schema exists, so return values need no elaboration, yet the description still tells the agent what comes back in the dedupe case (the existing item) and what the fallback is when no model is configured. Nothing an agent needs to call this correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by adding behaviour the schema cannot express — that url is normalised before matching and that private/local/blocked addresses are rejected, and that note drives folder selection, appears as chat context, and has its embedded links ignored. It adds real semantics rather than restating the field descriptions.

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 one link to the reader's catalogue") and immediately scopes the side effects of doing so. It explicitly names the two sibling tools it must not be confused with (driftnet_refresh_item, driftnet_enrich_item), so an agent can route correctly without opening any schema.

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 an explicit selection rule: use this for a link that is new, use driftnet_refresh_item to redo an existing card, use driftnet_enrich_item to submit your own summary. It also names a fourth path (driftnet_lease_items) for the no-model case, so every branch has a stated alternative.

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

Deploy Server