HackerTrans
トップ新着トレンドコメント過去質問紹介求人

ami3466

no profile record

投稿

[untitled]

1 ポイント·投稿者 ami3466·25 日前·0 コメント

[untitled]

1 ポイント·投稿者 ami3466·3 か月前·0 コメント

Show HN: tomcp.org – Turn any URL into an MCP server

github.com
34 ポイント·投稿者 ami3466·7 か月前·15 コメント

Show HN: AI Live Log Bridge- Feeds Cursor/Claude Terminal+browser Logs via MCP

github.com
1 ポイント·投稿者 ami3466·8 か月前·0 コメント

コメント

ami3466
·7 か月前·議論
The simplicity is a feature. I avoided headless Chrome because standard fetch tools (and raw DOM dumps) pollute the context with navbars and scripts, wasting tokens. This parser converts to clean Markdown for maximum density.

Also, by treating this as an MCP Resource rather than a Tool, the docs are pinned permanently instead of relying on the model to "decide" to fetch them.

Cloudflare Workers handle this perfectly for free (100k reqs/day) without the overhead of managing a dockerized browser instance.
ami3466
·7 か月前·議論
lol I got this domain at 2am and didn't think through.
ami3466
·7 か月前·議論
I see many of you asking about the differences between using this versus web_fetch. The main differences are the quality of the data and token usage.

1. Standard web_fetch tools usually dump raw HTML into the context (including navbars, scripts, and footer noise). This wastes a huge amount of tokens and distracts the model. toMCP runs the page through a readability parser and converts it to clean markdown before sending it to the AI.

2. Adding a website as an MCP Resource pins it as a permanent, read-only context, making it ideal for keeping documentation constantly available. This differs from the web_fetch tool, which is an on-demand action the AI only triggers when it decides to, meaning the data isn't permanently attached to your project.