让 AI 查一份工具清单时，回答看起来完整，不代表它真的读过最新网页。常见情况是：搜索摘要里写着某个价格，打开页面却发现只适用于年付；文章提到一项功能，官方文档已改成另一种限制。给助手接上搜索，解决了发现资料的问题，核对资料还需要下一步。
Monid 宣传由 TinyFish 支持的免费搜索与页面读取，TinyFish 也提供自己的 API 和 MCP 接入。两者名字经常一起出现，容易让人误以为是同一个账号、同一套接口，甚至以为所有浏览器操作都免费。下面按 2026 年 9 月 23 日公开页面说明区分这些入口，并给出一套可以自己执行的评估方法。本文没有调用付费服务，也没有编造搜索成功率或延迟数据。
先分清接的是哪一个入口
Monid 是工具聚合入口，其 TinyFish 介绍页强调搜索和抓取免费，不要求 API key 或信用卡。这是该页面对自己接入方式的说明，不能推导为 TinyFish 所有接口都匿名开放。Monid 产品介绍
TinyFish 官方 Search API 文档要求请求携带 X-API-Key，而官方 MCP 使用账号授权。对于开发者，这意味着连接方式要按所选入口配置。拿 Monid 的宣传语去排查 TinyFish REST 接口为什么要求密钥，很容易在错误方向上花时间。TinyFish Search API · MCP 接入
还有一个值得记录的细节：本次查看 Monid 页面链接到的 TinyFish 工具目录时，目录仍显示没有端点条目。因此，宣传页面足以证明它在介绍什么，但不足以单独写出一份已验证的接口调用教程。实际接入前还要查当前接入说明，并确认工具列表里出现了什么。Monid TinyFish 目录
如果已经在使用 Monid，可以从它现有工具列表验证搜索与读取；如果在开发独立程序，则比较 TinyFish 官方 API 的字段、鉴权和错误处理。没有必要仅为了同一个查询同时接两套系统。优先选择能看清调用记录、来源和费用的方式。
Search、Fetch 与浏览器操作各做什么
Search 适合不知道目标网页时使用：输入主题，获得标题、摘要和 URL。Fetch 适合已经有链接，需要正文内容时使用。浏览器自动化则可能涉及点击、填写表单和多步导航，执行成本与权限范围都不同。
比如要核对某个开源项目是否支持 Windows，先搜索项目名称和官方仓库，找到文档以后读取系统要求和发布记录。一般不需要打开一个可交互浏览器让它四处点击。只有信息必须通过页面操作才能看见时，再考虑额外能力。
TinyFish 当前 MCP 文档将搜索和 Fetch 列为免费，将 Agent 和 Browser 列为计费能力。免费搜索并不意味着助手能无限制地调用所有工具；模型本身、你自己的服务和其他工具也可能产生费用。本次不引用会变化的具体付费单价，使用前应查看实际账号对应规则。
在配置助手时，可以先只开放搜索和读取，观察它是否能完成目标任务。需要浏览器操作时，再给出具体用途。例如“查看公开的交互式产品比较表”与“登录后修改账号设置”，所需的权限和验收方式显然不同。工具名字都带 web，不应因此一并开放。
用一个具体问题测试整条检索过程
不要只问“推荐几个好用的项目”。这类问题没有明确答案，输出流畅就很容易被认为成功。可以换成一个可核对的问题：某个项目在指定版本中，是否提供官方 Windows 安装包，以及安装前需要什么运行环境。
第一次搜索限定项目官方域名或仓库线索，保留候选 URL。接着读取下载页与对应发布记录，查看文件名、适用平台和版本日期。最后回答时，把“当前主分支文档说明”与“选定版本实际附件”分开。主分支支持的能力，未必已经进入旧版本安装包。
记录这次测试时，保存查询词、执行日期、目标页面、页面读取是否完整、最终结论的依据。若工具只拿到导航菜单，就记作未取得正文；若下载页要求登录，就记作访问受限。不要让助手用另一个博客里的猜测填补空白。
接下来换三类资料：一个内容较短的静态文档，一个通过 JavaScript 呈现的产品页，一个带表格和注释的计费页。这样可以看出问题出在搜索命中，还是正文提取、表格保留、注释遗漏。把不同环节的失败合成一个“好不好用”的印象，很难指导调整。
提取成 Markdown 以后仍要检查什么
页面读取工具会尽量把网页变成模型容易处理的文本，但正文清理也可能改变信息位置。原本写在价格下方的“仅首年”或“按年付款”，提取后可能与金额相隔很远；表格的列名若丢失，数字就失去了含义。
因此，遇到价格、限额和支持范围，应同时读取相关脚注及说明。回答可以写成“页面在本次核查时列出某条件下的方案”，并附直接来源，而不是把一个短期活动价格写成长期固定成本。
TinyFish Fetch 文档说明支持页面内容提取，并在需要时处理 JavaScript 页面。这是产品能力描述，不能保证所有站点都能完整读取。登录墙、地区差异、页面改版和动态组件仍需要在实际目标上检查。Fetch API
如果读取失败，合理的处理顺序是先确认 URL 是否正确、普通浏览器是否可访问、页面是否换址，再检查工具错误。持续重试相同请求可能只得到更多失败记录。确实拿不到的资料，可以在结果中保留缺口，让用户知道结论还缺哪一页支持。
新鲜度筛选与事实发生时间不同
新闻检索常见一个陷阱：把最近发布的回顾文章当成最近发生的事件。搜索的新鲜度筛选帮助缩小页面范围，却不会自动改变文章里事件的时间。写产品发布情况时，应分别记下公告日期、功能开始提供的日期和本次核查日期。
技术资料也一样。一篇刚更新的教程可能仍在使用旧版 SDK，仓库的新提交也可能只是修改文档。对安装方式和接口字段，最好再核对版本号、发布标签或官方迁移说明。单独一个“更新于今天”标签，解释不了代码应该如何运行。
如果是在追踪变化，先保存上一次的有效内容和来源，再比较本次读到的内容。工具报告页面未变，只能说明它使用的比较方式没有发现变化；不能据此声称外部产品的所有政策都保持不变。重要结论仍应回到具体页面与条目。
给助手的任务描述可以更具体
下面是一段用于资料核查的示例任务，不依赖某个私有接口：
核对项目 X 的版本 Y 是否支持 Windows。
先找到官方发布记录与安装说明，再读取全文。
分别记录适用版本、安装文件和运行前提。
每项结论附直接来源；正文读不到时保留未确认状态。
不要把搜索摘要当作安装说明，不执行下载或安装。
这类任务的价值在于输出能验收。换一个工具运行同样的任务，就能比较哪一个找到了直接证据，哪一个遗漏了限定条件。评估时还可以放入一个“官方资料没有答案”的问题，看助手是否愿意保留不确定性，而不是总能生成一个肯定回答。
网页里的文本也只是资料。如果页面包含让助手改变任务、泄露配置或调用其他服务的指令，它不应该因此获得权限。把搜索结果送给模型时，保留来源信息，并让业务工具自行校验参数。资料核查不应因为读到一段网页文字，自动变成发送消息或购买服务。
接入以后，保留能替换它的余地
应用代码可以把搜索结果统一整理为标题、URL、摘要和查询时间，再把全文读取单独封装。这样以后换服务时，不必改写整套回答生成流程。错误也按搜索失败、读取失败、资料缺失分别记录，方便对症处理。
选择 Monid 或 TinyFish，最终要看它是否稳定取得你需要的资料、能否保留来源，以及实际工作流的成本是否可接受。免费入口很适合开始做小样本验证；是否用于日常生产，则要靠自己的目标页面和重复任务记录判断。先完成一次能够逐条核对的查询，再逐渐扩大使用范围。