This server provides a comprehensive set of MCP tools mirroring OpenCode 1.18.9, usable by any MCP client (e.g., Codex, Claude Code). Capabilities include:
File Operations: Read files/directories with pagination and attachment support (images/PDFs), write files, perform contextual edits, and apply structured OpenCode patches for add/delete/update/move.
Search: Glob for filename patterns, grep for content with regex and file type filtering.
Shell: Execute shell commands (bash) with configurable working directory, timeout, and output handling.
Web: Fetch web page content in text/markdown/HTML, and search the web via Exa or Parallel.
Todos: Manage session-isolated task lists with status and priority.
Skills: Load specialized skill instructions from various sources.
Click on "Install 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., "@opencode_native_tools Find all TODO comments in the codebase"
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.
一个独立的 MCP stdio Server，把 OpenCode 1.18.9 的公开内置工具带给 Codex、Claude Code 和其他 MCP Code CLI。
它不启动、不调用、也不依赖本机 opencode CLI。
工具 | 用途 |
| 紧凑读取文件、目录、图片和 PDF；支持分页、截断、批量读取和二进制识别 |
| 文件搜索与紧凑内容搜索 |
| 写入、上下文编辑和 OpenCode patch |
| Shell 命令、超时、输出截断和进程树清理 |
| 网页读取，以及 Exa / Parallel 搜索 |
| 连接隔离、可持久化的待办列表 |
| OpenCode、Claude、项目和 URL Skill 发现 |
task、question、lsp、OpenCode UI ask、插件 hooks 和内部控制工具不包含在内，因为它们依赖 OpenCode 的交互界面、子代理、LSP 会话或插件运行时。
Related MCP server: codex-cli-mcp-tool
read 默认只返回带行号的正文；grep 默认返回 文件:行号:内容。两者不会再把正文复制到 preview 或 display.text。读取被截断时，正文末尾会给出 startLine、endLine、totalLines 和 nextOffset；受字节上限影响而无法确认总行数时，totalLines=unknown。
需要机器可读元数据时传入 responseFormat: "detailed"。此时 structuredContent 只包含分页或匹配统计字段，不会重复正文。readMany 最多读取 8 个文件，默认每个文件 200 行，整批输出最多 100 KB；单个文件失败会作为该文件的结果返回，不会中断其他文件。
需要 Node.js 20 或更高版本。选择以下任一种方式；通常推荐 方式 A，它启动更快且不依赖每次执行时下载包。
npm install -g opencode-native-tools-mcp在 Codex 配置文件中加入：
[mcp_servers.opencode_native_tools]
command = "opencode-native-tools"
args = []
startup_timeout_sec = 30.0默认情况下，服务使用 MCP Client 启动它时的工作目录作为项目根目录。
不需要先执行 npm install -g。在 Codex 配置文件中加入：
[mcp_servers.opencode_native_tools]
command = "npx"
args = ["-y", "opencode-native-tools-mcp@latest"]
startup_timeout_sec = 30.0安装 MCP 后，建议执行一次配置器，让 Codex 自动优先使用本服务进行读取和搜索：
opencode-native-tools apply
opencode-native-tools status如果使用的是本节的 npx 方式，执行 npx -y opencode-native-tools-mcp@latest apply。apply 会保留已有 MCP 的 command 和 args，并更新全局 AGENTS.md 中的标记块。它不会把本 MCP 加入 direct_only_tool_namespaces：文件修改必须交给 Codex 原生的 write / edit / apply_patch，这样 Codex 才能显示文件修改 Diff。完成后重启 Codex 或新建 task。需要撤销自动规则时执行 opencode-native-tools unapply。
默认情况下，服务使用 MCP Client 启动它时的工作目录作为项目根目录。
如果需要固定操作某个项目，再额外添加：
[mcp_servers.opencode_native_tools.env]
OPENCODE_TOOLS_ROOT = "D:/path/to/your-project"Windows 的全局 Codex 配置文件通常是：
C:\Users\<你的用户名>\.codex\config.toml保存后重启 Codex Desktop，或新建一个 task，让 Codex 重新读取 MCP 配置。
在终端执行：
codex mcp list应该能看到：
opencode_native_tools ... enabled然后在新的 Codex task 中输入：
使用 opencode_native_tools 的 glob 查找 package.json，再用 read 读取它。Codex 应调用 read、glob、grep、write、edit、apply_patch、bash 等同名 MCP 工具。
OPENCODE_TOOLS_ROOT 用于固定该 MCP 默认操作的项目目录。未设置时，服务使用 MCP Client 启动时的工作目录；只有在全局配置需要固定到某个仓库时，才需要设置它。
如果不设置它，服务会使用 Codex 启动 MCP 进程时的工作目录。
OpenCode 的 ask 是其自身 UI 的交互能力，通用 MCP Server 无法复刻。文件修改和 shell 命令的批准应由 Codex 在调用前负责。
推荐为有副作用的工具要求批准：
[mcp_servers.opencode_native_tools.tools.write]
approval_mode = "approve"
[mcp_servers.opencode_native_tools.tools.edit]
approval_mode = "approve"
[mcp_servers.opencode_native_tools.tools.apply_patch]
approval_mode = "approve"
[mcp_servers.opencode_native_tools.tools.bash]
approval_mode = "approve"可以禁用不希望 Codex 使用的工具：
[mcp_servers.opencode_native_tools]
disabled_tools = ["bash", "webfetch", "websearch"]或者只保留白名单中的工具：
[mcp_servers.opencode_native_tools]
enabled_tools = ["read", "glob", "grep", "write", "edit", "apply_patch"]这些是 Codex 的 MCP 配置，只影响 Codex；其他 MCP Client 仍会看到服务公开的完整工具列表。
apply_patch 的目标路径位于 patchText 中。宿主应在调用前解析 *** Add File、*** Update File、*** Delete File 和 *** Move to，并按自身策略批准工作区外访问。结果中的 metadata.externalPaths 用于审计，不能替代调用前批准。
服务会在 MCP 初始化时声明对文件读取和搜索的工具偏好。文件修改使用 Codex 原生工具，以便 Codex 记录并显示文件 Diff。要让 Codex 在项目中更稳定地优先使用本 MCP，可以在目标仓库根目录放置 AGENTS.md。
仓库提供了可直接使用的模板：templates/AGENTS.md。它要求 Codex 使用 opencode_native_tools 进行读取和搜索，并使用 Codex 原生编辑工具修改文件，以保留 Codex 的 Diff 展示。
glob 和 grep 优先使用系统 PATH 中的 rg。找不到时，服务会下载兼容版本的 ripgrep 并写入自己的缓存；普通用户通常不需要手动安装 rg。离线或受限网络环境可以自行安装 ripgrep，或设置：
OPENCODE_TOOLS_RG_PATH=/path/to/rgWindows 下服务会按 PATH 优先级查找 rg.exe，但会跳过 Codex Desktop WindowsApps 中不可由 MCP 启动的内置副本。其他候选和缓存副本会在服务首次使用时验证一次可执行性；成功路径会在进程内缓存，后续 glob 和 grep 不产生额外探测开销。
没有可用的 ripgrep 时，服务会下载并验证自己的缓存版本。受限网络环境可通过 OPENCODE_TOOLS_RG_PATH 指定允许启动的 rg.exe 绝对路径。
websearch 是可选工具。要启用它，在 MCP 的 env 中提供一个 provider 的 key：
[mcp_servers.opencode_native_tools.env]
EXA_API_KEY = "..."
# 或 PARALLEL_API_KEY = "..."可通过 OPENCODE_WEBSEARCH_PROVIDER = "exa" 或 "parallel" 固定 provider。Parallel 还可设置 OPENCODE_TOOLS_MODEL_NAME。
服务会读取兼容的 OpenCode JSON / JSONC 配置数据，但不会加载 OpenCode runtime、插件或 hooks。支持以下配置来源：
OPENCODE_CONFIG
OPENCODE_CONFIG_CONTENT
OPENCODE_CONFIG_DIR
OPENCODE_DISABLE_PROJECT_CONFIG
兼容 shell、tool_output、formatter、skills 和 websearch runtime flags。Windows 默认按 pwsh、powershell、Git Bash、cmd 选择 shell；OPENCODE_TOOLS_SHELL 和 OPENCODE_GIT_BASH_PATH 可覆盖。
默认不会格式化文件。要在 write、edit、apply_patch 后启用 formatter，在项目的 opencode.json 或 opencode.jsonc 中设置：
{
"formatter": true
}本实现以 OpenCode 1.18.9 为固定对照基线。以下差异是通用 MCP 协议限制或有意保留的独立实现选择：
宿主 Code CLI 负责批准；不提供 OpenCode UI ask。
LSP diagnostics、watcher 和 OpenCode event bus 未迁移。
标准 MCP content / structuredContent 是对 OpenCode 内部 Tool result 的协议适配。
apply_patch 会先计算全部变更，再原子提交；OpenCode 原实现为审批后按顺序应用。
ripgrep、formatter、URL skills 和 shell 输出使用本服务的独立缓存，不与 OpenCode 全局缓存共享。
Apply an OpenCode patch document. Wrap one or more file operations in *** Begin Patch and *** End Patch. Use *** Add File, *** Delete File, or *** Update File headers. New lines in an added file must begin with +. Updates may include a *** Move to: path directive.
| Name | Required | Description | Default |
|---|---|---|---|
| patchText | Yes | The full patch text that describes all changes to be made |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavior. It discloses critical format constraints: the required '*** Begin Patch' and '*** End Patch' markers, allowed headers, the '+' prefix for new file lines, and the optional '*** Move to:' directive. This goes beyond surface description and helps avoid malformed patches, though it does not address error handling or atomicity.
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 only three sentences long but packs essential instructions. It starts with the primary purpose and then lists the required formatting elements without any fluff. Every sentence 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 single-parameter tool with no output schema, the description covers the core usage well: it explains what to pass and how to structure it. It could be enhanced by mentioning what constitutes a valid patch (e.g., the need for at least one operation) or what happens on invalid input, but these are not critical for basic invocation. Overall, it is sufficiently complete.
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 only describes patchText as 'full patch text', which is generic. The tool description provides essential semantics by specifying the exact patch syntax expected, including structure and examples of headers. This adds significant meaning beyond the schema and is crucial for correct invocation.
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 'Apply an OpenCode patch document', which is a specific verb+resource. It also provides details on the patch format (Begin/End markers, headers), distinguishing it from sibling tools like write and edit that operate on single files directly.
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 explains the mechanics of creating a patch but does not explicitly state when to prefer apply_patch over write/edit. The phrase 'one or more file operations' implies batch use, but no direct comparison or exclusion criteria are given. Usage context is implied rather than explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a shell command. Set workdir instead of changing directories inside the command when possible. timeout is in milliseconds. Output is capped; complete truncated output is saved to a file.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The command to execute | |
| timeout | No | Optional timeout in milliseconds | |
| workdir | No | The working directory to run the command in. Defaults to the current directory. Use this instead of 'cd' commands. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does reveal that 'Output is capped; complete truncated output is saved to a file,' which is useful. But it does not mention exit codes, error handling, or potential side effects of running arbitrary commands, leaving some gaps.
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 three concise sentences, each earning its place: purpose, usage guidance, and a behavioral note. No wasted words or repetition of schema details.
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 no output schema and straightforward parameters, the description covers key points: execution, timeout units, and output handling. However, it omits details about command compatibility (e.g., shell used) or error behavior, which could be relevant but are not strictly required given the simple 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?
The schema description coverage is 100% since all parameters have descriptions. The tool description adds a bit of value by reinforcing the unit for timeout and advising against 'cd' commands, but these are largely redundant with schema text. The additional guidance on workdir is helpful but not enough to exceed 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?
The description clearly states 'Execute a shell command' with a specific verb and resource. It is unambiguous and distinguishes this tool from siblings like file operations or web searches which have different purposes.
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 clear practical guidance: 'Set workdir instead of changing directories inside the command when possible' and specifies that timeout is in milliseconds. However, it does not explicitly discuss when to prefer bash over sibling tools or exclude scenarios, though the context implies bash is for running shell commands.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace text in a file using OpenCode matching semantics. Preserve the exact indentation from read output, excluding its line-number prefix. The operation fails when oldString cannot be identified unambiguously; supply more context or use replaceAll to replace every occurrence.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | The absolute path to the file to modify | |
| newString | Yes | The text to replace it with (must be different from oldString) | |
| oldString | Yes | The text to replace | |
| replaceAll | No | Replace all occurrences of oldString (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains OpenCode matching semantics, the need to preserve indentation, the failure condition when oldString is ambiguous, and the replaceAll fallback. This is substantial behavioral information, though it does not cover permissions or side effects of the edit operation.
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 sentences long, front-loaded with the core purpose, and every sentence earns its place. It is concise, structured, and free of fluff.
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 file-edit tool with no annotations and no output schema, the description covers the essential behavior: matching semantics, indentation handling, failure conditions, and disambiguation. It does not mention return values or when to prefer this over apply_patch/write, but it is adequate for typical use.
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 provides descriptions for all four parameters, giving 100% schema coverage. The description adds a bit of context by noting the matching semantics (which impacts oldString) and the replaceAll fallback, but it does not significantly enhance the parameter-level understanding beyond the schema.
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 function with a specific verb and resource: 'Replace text in a file using OpenCode matching semantics.' This makes the purpose clear, but it does not explicitly differentiate from sibling tools like apply_patch or write, so it lacks the full points for sibling differentiation.
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 concrete usage guidance: 'Preserve the exact indentation from read output, excluding its line-number prefix' and explains how to handle ambiguity: 'supply more context or use replaceAll to replace every occurrence.' This gives clear context on successful operation, though it does not mention when to use this tool versus alternatives like apply_patch or write.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast file pattern matching for codebases of any size. Supports patterns such as /*.js and src//*.ts. Returns matching file paths. Use it to find files by name pattern.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | The directory to search in. If omitted, the current working directory is used. Must be a valid directory path when provided. | |
| pattern | Yes | The glob pattern to match files against |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool is 'Fast' and 'Returns matching file paths,' implying a read-only search. But it doesn't disclose edge-case behaviors like hidden file handling, case sensitivity, or behavior on unmatched patterns. For a simple read-only tool, this is adequate 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?
The description is four short sentences, each serving a purpose: purpose, examples, return value, and usage. It is front-loaded with the core function and contains no fluff or 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 simple two-parameter tool with no output schema, the description adequately covers purpose, usage, and return value. It lacks edge-case details (e.g., empty results) but is sufficiently complete for an agent to select and invoke the tool correctly. Sibling context makes the distinction from grep clear.
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 coverage is 100%, providing baseline 3. The description adds value with pattern examples ('**/*.js', 'src/**/*.ts'), illustrating the accepted syntax beyond the schema's generic 'glob pattern' description. This pushes it to a 4.
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 performs 'file pattern matching' and explicitly says it 'Returns matching file paths.' It distinguishes from siblings like grep (content search) and read (file reading) by focusing on finding files by name pattern, with concrete examples (**/*.js, src/**/*.ts).
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 explicit usage guidance: 'Use it to find files by name pattern.' Avoids ambiguity about its purpose. However, it does not mention alternatives or exclusions (e.g., when to prefer grep for content search), which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast regular-expression content search for codebases of any size. The optional include parameter filters searched files, for example *.js or *.{ts,tsx}. Returns matching paths, line numbers, and matching lines.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | The directory to search in. Defaults to the current working directory. | |
| include | No | File pattern to include in the search (e.g. "*.js", "*.{ts,tsx}") | |
| pattern | Yes | The regex pattern to search for in file contents |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals return format (paths, line numbers, matching lines), performance ('fast'), and the filtering behavior of the include parameter. It omits details like case-sensitivity and .gitignore handling, but offers meaningful transparency for a grep-like tool.
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 three sentences with no redundant phrasing. Purpose is front-loaded, and each sentence contributes distinct information: core function, include filter example, and return value characteristics.
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 full schema parameter descriptions and no output schema, the description covers purpose, filtering, and output. It lacks edge-case behavior (e.g., binary files, symbolic links), but these are not typically critical for grep usage. Overall, the description is adequately complete for an agent to invoke 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?
The schema already provides descriptions for all three parameters (100% coverage), so baseline is 3. The description adds value beyond the schema by giving concrete examples for the include parameter ('*.js', '*.{ts,tsx}'), which clarifies the expected format more precisely than the schema's 'File pattern to include'.
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 it performs 'Fast regular-expression content search for codebases', specifying a clear verb, resource, and method. This distinguishes it from sibling tools like glob (which likely handles filename patterns) by focusing on content matching.
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 conveys clear usage context (regex content search) and gives an example of the include parameter, but does not explicitly name alternatives or say when NOT to use the tool. It implies when to use it based on the 'content search' phrasing, which is sufficient for typical cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a file or directory from the local filesystem. The filePath should be absolute. By default, returns up to 2000 lines starting at line 1. Use offset (1-indexed) and limit to read later sections. Lines are returned as : ; directories list entries with a trailing / for subdirectories. Lines longer than 2000 characters are truncated. Images and PDFs are returned as attachments.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | The maximum number of lines to read (defaults to 2000) | |
| offset | No | The line number to start reading from (1-indexed) | |
| filePath | Yes | The absolute path to the file or directory to read |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral burden. It discloses default line limits, offset/limit behavior, line formatting, truncation, directory listing format, and attachment handling for images/PDFs—all beyond what the schema provides.
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 concise and every sentence adds value. It is well-structured, covering purpose, usage, output format, and edge cases in a compact set of sentences 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?
Since there is no output schema, the description adequately explains return values and formatting. It covers common edge cases like line limits, long lines, directories, and binary attachments, making it complete for an agent to use the tool 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 coverage is 100%, so parameters are already documented. The description adds meaningful context: absolute path requirement, 1-indexed offset, default line count, line formatting, and directory trailing slash behavior, which enriches the agent's understanding beyond schema descriptions.
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 it reads a file or directory from the local filesystem, which is a specific verb+resource. It distinguishes itself from sibling tools like glob, grep, write, and edit by focusing on reading local content, and from webfetch by specifying local filesystem.
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 clear context: reading local files/directories, requiring absolute paths, and using offset/limit for large files. It does not explicitly name alternatives or exclusion criteria, but the context is sufficiently clear to avoid confusion with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a discovered specialized skill. The output contains the skill instructions and references to files in the skill directory. The name must match a discovered skill.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Skill name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It helpfully states that the output contains skill instructions and file references, which is useful since there is no output schema. However, it does not mention side effects, read-only nature, or error behavior for invalid names, leaving some gaps.
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 consists of three sentences, each earning its place: purpose, output content, and name constraint. It is front-loaded with the primary action and contains no fluff or 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 simple one-parameter tool with no output schema, the description covers the essential aspects: what it does, what the output contains, and the name constraint. It does not discuss error handling or prerequisite discovery steps, but these are minor for a loading tool.
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 describes 'name' simply as 'Skill name', which is tautological. The description adds the crucial constraint that the name must match a discovered skill, providing meaningful semantics beyond the schema. This exceeds the baseline for high schema coverage.
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 starts with a specific verb 'Load' and a resource 'discovered specialized skill', clearly distinguishing it from sibling tools like file operations or web searches. The mention of 'discovered' further refines the tool's unique role.
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 clearly implies the context: use this when you need to load a discovered skill. It states the prerequisite that the name must match a discovered skill, but does not explicitly name alternatives or exclusions. Given the sibling tools, the use case is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create and maintain the structured task list for the current MCP session. Each item has content, status, and priority.
| Name | Required | Description | Default |
|---|---|---|---|
| todos | Yes | The updated todo list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions session scoping but does not disclose whether the tool replaces the entire list or merges, whether it is destructive, or what the return value is. For a write tool, these are significant gaps.
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 short and front-loaded with the action. The first sentence is essential, but the second sentence merely restates what the schema already says, making it somewhat redundant. Overall, it is concise and easy to parse.
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 a single parameter and no output schema, the description provides the core purpose and item structure. However, it lacks clarity on how the list is maintained (whether the whole list is replaced or merged), which is important for correct usage. It is minimally complete but has gaps.
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 fully documents the 'todos' parameter with descriptions for content, status, and priority (100% coverage). The description only repeats that items have content, status, and priority, adding no additional semantics or examples beyond the schema.
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 a specific verb ('Create and maintain') and a specific resource ('structured task list for the current MCP session'). It distinguishes the tool from all siblings, which are unrelated (file ops, shell, web). This fully clarifies what the tool does.
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 implies usage for managing a session-scoped todo list, but does not explicitly state when to use it versus alternatives or when not to use it. Since sibling tools are unrelated, there is low ambiguity, but explicit guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch content from a fully formed HTTP or HTTPS URL. format controls whether text, Markdown, or HTML is returned; Markdown is the default. This tool is read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL | |
| format | No | The format to return the content in (text, markdown, or html). Defaults to markdown. | markdown |
| timeout | No | Optional timeout in seconds (max 120) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though no annotations are provided, the description states 'This tool is read-only,' which is a critical safety trait. It also discloses that format controls the output type and the default behavior (Markdown). This provides meaningful behavioral context beyond the schema.
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 sentences, front-loaded with the core purpose, followed by the key format detail and read-only safety note. Every word earns its place with no unnecessary 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?
For a simple fetch tool with 3 parameters and no output schema, the description adequately explains what the tool returns (formatted content) and its read-only nature. It doesn't cover error handling or redirects, but these are not essential for a basic fetch operation.
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 coverage is 100%, so the baseline is 3. The description mentions 'format' and its default, but this is redundant with the schema description. It adds no additional meaning beyond what the schema already provides for url or timeout.
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 uses the specific verb 'Fetch content' and clearly identifies the resource as 'a fully formed HTTP or HTTPS URL'. This distinguishes it from sibling tools like 'read' (file reading) and 'websearch' (web search), making the purpose unambiguous.
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 implies clear usage: use it when you have a complete HTTP/HTTPS URL. It also restricts to fully formed URLs, excluding relative or non-HTTP URLs. However, it does not explicitly mention alternatives or when not to use the tool, so it doesn't earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web through the configured Exa or Parallel provider. Query is required; numResults, livecrawl, type, and contextMaxCharacters are optional provider controls.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| query | Yes | Query | |
| livecrawl | No | ||
| numResults | No | Results | |
| contextMaxCharacters | No | Context limit |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It does not describe the return format, whether results include content or just URLs, rate limits, or how provider controls affect behavior. For a web search tool, this leaves important operational details undisclosed.
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 well-structured sentence that front-loads the core purpose, then lists required vs. optional parameters. No word is wasted, and it is easy to scan.
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 there is no output schema and no annotations, the description should explain what the tool returns and how the optional controls affect behavior. It only covers the basic invocation pattern, leaving significant gaps for an agent deciding whether and how to use the tool.
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 coverage is 60%, and the description only groups parameters as 'optional provider controls' without explaining their semantics. The enums for 'type' and 'livecrawl' are particularly ambiguous, and the description does not clarify what values like 'fast' or 'preferred' mean. It adds little beyond the schema's terse field descriptions.
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: 'Search the web through the configured Exa or Parallel provider.' This is a specific verb+resource pairing that distinguishes websearch from sibling tools like webfetch, which likely fetches a specific URL.
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 clear context for using the tool ('Search the web') and states that query is required while listing optional parameters. However, it does not explicitly mention when to use websearch over webfetch or other alternatives, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a text file to the local filesystem. An existing file is overwritten. Prefer edit for an existing file when a targeted replacement is sufficient.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The content to write to the file | |
| filePath | Yes | The absolute path to the file to write |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It clearly states that an existing file is overwritten, which is the key destructive side effect. It does not mention auxiliary details like permission requirements or return values, but the core behavioral trait is well covered.
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 compact two-sentence structure with no wasted words. The first sentence states the core function, the second adds important behavioral and usage guidance, making every word earn 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?
Given the tool's low complexity and complete schema, the description is nearly sufficient. It covers the primary operation, the overwrite behavior, and the alternative tool. It does not describe return values, but for a write operation this omission is minor and not required by the guidelines when no output schema exists.
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 fully describes both parameters (filePath and content) with clear descriptions and 100% coverage. The tool description adds no new parameter-level detail, but it does not need to since the schema is self-sufficient. Baseline 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 writes a text file to the local filesystem, using a specific verb and resource. It also distinguishes itself from the sibling 'edit' tool by noting when write is preferred, making the purpose unambiguous.
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 explicitly tells the agent to prefer 'edit' for existing files when a targeted replacement is sufficient, providing a clear when-not-to-use condition and naming an alternative. This goes beyond simple context to give actionable guidance.
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. Dates show when Glama detected each change.
v0.1.3apply_patchbasheditglobgrepreadskilltodowritewebfetchwebsearchwriteMost tools have clearly distinct purposes: read vs. write vs. edit are separated by whole-file vs. targeted replacement, and webfetch vs. websearch are cleanly split. However, write, edit, apply_patch, and bash all touch file modification, which could cause occasional misselection.
Names use a mix of single verbs (read, write, edit, glob, grep), compound words (webfetch, websearch, todowrite), a proper command (bash), and one underscored verb_noun (apply_patch). This is readable but lacks a uniform pattern.
With 11 tools, the set is well-scoped for a coding assistant: it covers file operations, search, shell execution, web access, task tracking, and skill loading without being bloated or sparse.
The file lifecycle is complete (create via write, read, update via edit/apply_patch, delete/move via apply_patch), and search, shell, web, task management, and skill loading cover the expected capabilities for a native tool server. No obvious critical gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
An MCP server that gives your AI access to the source code and docs of all public github repos
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ShiYioo/opencode_native_tools'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
