I build LinkDigest. Every number below is from a measured run recorded in the project log; nothing is projected.
The problem
Agents are good at reading and bad at opening. Give Claude Code, Cursor, or a Dify workflow a link from Xiaohongshu, Douyin, TikTok, YouTube or X and the usual tool — fetch the URL, parse the HTML — returns one of three things: an app-download shell, a login wall, or a page whose body is 264 characters of navigation because the post itself lives in a JSON blob or in a video. The agent reports "nothing useful here" and it is telling the truth about the HTML.
The substance of these posts is not text. It is speech in a video, words printed on images, screenshots of code, a recipe laid out in a photo. A plain fetch throws all of that away, and a share link from the app carries a token that expires in a few weeks, so even the HTML you do get is different depending on which link and which user-agent you used.
The solution
LinkDigest does the reading on its own servers and hands back text. One call:
curl -X POST https://linkdigest.dev/api/v1/digest \
-H "Authorization: Bearer $LINKDIGEST_KEY" \
-H "Content-Type: application/json" \
-d '{"url": "https://www.youtube.com/watch?v=CEvIs9y1uog", "format": "json"}'
returns the post's transcript with timecodes, every fragment of on-screen text, a description and OCR of each image, the caption and metadata, and a list of key points — as JSON, or as Markdown if you ask for it. Long media answers in two steps: a 202 with a job id, then the digest when it is done.
Measured, not estimated:
| post | what came back | time |
|---|---|---|
| a 17-image Xiaohongshu note | 17 images described and read, 381 on-screen text fragments, 13 key points | 119 s |
| a Xiaohongshu video note | ASR transcript, 56 on-screen text fragments, 12 key points | ~4 min |
| a YouTube talk (native captions) | 426 transcript segments, 190 on-screen text fragments | ~1 s cached |
| a two-photo X post | both photos described, 3 text fragments | ~20 s |
For agents: it is an MCP server
claude mcp add --transport http linkdigest https://linkdigest.dev/mcp \
--header "Authorization: Bearer $LINKDIGEST_KEY"
One tool, digest_url(url, format). The tool description tells the model exactly when to reach for it and which platforms are out, so an agent does not confidently hand you a failure. It is in the official MCP registry as dev.linkdigest/linkdigest, on Apify as three Actors, and submitted to the Dify marketplace.
What it does not do
This is the part I would want to know before pasting a key:
- Bilibili: not supported. Bilibili returns HTTP 412 to our server's address.
- Instagram: wired, not verified end to end. Facebook: out of scope.
- X long-form articles expose only their lead image; regular photo posts come back in full.
- A YouTube link is read by Gemini watching the video, because YouTube blocks datacenter IPs; if Google refuses a video, you get an honest stub, and it costs nothing.
- Anything that could not be read is named in a
degradedfield. A digest that read nothing is free.
Pricing
Three digests free, no card. Then $9 a month for 500 credits — a typical post is 1 credit, video 2 per started minute, and links anyone has already digested are free forever. https://linkdigest.dev/pricing
Why I built it
I kept pasting Xiaohongshu and Douyin links into agents and watching them fail, and the failures were silent — a confident summary of a login page. Two of the bugs I hit while building this are written up separately: share links have two domains and one of them fails silently, and what it actually takes to read a Xiaohongshu post from a server.
If you try it and something reads thin, reply here — I fix these the same day.
Top comments (0)