This server provides read-only access to code projects for browsing, reading, searching, and reviewing diffs.
List available code projects.
List repository code files with pagination and current/previous snapshot handles.
Read source files, optionally by line range, from current or previous code.
Search case-sensitive literal code text and get file paths and line locations.
Review the latest code changes against the preceding state, optionally limited to one file.
All exposed tools are read-only, non-destructive, and do not modify or run code.
Enables ChatGPT/OpenAI to read selected local code projects via MCP, exposing read-only tools for project listings, source reading, code search, and diffs.
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., "@Colink MCP show me what changed in my project since the last snapshot"
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.
macOS 安装包：0.5.0 Beta 8（0.5.0b8，build 39） · macOS 14+ · Apple Silicon · MIT
当前源码与公开安装包均对应 v0.5.0b8，包含统一源码读取与分析、Python / Java
值传播、TypeScript / JavaScript 结构关系、读取预算与符号定位修复，以及本机工作区管理。
发行细节和验证边界见发行说明。
Live 主要使用两个入口：read_code 定向读取文件、符号、搜索和少量显式文件，
analyze_code 查询关系、数据传播及任务 Diff，需要正文时可在同一次分析中附带。
已知文件可直接读取；跨文件理解先取得必要关系与源码证据。Live 完整工具集合为
40 个，含一个批量写入入口；八个被替代的旧入口已删除，更新后刷新连接工具。
历史 Mirror 保持原十五个只读工具与原有语义，详情见
入口说明。
查看和清理项目工作区：设置 → 存储位置 → 项目数据。每行显示一个完整本机工作区、
原目录、包含的项目和全部占用；关闭连接后可将整个工作区及登记移到废纸篓，
原目录不存在或没有索引时也可操作。清理后退出列表，重新选择源码目录可重建。
源码、全局连接配置与写入恢复库保留；具体范围和恢复方式见
本机工作区。升级前的正式 build 29 保留可安装回退包。
本版保留本机开发终端、固定数据库只读工具和局部代码索引更新，并更新源码分析与读取能力。 原生终端按当前 macOS 用户权限运行；可选隔离执行器目前只在已验证的 Darwin 27 上开放。 安装包声明最低 macOS 14；更新内容和验证边界见 Beta 8 发行说明。
CoLink 把你选定的本机项目接入 MCP。你可以在 ChatGPT 网页端询问项目结构、查找 函数、理解跨文件依赖；需要改代码时，在本机打开写入开关，让 AI 精准编辑、创建 或删除文件。默认只读，项目由你在本机确认。开发终端按当前系统用户权限运行， 项目选择决定初始目录，不构成文件系统或数据库隔离。
功能 | 你可以用它做什么 |
按需读取源码 | 一个入口读取文件、符号、搜索及少量显式范围；直接读取磁盘上已保存的文件 |
多项目管理 | 选择一个工作目录，分别启用其中的项目；在对话中指定项目 |
Python / Java 代码关系 | 联合查询类、调用、文件/模块关系与数据传播，可附带目标源码；引用、文件影响和全项目视图保留专用查询 |
精准写入 | 本机授权后按行插入、替换指定范围或唯一片段；修改前核对原文和文件哈希 |
批量写入 | 一次预检并提交最多二十笔显式编辑或创建，逐项保存恢复记录；执行中断明确报告已完成与待处理项 |
创建、移动与删除 | 创建文件和目录，在任务范围内移动源码与静态资源，删除明确指定的单个文件；不提供递归删除 |
任务 Diff | 查看同一任务跨多轮、跨文件的累计改动，不在普通问答里展示递增版本编号 |
网页开发终端 | 开发档直接运行本机命令、安装依赖与启动前后端，支持交互输入和输出；按当前 macOS 用户权限执行 |
环境与端口 | 查询本机实际工具版本、创建项目 Python 虚拟环境、查看监听与冲突；手动启动的本项目旧服务需本机确认后停止 |
数据库命令 | 只读档查看库表、结构和数据；开发档通过 mysql、psql、redis-cli、sqlite3 或驱动执行 CRUD、DDL 等账号允许的操作，无连接页和聊天卡片 |
存储位置 | 在齿轮设置内的折叠入口查看或更换本机运行数据目录；默认 |
本地 Git | 精确提交本任务选择的文件，保留用户原有暂存内容；首版不推送 |
菜单栏控制 | 启动、关闭、选择文件夹和管理项目；跟随系统深浅主题，不占 Dock 位置 |
可选自动匹配 Skill | 本机代码缺少上下文时优先读取；已经贴出足够代码时直接回答，无需每次手选技能 |
普通文本源码读取不限于 Python / Java；结构化关系分析目前重点支持这两种语言。 关系来自静态分析，动态调用、外部库内部实现等可能无法确定，工具会标明不确定项。 Skill 是否自动匹配由客户端决定，不保证每轮触发。
本版的结构索引按项目使用独立 SQLite，只保留当前一版；每项目磁盘上限 500 MiB，按需分配。最多同时打开 4 个项目索引，关闭连接后缓存保留在磁盘； 详细容量、关系复用与性能复测见 安装版索引修复。
Related MCP server: github-assistant-mcp
打开 0.5.0 Beta 8 下载页，
下载 Colink-macos-arm64.dmg，将 Colink.app 拖入“应用程序”，然后打开 CoLink。
也可以下载 ZIP 安装。
安装包已包含 Python、MCP 运行依赖和隧道客户端，不需要先安装开发环境。 目前支持 Apple Silicon Mac（M 系列芯片），macOS 14 或更新版本。 Beta 包尚未完成 Apple Developer ID 签名和公证，首次打开可能出现系统安全提示； 详情与文件校验方法见 安装指南。
在菜单栏面板完成“首次连接设置”，填写你自己的 Tunnel ID 和运行密钥，再在 ChatGPT 中添加对应的私有 MCP 连接。首次配置步骤见 连接指南。
连接通过出站私有隧道建立，不需要 VPS、路由器端口映射或本机公网入站端口。 你仍需要具有相应功能和权限的 ChatGPT / Platform 账号；安装软件不会自动获得这些权限。
先用自带样例确认连接可用，再选择自己的项目或工作目录。在“项目管理”中启用 要提供给 AI 的项目，点击“启动”。新发现的项目不会自动获得访问许可。
在新对话中可以这样问：
看看我已连接的项目有哪些。请只读取项目清单。
解释指定项目的入口函数，并查一下它依赖哪些文件。
找到这个 Python 类的定义、调用位置，以及修改它可能影响的模块。
主面板提供 只读 / 写入 / 开发 三档模式。需要修改时选择 写入，确认准确项目， 并明确告诉 AI 要改什么。关闭连接、退出或重启后，写入和运行权限都会关闭。更新旧版后，应在 ChatGPT 原连接页刷新工具并新建对话。写入使用方法见 读取与写入指南。
运行项目时选择 开发，为准确项目开启本机开发授权。网页可先查询环境和端口，
再通过 terminal_* 运行命令或数据库 CLI。终端以当前 macOS 用户权限运行，
项目 ID 决定授权入口和初始目录，并不隔离文件、网络或数据库。只读/写入档只有
固定数据库读取；本版没有数据库连接页、聊天卡片或逐库授权入口。
把下面这句话交给你已有的本机编码助手：
请按照 https://github.com/YuyanYYt/Colink/blob/main/docs/AGENT_INSTALL.md 帮我安装 CoLink，先检查系统、版本和校验值，再说明安装计划；保留现有配置， 由我自己完成登录、密钥输入和项目授权。
Agent 可以协助下载、校验和安装，但不能代替账号授权或绕过系统安全提示。 想减少日常手动选择，另见 自动匹配 Skill 的安装方法。
适合开发者、Linux 用户或使用本地 stdio MCP 客户端的用户。准备 Git、Python 3.11+ 和 uv，然后运行：
git clone https://github.com/YuyanYYt/Colink.git
cd Colink
uv sync --locked让支持 stdio 的 MCP 客户端在仓库目录启动以下命令，即可只读连接自带样例：
uv run colink live --root examples/sample_project --project sample \
--data-dir .code-context/live-sample这不是网页访问地址，不会自动配置 ChatGPT 或打开写入权限。 多项目、HTTP、旧镜像兼容入口和客户端配置见 命令行指南。
这里只列使用者能感受到的变化。开发阶段也保留在表中，不代表每个阶段都有独立安装包； 已发布包和对应源码可在 Releases 找到。
版本 | 主要变化 |
当前主分支源码、自包含 Live 模式 macOS 应用（build 39）、Skill 备用包及校验清单；见发行说明 | |
Python / Java 有界数据流、结构分析覆盖与限制诊断、可恢复批量写入与工作区管理；见发行说明。本期仅提供源码 | |
只读 / 写入 / 开发三档、原生终端、固定数据库只读、局部索引和自定义运行数据目录；见 发行说明 | |
0.5.0 Beta 4 · 维护源码 | 网页独立开发作业、原生隔离与有界存储、环境/端口/数据库引导、受控移动与本地 Git；公开发行状态和实际验收另行记录 |
0.5.0 Beta 2 · 公开发行 | 改善无 Git 项目发现和同名项目区分；发布直读、多项目及受控写入安装包；移除主动代码回退，代码历史交给项目 Git 管理 |
0.5.0 Beta 1 | 原文件按需直读、多项目授权、默认关闭的精准编辑与文件/目录创建、任务 Diff；后续源码补充单文件删除 |
0.4.3 · 开发阶段 | 修复自定义 Python 源码根的模块定位，支持显式源码根配置 |
0.4.2 · 开发阶段 | Python / Java 符号与关系查询；单文件上限提高到 4 MiB；品牌统一为 CoLink |
Diff 摘要、分页读取、连接状态检查、文件过滤与自动匹配 Skill | |
首个公开自包含 DMG / ZIP、首次连接设置、菜单栏运行和 Agent 安装指南 | |
0.3.3 | 项目与插件统一品牌；旧镜像只保留当前和前一次代码状态，取消面向用户的递增版本编号 |
0.3.2 | 插件名称统一，Logo 间距与中心对称优化 |
0.3.1 | 精简界面、平滑 Logo，支持从“应用程序”重新打开 |
0.3.0 | 原生 macOS 毛玻璃菜单栏界面，加入启动、关闭和选择文件夹 |
0.2.0 | 本机持续托管和私有隧道连接，无需另购服务器 |
0.1.0 | 初版源码读取、搜索、Diff、同步和 stdio / HTTP MCP |
完整记录见 CHANGELOG。更新应用请先关闭并退出旧版，保留原配置与数据； 历史版本可下载，但不保证能直接读取新版数据格式，详见 升级说明。
你决定可读范围。 只开放本机已确认的项目；不要直接共享个人主目录、系统目录或凭据目录。
私有连接不等于代码不出电脑。 被查询到的源码会发送给使用它的 AI 客户端及其服务提供方。
写入默认关闭。 本机许可和客户端工具确认相互独立；不会自动授予“全部权限”。
代码历史使用 Git。 当前版没有主动代码回退按钮；修改前保存重要稳定点，任务 Diff 不是 Git 历史。
运行独立授权。 首版非交互作业支持 Python、npm、Maven 和隔离 Shell；环境必须实际存在。Node 服务有 Unix socket 适配器，Python/JVM 服务需要相应接入，现有 Tomcat/Spring TCP 服务暂不能直接兼容。CPU、内存与进程数是监督软限制，原生保护不是虚拟机。
数据库需要实际验证。 工具存在、端口开放和进程启动都不代表业务成功；迁移、CRUD、重启后数据及向量检索分别验证。Qdrant 目前提供连接配置与引导，执行需项目范围认证，尚未启用。
存储有界，但不是零。 读取不保留完整源码镜像；结构索引、任务比较起点和中断保护仍占空间，并有容量限制。
过滤规则、隐私与写入边界见 SECURITY。
安装与升级 · 读取与写入 · Python / Java 代码关系 · 自动匹配 Skill · 技术架构 · 开发与贡献
欢迎通过 Issues 提交问题和功能建议。 请附系统、芯片、应用版本和复现步骤，不要上传运行密钥或私人源码。
CoLink 使用 MIT 许可证。这是每位用户独立运行的开源软件，不是共享维护者 账号的公共连接，也不代表已经上架 ChatGPT 公共插件目录。
维护者保留的固定恢复锚点：0.5.0b7 / build 33，本机标签为
anchor/colink-0.5.0b7-build33-before-cross-language-20261016T152045。
恢复前保留当前改动并检查运行数据兼容性，具体步骤和归档记录见
build 33 恢复说明。历史 build 19 材料保留；
这些维护者本机恢复材料不随公共源码发行分发。
Review the latest code changes against the preceding state; no numbered versions needed. Omit snapshot for current code or reuse its opaque handle. With only one initial state, compare against an empty project. Optional path limits the comparison to one file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ||
| snapshot | No | ||
| project_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description goes beyond that by disclosing two real behaviors: no version numbering is required, and a single-state project diffs against an empty project. It does not mention result format or size, but the output schema exists for that.
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?
Three sentences, front-loaded with the core purpose before the parameter conditions. Slightly dense and the phrase "no numbered versions needed" is a bit oblique, but no sentence is wasted.
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?
With an output schema present, return values need not be explained, and the description covers all three parameters plus the edge case of a single initial state. What remains missing is any indication of comparison scope limits or relationship to sibling tools.
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 0%, so the description must carry the parameters, and it does: snapshot is an opaque handle that can be omitted for current code, and path narrows the diff to one file. project_id is only implicitly covered, which is the one small gap.
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 ("Review the latest code changes against the preceding state"), which reads as a diff-retrieval operation and is distinguishable from read_file/search_code/repo_overview by its comparative scope. It never names a sibling explicitly, so differentiation is inferential rather than stated.
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 conditional usage for parameters ("Omit snapshot for current code", "With only one initial state, compare against an empty project"), which is real guidance, but it never says when to prefer get_diff over repo_overview or search_code. Usage is implied through parameter conditions rather than stated as a routing decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find available code projects. Context handles are internal, not user-facing labels.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds one genuinely useful piece of context — that context handles are internal identifiers rather than display labels — but says nothing about ordering, scope, or filtering behavior.
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 short sentences with no filler, and the core purpose is front-loaded. The second sentence is terse to the point of being cryptic, but it is not wasted.
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?
An output schema exists, so return values needn't be explained, and there are no parameters to document. Still, for a discovery tool sitting beside repo_overview, the description leaves the project-vs-repo relationship and the expected usage flow unstated.
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?
Zero parameters, so per the rubric the baseline is 4. The note that 'context handles are internal, not user-facing labels' is about output labeling rather than inputs, so it doesn't shift this dimension.
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 clear verb+resource: 'Find available code projects.' This is distinguishable from siblings like repo_overview, read_file, search_code, and get_diff, which all operate on code content rather than enumerating projects. However, it never clarifies how a 'project' relates to a 'repo' in this ecosystem.
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?
No guidance on when to call this versus siblings such as repo_overview, nor any prerequisites or ordering advice. The intent (discover projects before acting on them) is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read source to answer code questions; default 200, max 1000 lines. Omit snapshot for current code, use 'previous', or reuse repo_overview's opaque handle for consistent reads. Report code findings, not handles, hashes or synchronization metadata, unless requested.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| end_line | No | ||
| snapshot | No | ||
| project_id | Yes | ||
| start_line | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context: default 200 and max 1000 lines, snapshot consistency semantics, and output-reporting guidance ("report code findings, not handles, hashes..."). That is more than the annotations provide.
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?
Front-loads the purpose, then adds two compact clauses on snapshot semantics and reporting. Dense but every sentence carries information; minor awkwardness in the mid-clause aside, it is appropriately sized.
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?
An output schema exists, so return-value detail is unnecessary, and the description covers the non-obvious snapshot and line-limit behavior. Given the low schema coverage, project_id and path could be clarified, but an agent has enough 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 0%, so the description must carry the load. It explains snapshot values well and the default/max line count maps to start_line/end_line behavior, but path and project_id are left entirely undocumented. Partial compensation only.
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+resource ("Read source") and ties it to a goal ("answer code questions"), which distinguishes it from list_projects, search_code, and get_diff. It references repo_overview's handle, but does not otherwise differentiate itself from siblings that also surface code, so it falls 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?
Provides condition-based guidance for the snapshot parameter (omit for current, 'previous', or reuse a repo_overview handle), which is genuinely useful. However, it never states when to prefer read_file over search_code or get_diff, so usage relative to alternatives remains implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List code files. Omit snapshot for current code, use 'previous', or reuse an opaque handle. Pass the returned handle to follow-up reads; do not include it in the answer. Only current and previous code are retained. Expired handles require a fresh analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| snapshot | No | ||
| project_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuinely new behavioral context: retention is limited to current and previous code, handles expire and require a fresh analysis, and the handle must not appear in the answer. That lifecycle detail goes well beyond the annotations.
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?
Short, front-loaded, and every sentence carries information about the snapshot/handle lifecycle. The phrasing is terse to the point of being cryptic in places ("do not include it in the answer"), but there is no filler.
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?
An output schema exists, so return shape need not be described, and the description covers the tricky part (snapshot selection, handle reuse, expiry). Missing only pagination behavior for limit/offset and any hint of result size, which is minor given the output schema.
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 0%, so the description carries the burden, and it does explain the snapshot parameter's three modes and the handle contract thoroughly. But limit, offset, and project_id receive no explanation at all, leaving pagination semantics undocumented.
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+resource ("List code files"), so an agent knows the basic operation. However, it never distinguishes itself from siblings like read_file or search_code, and the name "repo_overview" suggests something broader than a file listing, leaving a small ambiguity about scope.
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 concrete guidance on the snapshot argument (omit for current code, use 'previous', or reuse a handle) and on passing handles to follow-up reads, which implies a workflow. But it never says when to choose this tool over read_file, search_code, or get_diff, so sibling selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Locate literal, case-sensitive code text with paths and lines. Omit snapshot for current code, use 'previous', or reuse an opaque handle. Keep handles out of the answer.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| snapshot | No | ||
| project_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description adds real behavioral detail on matching semantics (literal, case-sensitive) and the snapshot-handle lifecycle, including the caution to keep handles out of the answer. It stops short of describing result ordering or pagination behavior.
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 short sentences, front-loaded with the core behavior and no filler. The trailing 'Keep handles out of the answer' is terse and slightly ambiguous but earns its place as an operational caution.
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?
An output schema exists, so return values need no explanation here. With matching semantics, snapshot modes, and the safety profile covered by annotations, the definition is nearly sufficient; only limit/pagination behavior is unaddressed.
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 0%, so the description must carry the load. It does explain query semantics (literal, case-sensitive) and snapshot modes, but says nothing about limit or project_id, leaving two of four parameters undocumented anywhere.
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 resource ('Locate literal, case-sensitive code text') plus what is returned ('paths and lines'). It does not explicitly contrast itself with read_file or get_diff, but 'search' vs 'read' is a reasonably clear split for an agent.
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 snapshot guidance ('Omit snapshot for current code, use previous, or reuse an opaque handle') is useful mode-selection advice, but it is parameter usage rather than tool-selection guidance. There is no statement of when to prefer this over read_file or get_diff, so usage is only implied.
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.4.0get_difflist_projectsread_filerepo_overviewsearch_codeScored across 5 tools
Each tool targets a distinct action: listing projects, listing files, reading content, searching, and diffing. The four read tools share a 'snapshot'/opaque-handle mechanism but their core purposes (files vs. content vs. search vs. diff) remain clearly separable.
Four tools follow a verb_noun pattern (list_projects, read_file, search_code, get_diff). repo_overview breaks the pattern as a noun-first name, a minor deviation but still readable.
Five tools is a lean but well-scoped set for a read-only code exploration server. Each tool covers a distinct need without redundancy, though slightly thin overall.
Covers the core read-only lifecycle: discover projects, enumerate files, read content, search text, and view diffs. Minor gaps exist (e.g., no directory-level navigation or metadata/project-detail view), but agents can work around them.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Project memory, documentation and controlled secret access for AI coding agents.
Shared memory MCP server for Claude Code, Codex, Gemini CLI and Cursor. Cited, editable.
Read-only access to your CodeMouse accounts, repositories, and AI pull-request reviews.
