This MCP server exposes a local-first asset inventory for AI agents on a Windows machine, letting agents query what's installed, what was done, and where records live — all via 8 tools.
inventory_overview — Get a machine-wide summary: counts of agents/skills/MCP services/projects, main project list, and activity in the last 7 days.
inventory_index — Get a cheap token-saving directory page: record-source file counts, latest dates, and main project list; use it before deep searches.
inventory_search — Full-text search across agents, skills, MCP services, projects, and agent work records, returning file names, line numbers, and context snippets.
inventory_project — View a full project profile: implemented features, dev logs, artifact paths, and participating agents; omit name to list all main projects.
inventory_agents — List installed agent clients: names, categories, executables, record directories, and descriptions.
inventory_recent — See what each agent did in the last N days, grouped by agent, with tasks and artifact paths.
inventory_skills — Search the local skill library by keyword to find existing skills and their paths.
inventory_reindex — Trigger a rescan of the machine's inventory (and optionally transcribe agent logs) when data may be stale.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@agent-inventory search the inventory for recent work on the billing project"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
中文 ｜ English
AI agent inventory·MCP server·skill manager·record index· 本地优先、不上传
把一台 Windows 电脑上散落的 AI Agent、技能、MCP 服务与主要项目扫成一张名册 —— 并且把它们的记忆与工作记录就地索引起来，交给它们自己查。
这一版把上一版留下的一个包袱整块拆掉了，并重排了工作台。
废掉「一格一 Agent 的工作记录夹」 —— 上一版让每个 Agent 把整理稿交进
<应用目录>/通用资源/工作记录/<Agent>/。实践证明这层预付款不划算：
要催、会过期、漏写就永远查不到。本版只认各家原生位置（就地读），
应用不再自留一格，也不再产出 works_dir；搜索与项目页的原料全部改回原生记录。
工作台重排（每个 Agent 一页）：
打开本体目录 —— 一键开它本体所在的总目录；
手动添加检索地址 —— 原来的「＋添加检索地址」与「复制自报家门问话」合并成一枚： 点开即摊开一层提示（含可直接粘给该 Agent 的提示词 + 「选择目录加入…」）；
接入 Agent 从首页搬进工作台，并且只对这一个 Agent 生效；
地址清单一律常态摊开，且不再区分内置 / 手工（都是它记录所在之处）； 手工登记的那条可右键移除。
撤掉「记录来源」窗 —— 内容已在各工作台里；卡片上「记录」灯改为点开该 Agent 的工作台。
「主要项目」升格为「人划的重点」：新增 【编辑我划的重点】，写一份人工清单， 优先于自动摘录显示给人看；自动摘录处一律标注「自动摘录，供定位」。
让 Agent 先查主要项目：接入指引与 MCP 提示都改成
inventory_index（目录页，约 266 token）→ 命中主要项目就 inventory_project
→ 没命中再 inventory_search。项目全貌也瘦身了（功能 8 / 开发日志 8 / 任务 5 条）。
首页右上角可摆一张配图 + 一条横贯粗线（默认关闭，见源码里的 HOME_ART_* 常量；
那条线的位置与粗细从图上现量，换图会自动跟着变）。
若干界面修正：首页统计条不再塌成一张巨卡；工作台的启动键挪到页头； 悬停说明可指定弹出方向（默认仍在控件正上方）。
升级提示：旧版在应用目录下留的
通用资源/工作记录/<Agent>/已不再被读取， 可以整个删掉或自己归档，不影响任何功能。
截图为示例数据，不含任何真实路径与项目名。
Related MCP server: rvn
到 Releases 下载
AgentAssetOverview.exe，双击即用：
不需要装 Python，不需要配任何环境；零第三方依赖（界面只用标准库 tkinter）；
首次运行自动扫描你这台机器；名册带「产地戳」，别人带来的底册会被识破并弃用重扫；
一枚 exe 两个身份：双击 = 图形界面；带 --mcp 启动 = MCP 服务端（各 Agent 用它来查你的资产）；
高 DPI 屏（125%/150%/200%）原生渲染不糊；窗口尺寸自动夹进屏幕可用区。
用 AI 的人，机器上不知不觉装了一堆东西：编程助手、聊天机器人、绘图工作流、各种技能与 MCP 服务。 更麻烦的是 —— 它们各自失忆：
你上周跟 A 说的事，B 不知道；
过一个月，连 A 自己也想不起来了；
你自己也记不清"那个项目到底做到哪一步了"。
所以这个工具做三件事：
摆成一张桌子 —— 本机的 Agent / 技能 / MCP 服务 / 主要项目，一屏看尽；
就地索引它们的记忆 —— 各家的记录长在哪儿就读哪儿，不复制副本；
把这份索引交给它们自己用 —— 接上 MCP，并在它们每次必读处写一条 **「每轮先查再答」**的规则。
栏目 | 内容 |
Agents | 本机的 Agent 客户端（内置登记表 + 快捷方式 + 全盘寻真身 + 按特征自动发现）。卡片右上角有三盏接入灯（记录 / 人格 / MCP），灯能点 —— 暗灯点一下就知道该补什么。点卡片进工作台；登记路径落空时按名字在常见位置找它的落脚点 |
技能 | 用户级与项目级技能（读 |
MCP 服务 | 各家客户端的 MCP 注册（WorkBuddy / Cursor / Claude Desktop / AstrBot / Codex）。只收通用项 —— 绑死在某个客户端私有运行时目录里的会被剔除 |
主要项目 | 你划重点的项目：已实现的功能、开发日志、产物完整路径，一页看尽。项目页还带一枚 【编辑我划的重点】 —— 人工写的清单优先于自动摘录 |
按名字认人：登记表里的 @HOME%\AppData\Local\Programs\… 不再当硬性条件 ——
常见位置（含 Program Files、各盘根、桌面/文档/下载）里只要有一格名字对得上的文件夹
（如 Codex++），就把它认出来；里面再挑一枚主程序（挑不到也算认出来）。
认出来的来源会标成「按名字找到 · 目录名」，方便你分辨真假。
修掉两处只在新电脑首次扫描时才会炸的崩溃（批量整理任务那一段的两个未定义变量）。
工作台：启动键做成这一页唯一的主操作（实心近黑、大一号、带按下反馈）； 每条地址后面多一枚 「复制」 小标；任何一条地址都可右键删除 （内置的删掉后不再登记也不再读，可一键恢复）；新增 【自动检索】 —— 重新枚举它的记录位置，并在它本体目录下找一层候选目录供一键登记。
同一个目录被登记了两种读法（.jsonl 摘录 + 文本直读）时合并成一行显示，
且计数各按各自真正读的东西算。
各家的记录存放在哪，就直接读哪：
来源 | 位置 | 处理 |
WorkBuddy 会话记忆 |
| 直接读 |
WorkBuddy 长期记忆 |
| 直接读 |
WorkBuddy 会话存档 |
| 摘录 |
Codex 笔记 |
| 直接读 |
Codex 会话实录 |
| 摘录 |
AstrBot 对话记忆 |
| 摘录 |
AstrBot 会话工作区 |
| 直接读 |
桌面文本 |
| 直接读 |
你自己登记的位置 | 见下「让 Agent 自报家门」 | 直读或摘录 |
三档处理：
直接读 —— 搜索 / 工作台 / MCP 全都就地读，不复制、不落后，新写的内容立刻可查；
摘录 —— 太大或不是给人读的（十几 MB 的 jsonl、SQLite 库），摘成可读文本放进
%LOCALAPPDATA%\Agent资产总览\digest缓存\（可随时重建，不是唯一副本）；
只登记 —— 私有二进制格式（如 Cursor 的 workspaceStorage），只标出位置。
为什么不再"抄录"：抄录要事先把每个来源都写对，漏一处就永远抄不到（真栽过四次）； 就地索引没有"漏抄"这回事，也不存第二份。
不必猜各家目录结构 —— 问它自己：
打开某 Agent 的工作台 → 点 【手动添加检索地址】；
摊开的那层提示里就有现成的提示词 → 点「复制提示词」发给那个 Agent → 它会报出自己记忆/记录的目录（绝对路径、文件数、体量、文本还是二进制）；
拿到地址后，逐个点 【选择目录加入…】 → 选目录 → 按提示确认 （应用先探测体量，建议「直读」还是「摘录」）。
登记完 立刻纳入检索 ✓
工具 | 作用 |
| 一页目录（约 266 token）：各记录来源的文件数与最近日期 + 主要项目清单 |
| 本机总览：四栏计数 + 主要项目 + 近 7 天谁在干活 |
| 四栏 + 各 Agent 工作记录全文检索（回文件名·行号·上下文） |
| 某项目全貌：已实现功能 / 开发日志 / 产物完整路径（命中主要项目时先查它最省；人工写的「我划的重点」优先，自动摘录处会标注） |
| Agent 名册（可执行文件、记录目录、简介） |
| 最近 N 天各 Agent 干了什么 |
| 技能库检索 |
| 重扫本机（可顺手重建摘录缓存） |
全盘搜索在本地工具进程里跑，进模型上下文的只有命中片段 —— 实测一次检索回几百字， 而全库有十几 MB。所以库再大，你的 token 花费不变。
接上 MCP 只是把工具放在它手边；要它主动用，还得写一条规则。应用会把这条写进 各 Agent 每次必读的地方：
每一轮对话，在回答之前都先查一遍 —— 不要等对方说「还记不记得」。 先
inventory_index()看目录，再按关键词inventory_search(...)，命中才细读。
已支持自动写入：AstrBot（人格，存 SQLite）、WorkBuddy（SOUL.md / MEMORY.md / AGENTS.md）、
Codex（AGENTS.md）。不读这类文件的客户端（Claude Desktop / Cursor / ComfyUI 等）
窗口里有「复制指针原文」，人工粘进它的设置即可。
每张 Agent 卡片点进去就是它的工作台：
启动 <Agent>（页头）：开它的本体 —— 这一页唯一的主操作（实心近黑、大一号）；
打开本体目录：一键开它本体所在的总目录；
手动添加检索地址：摊开一层提示 —— 可复制的提示词 + 「选择目录加入…」（见上）；
接入 Agent：只给这一个接 MCP、放「每轮先查再答」指针，并给出自检提示词与 「复制读取指引（免 MCP）」；
自动检索：重新枚举它的记录位置，并在它本体目录下找一层候选目录（可一键登记）；
正文：它的数据文件地址一条条摊开（内置与手工一视同仁）—— 点路径即打开该位置、点 「复制」 拷走这一条、任何一条都可右键删除 （内置的删掉后不再登记也不再读，清单末尾给「恢复」）； 同一目录的两种读法会合并成一行显示；
可编辑简介：每个 Agent 都能写一段自己的简介，存 agent_intros.json，重扫不会丢。
悬停说明：鼠标停在按钮上即弹一句话说明 —— 按控件类接管，以后新加的按钮自动生效；可指定弹在控件上方或左侧；
首页配图（可选）：HOME_ART_* 常量指向一张本地图片，它会被等比例缩到
「页头 + 统计条」那块大小摆在右上角，并可附一条横贯全宽的粗线；默认关闭；
快捷键：Ctrl+F 聚焦搜索 ｜ F5／Ctrl+L 重新扫描 ｜ Ctrl+1..4 切栏 ｜
Ctrl+P 设置主要项目 ｜ Esc 清空搜索；
空栏目连页签一起隐去；没检索到的东西不摆出来；
配色克制：暖白底 + 超淡边（#eaeaea）+ 近黑字（#111111），颜色只用于语义。
需要 Windows + Python 3.9+，没有第三方依赖。推荐用 uv：
winget install --id=astral-sh.uv -e # 或: pip install uv
git clone https://github.com/YOZODO349/agent-inventory.git
cd agent-inventory
uv run python src/agent_inventory_app.pysrc/ 里这几个文件必须在同一目录（程序以自身位置为基准找它们）：
agent_inventory_app.py 主程序（图形界面）
glass_widget.py 卡片控件
scan_agents.py 采集器：技能 / MCP
scan_agents_apps.py 采集器：Agent 客户端 / 记录根登记表 / 就地索引
agent_mcp.py MCP 服务端（stdio，纯标准库实现）
agent_onboard.py 接 MCP + 放人格指针 + 自报家门技能服务端命令就是那一枚 exe（或源码运行时用 python）：
// 例：~/.workbuddy/mcp.json、~/.cursor/mcp.json、Claude Desktop 配置
{"mcpServers": {"agent-inventory": {"command": "D:\\path\\AgentAssetOverview.exe",
"args": ["--mcp"]}}}AstrBot 另有讲究：它对 stdio MCP 的启动命令有白名单（只认
python/node之类）， 故要写"command": "<python.exe>", "args": ["<应用目录>\\agent_mcp.py"]， 见它的core/agent/mcp_client.py。图形界面的 接入 Agent 会把上面这些改动代办好（改前一律备份， 改动清单在窗口里可见）。
uv run pyinstaller --noconfirm scripts/build_exe.spec产物 dist/AgentAssetOverview.exe。
规格里 console=True —— 因为 MCP 的 stdio 通道在窗口模式下不可靠
（PyInstaller 会把 sys.stdout 当作不可用）；
图形界面启动时自行隐藏那枚控制台窗口（_hide_console()），观感与从前一致。
程序会在自己旁边长出这些（都是本机数据，不进版本库）：
通用资源\skills\ 技能库真身（各家技能架里留的是指向这里的链接）
通用资源\安卓模拟器MCP\ 自带运行时的安卓工具链（若你部署过）
主要项目.json 你设的主要项目
agent_intros.json 你写的 Agent 简介
MCP设置.json 脱敏开关 / 自动接入开关用户目录那边还有两处（与本应用相关）：
%LOCALAPPDATA%\Agent资产总览\digest缓存\ 摘录出来的可读文本（可随时重建）
%LOCALAPPDATA%\Agent资产总览\检索地址.json 你登记的检索地址改 src/scan_agents_apps.py，格式照抄：
常量 | 用途 |
| 已知 Agent 客户端登记表（路径用 |
| 各客户端的「真身」特征名，登记路径落空时靠它全盘找 |
| 记录根登记表：哪个 Agent 的记录在哪、怎么处理（直读 / 摘录 / 只登记） |
src/agents.json 与 src/agent_inventory.json 是运行期产物，采自你自己的电脑：
里面有你的用户名路径与你装的技能清单。已在 .gitignore 中忽略，请勿提交。
每次启动都会检查它们的「产地戳」，不是本机的就整份弃用重扫。
本机 Agent 客户端名册：名字、分类、可执行文件、工作记录目录、简介。想知道「这台机器上有哪些 Agent 可以干活、它们的记录在哪」用它。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. '名册' and '有哪些…在哪里' make clear this is a read-only listing of local client configuration rather than an action/mutation, and the listed fields hint at the report shape. It could be more explicit about side-effect-free behavior or data source, but the inventory framing is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence front-loads the resource and contents, then gives the exact user question that should invoke it. Every clause adds value; no repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema inventory tool, the description fully covers what the tool is, what data it exposes, and when to call it. Nothing necessary for selecting and invoking the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema has 100% coverage, so there is no parameter information for the description to add. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description identifies a precise resource (local Agent client roster) and enumerates its contents: names, categories, executables, work-log directories, and summaries. The '想知道…用它' phrasing makes the intended selection immediate and distinguishes this listing tool from sibling inventory tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit trigger condition: use when you need to know which Agents on this machine can work and where their records live. It does not name alternative tools or state when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
最省 token 的第一步：一页目录 —— 各记录来源的文件数与最近日期、主要项目清单。先看它（几百字），再决定要不要 inventory_search / inventory_project 深挖；别让模型自己去逐个读文件。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the call is lightweight ('最省 token'), returns a one-page directory, and implies a read-only operation by positioning it as an overview. It doesn't mention potential errors or caching, but for a 0-parameter read tool this is adequate and not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, punchy sentence in Chinese, front-loaded with the core value proposition ('最省 token 的第一步'). Every clause earns its place: it states the content, the timing, and the alternative tools. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description provides enough for an agent to call it correctly: it explains what the result contains (file counts, recent dates, project list) and when to use it. It doesn't specify the exact return format or pagination, but for a simple index tool this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description adds no parameter-level detail because none is needed; the schema itself is empty. The description focuses on the output semantics, which is appropriate for this tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool provides a one-page directory listing the file count and most recent date for each record source, along with a list of main projects. It explicitly positions it as the first, token-saving step and differentiates it from deeper tools like inventory_search and inventory_project, so an agent can identify its specific role among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: it should be consulted first ('先看它'), and the agent should then decide whether to use inventory_search or inventory_project for deeper investigation. It also warns against reading files individually, which serves as a clear alternative behavior to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
本机 AI Agent 资产总览：各栏数量、主要项目清单、近 7 天各 Agent 的工作量。想了解这台机器上装了什么、在做什么，先用它。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the nature of the output (counts, main projects, 7-day workload) and implies a read-only overview. Still, it does not state whether it is non-mutating, whether data is cached or live, or any caveats about the overview's completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the core purpose and immediately lists the key contents. It then adds a practical usage hint. Every phrase contributes value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description gives a reasonable sense of what will be returned and when to call it. The ambiguity of '各栏数量' and '主要项目清单' slightly reduces completeness, but overall the agent can safely decide to invoke it as an overview.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so parameter descriptions are unnecessary. The baseline for 0-parameter tools is 4, and the description does not need to add parameter-specific meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool produces a local AI Agent asset overview with item counts, a main project list, and per-agent workload over the past 7 days. It is distinct enough from sibling tools by positioning itself as the initial entry point, but it lacks an explicit verb like 'retrieve' or 'show' and does not sharply contrast with inventory_index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear guidance: '想了解这台机器上装了什么、在做什么，先用它' tells the agent to use this first when checking what is installed or active. However, it does not explicitly mention when not to use it or name specific alternative siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
某个「主要项目」的全貌：已实现的功能、开发日志（含产物完整路径）、参与 Agent。不传 name 则列出所有主要项目。多个 Agent 接力做的项目，用它能一次看全。
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | 项目名（可部分匹配）；留空则列出全部 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses what the output contains (features, dev logs with full paths, participating agents) and the conditional behavior when 'name' is not passed. It implies a read-only operation but does not explicitly state safety or side-effect profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the resource and contents first, then the conditional behavior, then a relevant use case. Every clause earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description reasonably compensates by naming the key return categories. For a simple one-optional-parameter tool, it is largely sufficient, though it could go further on exact response shape or ordering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the 'name' parameter, including partial matching and blank-to-list-all behavior. The description adds no substantial semantic detail beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to show a complete picture of a major project, including implemented features, development logs with artifact paths, and participating agents. It also distinguishes its scope by noting that omitting 'name' lists all major projects and that it is useful for multi-agent relay projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('multiple agents working in relay') and the behavior when 'name' is omitted, but it does not explicitly contrast this tool with its siblings or state when not to use it. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
最近 N 天各家 Agent 干了什么（按 Agent 分组，含任务与产物路径）。接手别人的活、续接上次进度时用。
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | 天数，默认 7 | |
| agent | No | 只看某个 Agent（可部分匹配），可省 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the output grouping, included content (tasks and artifact paths), and the recency window. However, it does not mention side effects, sorting, data source, or other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The first sentence states purpose and output content up front; the second gives a concrete use case. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two optional parameters and no output schema, the description covers the purpose, use case, grouping, and output content. It does not detail exact output formatting or behavior when no agent is specified, but the schema already covers the parameters, making the remaining gaps minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both days and agent are already documented in the schema. The description reinforces the agent-grouping idea but does not add substantive parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: returning what each Agent did over the recent N days, grouped by Agent and including tasks and artifact paths. This clearly distinguishes inventory_recent from its siblings by focusing on recent per-Agent activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use the tool: when taking over someone else's work or resuming previous progress. It does not mention alternatives or when not to use it, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
重扫本机名册（技能/MCP/Agent/任务表），可选顺手把各 Agent 的日志抄录进来。当你怀疑数据过期、或刚做完一批活想让记录进库时调用。
| Name | Required | Description | Default |
|---|---|---|---|
| transcribe | No | true 则同时抄录各 Agent 日志，默认 false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the two main behaviors (rescanning the local inventory and optionally transcribing agent logs into it), which implies a mutating/persist operation. However, it does not disclose side effects such as whether existing records are overwritten, whether the operation is idempotent, whether it is slow/heavy, or what it returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact two-part description: purpose first, usage trigger second. No wasted sentences, and the core rescan behavior is front-loaded ahead of the optional parameter note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple single-parameter tool with no output schema or nested objects, but gaps remain: no return-value description, no side-effect disclosure, and no explicit routing among the seven sibling inventory tools. An agent could still mis-select it without reading the sibling schemas.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (transcribe) exists and schema coverage is 100%, so the schema already documents its meaning and default. The description reinforces the same concept (optional log transcription) without adding syntax or edge-case detail, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (重扫/rescan) with a precise resource scope (本机名册 of 技能/MCP/Agent/任务表), plus the optional log-transcription behavior. It clearly identifies the refresh-type action, which is distinct in spirit from the sibling search/overview/recent tools, though it does not explicitly name any sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit trigger conditions: call when you suspect data is stale, or right after finishing a batch of work that should be persisted. This is actionable guidance, but it omits when-not-to-use and does not name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
跨栏全文检索：Agent 名册、技能、MCP 服务、主要项目，以及各 Agent 的工作记录（逐字翻，给文件名·行号·上下文）。查「某功能/某项目由谁在哪做过」用它。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 各类最多返回几条，默认 20 | |
| query | Yes | 关键词（中文/英文均可） | |
| scope | No | 检索范围，默认 all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that results are verbatim and include file names, line numbers, and context, which gives the agent a clear picture of output behavior. It does not discuss limits or side effects, but for a read-only search operation this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with no filler. The scope of search and the distinctive work-record feature are front-loaded, and the use case is given immediately. The slight typo '跨栏' does not undermine clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple search tool with full schema coverage and no output schema, the description covers the key agent-facing needs: what is searched, what the result includes, and when to use it. It does not spell out the exact response format, but it conveys enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no parameter-level meaning beyond what the schema provides, which matches the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('检索') and a clear resource: full-text search across agent rosters, skills, MCP services, projects, and work records. The use case '查某功能/某项目由谁在哪做过' further pins down what the tool is for and distinguishes it from the browsing-focused sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete when-to-use scenario: finding which agent did what and where. It implicitly contrasts with browsing-oriented siblings like inventory_overview or inventory_recent, though it does not explicitly name an alternative or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
技能库检索：本机所有技能的说明与路径（可按关键词筛）。想知道「有没有现成技能能做这件事」用它。
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | 关键词，可省 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It clearly discloses the read-only retrieval behavior and the returned content (descriptions and paths), but does not explain matching semantics, staleness of the index, or output formatting. Acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the action and result, followed by a clear use-case statement. Every sentence earns its place and there is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description adequately covers what it does, what it returns, and when to use it. It could be more complete by contrasting with inventory_search and noting whether the skill index depends on inventory_reindex.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the single optional query parameter (关键词，可省), and schema description coverage is 100%. The description merely paraphrases this as '可按关键词筛', adding no new semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (检索) on a clear resource (技能库) and describes the output: descriptions and paths of all local skills with optional keyword filtering. It does not explicitly distinguish itself from sibling inventory_search, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit, practical when-to-use cue: use it to check whether an existing skill can handle a task. It does not mention when not to use it or point to alternatives, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.5.3inventory_agentsinventory_indexinventory_overviewinventory_projectinventory_recentinventory_reindexinventory_searchinventory_skillsScored across 8 tools
Most tools target clearly distinct resources: agents, skills, projects, recent work, search, and reindexing. The only potential confusion is between inventory_overview and inventory_index, since both are presented as high-level entry points and both mention major project lists, though their descriptions do differentiate them.
All tools share a clean inventory_ prefix in lowercase snake_case, making the family instantly recognizable. However, suffixes mix mostly nouns (overview, project, agents) with an adjective (recent) and a verb (reindex), so there is not a single fully consistent pattern.
Eight tools is a well-scoped size for an inventory server: it covers overview, navigation, search, project details, agent rosters, recent activity, skills, and reindexing. Each tool has a clear purpose and none feel redundant or excessive.
The tool surface covers the stated inventory domain well: overview, search, projects, agents, skills, recent work, and refresh/reindex. The only noticeable gap is a dedicated MCP-service listing; MCP services are only reachable through overview counts or full-text search.
Find, compare, and audit software for AI agents. Scored registry of tools and MCP servers.
Live index of AI agents, MCP servers and tools with observed liveness and capability search.
A registry of AI agent tools — MCP servers, APIs, CLIs, SDKs — kept current by automated ingestion.
Search engine for AI agents to find MCP servers, A2A agents, and skills on their own.
