ローカルで動作するオープンソースのMCPサーバー + エージェントスキル。最新リリースの公式Zigドキュメントを常に新鮮な状態で提供し、厳選した高性能軽量ソフトウェアのガイダンスコーパス、そして古くなったローカルZigツールチェーンを対象とした安全なドライラン優先の自動アップデートを備えています。
zig-docs-mcp
├── zigdocs MCP server (stdio, local, no accounts)
├── guidance/ curated performance guidance (12 topics)
├── skills/zig-docs agent skill: operating rules for Zig work
└── skills/zig-docs-mcp agent skill: Python integration (`zdoc` singleton)Zigは変化が速く、学習記憶に基づく回答はマイナーリリースの間で陳腐化します。0.16はI/Oレイヤー全体を置き換え、Dir を std.fs から std.Io に移動させました。このサーバーは呼び出しのたびに公式ドキュメントとリリース済みstdソースを取得するため（短いTTLによる再検証）、すべての回答がどのバージョンに由来するかを明示します。ローカルのコンパイラがドキュメントより古い場合、サーバーはそのことを伝え、確認ゲート付きのアップグレードを提案します。明示的な確認なしにシステムを変更することはありません。
Related MCP server: Zignet
ドキュメントは急速に陳腐化します。 Zigのstdライブラリ構成はマイナーリリース間で変わります。最新リリースの実際のソースを提供することだけが、APIの真実の唯一の情報源です。zig_std は、リリース済みツリー内の実際の再エクスポートを辿ってシンボルを解決します。スクレイピングしたスナップショットではありません。
パフォーマンスの助言は機械的であるべきです。 同梱のコーパスは、アロケーション戦略、データレイアウト、comptime、バイナリサイズ、起動レイテンシ、SIMD、並行性、ベンチマークについて、感覚ではなくハードウェアとランタイムが実際にどう動作するか（キャッシュライン、システムコール、ページフォールト）に基づいて説明します。
古いコンパイラは静かにすべてを無効化します。 zig_version_status はチェックのたびにツールチェーンをアップストリームのインデックスと比較し、zig_update は具体的でレビュー可能なアップグレード計画を提示します。
すべてがローカルファーストです。 サーバーはstdioでお使いのマシン上で実行されます。アカウントもトークンもテレメトリもありません。ネットワークは、ドキュメント、リリースノート、ソースtarballを取得するためだけにziglang.orgへ接続します。
キャッシュされたレスポンスは、6時間より古くなると ziglang.org に対して再検証 されます（force=true で即時再検証）。再検証は条件付きGET（ETag / Last-Modified）を使うため、コストは低いです。
オフライン対応：ネットワークがダウンしている場合、失敗する代わりにキャッシュされたコンテンツが stale フラグ付きで提供されます。（初回実行時だけネットワークが一度必要です。）
stdソースは 公式のリリース別 src tarball から取得します。これは、GitHubのリリースタグが遅れている場合でも正規の内容です（これを構築した時点では0.16.0はGitHubにタグがありませんでした）。tarballはバージョンごとに一度だけダウンロードされ、lib/std/** のみが展開されます。
channel パラメータで stable（デフォルト、最新リリース）または master（ナイトリービルド）を選択できるため、次期リリースの変更をプレビューできます。
キャッシュレイアウト（~/.cache/zig-docs-mcp/、ZIG_DOCS_MCP_CACHE で上書き可能）：
~/.cache/zig-docs-mcp/
├── http/ upstream bodies + ETag/Last-Modified metadata
├── langref-0.16.0.json parsed reference sections (per version)
├── notes-0.16.0.json release-notes digest
├── zig-0.16.0-src.tar.xz source tarball cache
└── src/0.16.0/lib/std/ extracted std sources (550 files)Python ≥ 3.10 と uv
macOS または Linux（自動アップデートはHomebrewとスタンドアロンインストールをサポート。Windowsは動作する計画の出力のみで、tarball戦略はまだありません）
ziglang.org へのネットワークアクセス（初回取得と再検証のため）
git clone https://github.com/gbrlpzz/zig-docs-mcp
cd zig-docs-mcp
uv tool install . # installs the `zigdocs` command on your PATH
zigdocs --help # verifyインストールしたくない？ クローンから直接実行できます：
uv run --project ~/zig-docs-mcp zigdocsstdioに対応した任意のMCPクライアント。zigdocs コマンドを指定してください：
{
"mcpServers": {
"zig-docs": {
"command": "zigdocs"
}
}
}グローバルインストールなしで、クローンを直接使用する場合：
{
"mcpServers": {
"zig-docs": {
"command": "uv",
"args": ["run", "--project", "/path/to/zig-docs-mcp", "zigdocs"]
}
}
}このリポジトリには2つのスキルが同梱されています。シンボリックリンクを作成してセッションを再起動（または /reload を実行）してください：
ln -sfn ~/zig-docs-mcp/skills/zig-docs ~/.agents/skills/zig-docs
ln -sfn ~/zig-docs-mcp/skills/zig-docs-mcp ~/.agents/skills/zig-docs-mcp次に、エージェントカーネルから：
from zig_docs_mcp import zdoc
await zdoc.zig_version_status() # local vs latest upstream
await zdoc.zig_update() # dry-run upgrade plan
await zdoc.zig_update(dry_run=False, confirm=True) # apply after user agrees
await zdoc.zig_langref(section="Errors") # fresh language reference
await zdoc.zig_std(symbol="std.heap.ArenaAllocator") # std docs from released source
await zdoc.zig_changelog() # what changed in the release
await zdoc.perf_guidance(topic="allocation-strategy") # curated guidance
await zdoc.zig_search(query="vectorization") # search everything at once呼び出しは結果をJSON文字列として返します（トピック全体のガイダンス読み取りは生のMarkdownを返します）。version や docs などのフィールドが必要な場合は json.loads(...) で解析してください。引数はキーワード専用です。サーバーコマンドは次の順序で解決されます：ZIG_DOCS_MCP_CMD、PATH上のzigdocs、次に ZIG_DOCS_MCP_REPO（デフォルト ~/zig-docs-mcp）に対する uv run --project。
skills/zig-docs/SKILL.md には、エージェントが従う運用ルールが含まれています：まずバージョン確認、コードよりドキュメント、ドキュメントのバージョンを引用、そしてユーザーの明示的な承諾なしにアップデートを適用しない。
zig_version_statusローカルの zig version を最新のアップストリームリリースと比較します。
{
"local_version": "0.16.0",
"local_path": "/opt/homebrew/bin/zig",
"latest_stable": "0.16.0",
"master": "0.17.0-dev.1818+7051f8e73",
"up_to_date": true
}ローカルツールチェーンが古い場合、レスポンスには behind と、zig_update を指す suggestion が追加されます（例示）：
{
"local_version": "0.15.2",
"latest_stable": "0.16.0",
"up_to_date": false,
"behind": "local 0.15.2 < latest 0.16.0",
"suggestion": "Call the zig_update tool (dry-run first) to upgrade the local toolchain to the latest stable release."
}zig_updateローカルツールチェーンをアップグレードします。デフォルトはドライラン で、正確な計画を出力するだけで何も変更しません。適用するには dry_run=false, confirm=true が必要です。ツールチェーンの自動アップデート を参照してください。
zig_langref公式言語リファレンス。チャネルバージョン用に毎回取得します。
section="Errors" → セクション全文（コードブロックは保持）：
### Error Set Type
An error set is like an enum. However, each error name across the entire
compilation gets assigned an unsigned integer greater than 0. ...query="vector" → 関連度順のセクションヒット：
[{"section_id": "Vectors", "title": "Vectors§"},
{"section_id": "Builtin-Functions", "title": "Builtin Functions§"}]引数なし → すべてのセクションIDのリスト。
zig_std正確なリリース済みソース からの標準ライブラリドキュメント。シンボル解決は実際の再エクスポート（std.zig → heap.zig → heap/ArenaAllocator.zig）を辿り、@import エイリアスを追跡し、そのリリースの /// ドキュメントと宣言テキストを返します：
{
"symbol": "std.ArrayList",
"version_source": "0.16.0",
"file": "lib/std/std.zig",
"line": 49,
"declaration": "pub fn ArrayList(comptime T: type) type {\n return array_list.Aligned(T, null);\n}",
"docs": "A contiguous, growable list of items in memory. This is a wrapper around a\nslice of `T` values. ..."
}名前が辿った名前空間内の単純なトップレベル宣言でない場合（レイアウトはリリース間で移動します）、ツールはコーパス全体のトップレベル宣言検索にフォールバックし、最適な一致から順に返します。例えば、0.16の std.fs.Dir は、正しく lib/std/Io/Dir.zig を表示します。query="arena" はstdのドキュメントコメントを直接検索します。
zig_changelog現在のチャネルバージョンのリリースノートダイジェスト：各セクションのタイトルと短い要約。リリース直後に便利です（zig_changelog(force=true)）。
perf_guidance高性能・軽量ソフトウェアのための厳選されたガイダンス。引数なしでトピックを一覧表示し、topic="allocation-strategy" で完全なガイドを返します（原則 / 仕組み / Zigのイディオム / アンチパターン / 経験則 を含む生のMarkdown）。query=... はすべてのガイドを横断検索します。
zig_searchlangref、stdのドキュメントコメント、ガイダンスにわたる統合検索：
{"query": "vectorization", "langref": [...], "guidance": [...], "std": [...], "std_version": "0.16.0"}scope で絞り込めます：all（デフォルト）| langref | std | guidance。
zig_update は戦略を自動的に選択します：
Homebrew管理のzig（バイナリがbrewプレフィックス内に解決される）→ brew upgrade zig：
{
"mode": "dry-run (nothing changed). Re-run with confirm=true to apply.",
"target_version": "0.16.0",
"current": "0.16.0",
"strategy": "homebrew",
"command": ["brew", "upgrade", "zig"],
"note": "Homebrew formula may lag the newest release slightly."
}スタンドアロンインストール（公式tarball、その他の場所）→ アップストリームのインデックスからプラットフォーム用tarballをダウンロードし、~/.local/opt/zig-<version> に展開して、~/.local/bin/zig にシムを作成します：
{
"strategy": "standalone-tarball",
"download": "https://ziglang.org/download/0.16.0/zig-aarch64-macos-0.16.0.tar.xz",
"install_dir": "~/.local/opt/zig-0.16.0",
"steps": ["download ...", "extract ...", "symlink ~/.local/bin/zig -> .../zig/zig"],
"activation": "~/.local/bin is first on PATH; new zig takes effect immediately"
}~/.local/bin がPATHの先頭に ない 場合、計画はそのことを明示します。古いコンパイラが優先されるため、ツールは順序を修正する方法を伝えます。
安全ルール：
デフォルトはドライランです。何もダウンロード、移動、リンクされません。
適用には dry_run=false, confirm=true の両方が必要です。
このサーバーを使用するエージェントは、確認前に計画を表示し、ユーザーの明示的な承諾を得るように指示されています。
guidance/ にある12のトピック。wheel内に同梱され、perf_guidance によって提供されます。原則は普遍的ですが、スニペットはZig 0.16時代のものです。正確なAPIの真実は常に zig_std から得られ、コーパスからは決して得られません。
トピック | 一言まとめ |
| アロケータをライフタイムに合わせる；アリーナのバンプポインタコストと一般的なアロケータの簿記；隠れたアロケーション。 |
| 64バイトのキャッシュライン上でのSoAとAoSのバイト計算；ホット/コールド分割； |
| comptimeの結果はrodata/即値になり、実行時テーブルはダーティページを消費する。 |
| スライスは16バイト。トークンごとのアロケーションは、アロケーション、memcpy、キャッシュラインをトークンごとに消費する。 |
| サイズ＝到達可能性。strip、パニックモード、依存関係の衛生管理。テキストが小さいほど起動時のページフォールトが少ない。 |
| init_arrayなし、テキストページフォールトの遅延、遅延初期化、argv前に作業をしない。 |
| パディング計算、フィールド順序、パックド構造体、 |
| 自動ベクトル化の妨げ、レーンごとの累積＋単一リダクション、 |
| 共有書き込みのMESIコスト、futex待機、システムコールのバッチ処理、フォールスシェアリングのパディング。 |
| エラーはu16値。 |
| リリースビルド、ウォームアップ、平均より最小値/中央値、DCEを防ぐためのシンク、カウンタ。 |
| std優先。依存関係はリンクされるコード量とビルドの脆弱性を増やす。小さなユーティリティはベンダリングする。 |
変数 | 意味 | デフォルト |
| キャッシュディレクトリ |
|
| 完全なサーバーコマンドライン（スキル上書き用） | — |
|
|
|
make sync # deps
make test # unit tests (offline; std-source tests skip without warm cache)
make e2e # spawns the real server over stdio, calls every tool
make fmt # ruff format + checke2eスイートは初回実行時にネットワークが必要です（キャッシュをウォームアップします）。シンボル解決をテストするユニットテストは、ウォームされたstdソースキャッシュに対して実行され、キャッシュがない場合は正常にスキップされます。
zigdocs server not found（Prime Agentスキル）：クローンから uv tool install . でインストールするか、ZIG_DOCS_MCP_REPO にクローンのパスを設定するか、ZIG_DOCS_MCP_CMD に完全なコマンドラインを設定してください。
オフライン時に初回実行が失敗する：キャッシュは空から始まるため、オンライン時に一度取得してください。以降は、古いキャッシュへのフォールバックによりすべてのツールが動作し続けます。
新しいリリース後に結果が古く見える：force=true を渡してください（そうしないと6時間のTTLが適用されます）。
アップデート後も zig version が古いまま：新しいシェルが必要です。また、~/.local/bin がPATH内で以前のインストールディレクトリより前にある必要があります。ドライラン計画には、お使いのマシンの正確な状況が記載されています。
Homebrewのzigが最新リリースに追いつかない：brewのformulaはリリースに遅れます。リリース当日のバージョンが必要な場合は、スタンドアロン戦略を使用してください（brewのformulaを削除し、スタンドアロンをインストール）。
MIT — LICENSE を参照してください。
Curated guidance for high-performance lightweight software (Zig-first).
topic=None lists topics. topic='allocation-strategy' returns the guide. query searches across all guides. Principles are universal; snippets are Zig 0.16-era; verify exact APIs with zig_std.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| topic | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses a limitation: snippets are Zig 0.16-era and advises verifying with zig_std. It also notes principles are universal, implying portability. These are behavioral traits beyond a simple 'getter'. It does not explicitly state it is read-only, but the 'curated guidance' framing implies a non-mutating 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 three short sentences, front-loading purpose and then usage. No redundant content; every sentence adds value. It packs routing and caveats efficiently.
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 simplicity and existing output schema (which covers return format), the description covers usage modes and limitations. It does not specify whether query and topic can be combined, but that is a minor gap. Overall, sufficient for correct invocation.
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 has 0% coverage, so the description must explain parameters. It does: topic=None lists topics, topic='allocation-strategy' returns the guide, query searches across guides. This gives actionable meaning to both params, though it doesn't enumerate all topic values—acceptable because it instructs how to discover them.
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 provides 'Curated guidance for high-performance lightweight software (Zig-first)', a specific resource type. It distinguishes from siblings like zig_std (API reference) and zig_search (search) by focusing on performance guidance. The usage examples (topic listing, specific topic retrieval, query search) further clarify its 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?
Explicitly explains how to use without params (topic=None lists topics), with a specific topic (topic='allocation-strategy' returns the guide), and with query (searches across all guides). It also points to zig_std for API verification, indicating when not to rely on this tool for exact APIs. This is clear routing to an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Release-notes digest for the current channel version: what changed.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | ||
| channel | No | stable |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only states the output ('release-notes digest') but not whether the operation is read-only, whether it makes network calls, whether the 'force' parameter triggers a refresh, or if there are any side effects. This minimal disclosure leaves significant ambiguity for a fetch-style 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 a single, concise sentence that is front-loaded with the core purpose. It is efficient and easy to parse. However, it omits parameter information, making it less complete though still appropriately sized for the tool's simplicity.
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 two optional parameters and an output schema, the description should explain what both parameters do and when to set them. It does neither. The output schema exists, so return format is covered, but the parameter semantics are entirely missing. The tool is simple, yet the description fails to equip the agent to use 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?
The input schema has two parameters (force, channel) but neither has a description, and the schema coverage is 0%. The description does not mention these parameters at all, so the agent has no explanation of what 'force' or 'channel' control. This is a critical gap for a tool with optional parameters.
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: it provides a digest of release notes for the current version of a given channel. The phrase 'what changed' conveys the specific information returned. This distinguishes it from sibling tools like zig_version_status (version info), zig_update (update action), and zig_search (search).
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?
There is no guidance on when to use this tool versus alternatives. It does not mention any situational context, such as 'use this to see recent changes' or 'for details on a specific version use zig_search'. No exclusions or comparisons to siblings are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Official Zig Language Reference, fetched fresh for the channel version.
section= returns that full section. query= searches sections. Neither lists all section ids. channel: 'stable' (latest release) or 'master'.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | ||
| query | No | ||
| channel | No | stable | |
| section | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'fetched fresh' implying network/caching behavior, and clarifies channel versions, but it does not explain the force parameter, potential side effects, rate limits, or what happens when both section and query are provided. Significant behavioral gaps remain.
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, front-loaded with the purpose, and each sentence earns its place. It is well-structured, moving from general purpose to specific usage details. No fluff or redundancy, though it could be slightly more detailed without losing conciseness.
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 has 4 optional params and an output schema, the description covers the main modes but leaves gaps: it does not address the interaction between section and query (mutually exclusive or combinable), the effect of force, or the output format (though schema exists). It is adequate for basic use but not fully 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?
Schema description coverage is 0%, so the description must compensate. It explains section, query, and channel, giving concrete meaning (e.g., 'stable (latest release) or master'), but it does not describe the force parameter at all. The coverage is partial—3 out of 4 params—so it adds value but is incomplete.
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 fetches the official Zig Language Reference and specifies two modes (section retrieval and query search). It uses a specific verb and resource, but does not explicitly distinguish it from sibling tools like zig_search or zig_std, though the purpose is evident.
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 context for usage—it's the language reference fetcher—and explains the two modes, but it does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or alternative guidance is given, so usage 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.
Unified search across langref, guidance, and std doc comments.
scope: 'all' | 'langref' | 'std' | 'guidance'. Results are grouped per source with short snippets; follow up with zig_langref/zig_std/perf_guidance for full text.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| scope | No | all | |
| channel | No | stable |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that results are grouped per source with short snippets and that follow-up tools provide full text. However, it does not mention default behaviors (e.g., scope and channel defaults), rate limits, or any additional side effects. Basic behavior is covered but not comprehensively.
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 with the purpose front-loaded. The second sentence provides essential hints about scope and follow-up, with no redundancy. It is concise but could be slightly more structured; still, it is efficient and easily scannable.
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?
The tool is moderately complex with four parameters and multiple sources. The description covers the search scope and output format (snippets, grouping) but does not explain the channel parameter or how limit affects results. It also leaves ambiguity about whether changelog is searched, given the sibling tools. The output schema likely covers return format, but the description has notable 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?
Schema description coverage is 0%, so the description must compensate. It explains the scope parameter by listing valid values and clarifies the grouping of results by source. However, it does not explain the 'limit' or 'channel' parameters at all, leaving them to schema defaults. This partial compensation is helpful but incomplete.
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 is a unified search across langref, guidance, and std doc comments, with a specific verb and resource. It also distinguishes itself from follow-up tools by indicating it returns snippets rather than full text. However, it does not explicitly contrast with all siblings (e.g., whether changelog is included), so it slightly misses full 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?
It implies usage by saying 'follow up with zig_langref/zig_std/perf_guidance for full text', which suggests using this for initial search and those for detailed content. Yet it does not specify when to use this tool instead of directly accessing those tools, nor does it mention any exclusions or scenarios where a search is not appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Standard-library docs from the EXACT released source of the channel.
symbol='std.fs.Dir.openFile' walks real re-exports and returns the /// docs plus the declaration text from that release. query= searches std doc comments. Prefer exact symbols; use query to discover names.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | ||
| query | No | ||
| symbol | No | ||
| channel | No | stable |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It honestly discloses how it works: walking real re-exports and returning doc comments plus declaration text from the exact release. This gives the agent a clear model of behavior and scope. It does not mention side effects, but as a lookup tool, that is expected. No contradictions with annotations (none exist).
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 well-structured: the first sentence states purpose, the second explains the two modes, and the third gives a preference hint. Every sentence earns its place, and there is no verbose repetition or 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 documentation lookup tool, the description covers the core behavior and most parameters. The output schema exists, so return values need not be described. The main missing piece is the 'force' parameter's effect, which is a notable hole given the tool's simplicity. Overall, it is reasonably complete but not fully exhaustive.
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 explain parameters. It explains symbol and query with concrete examples, and channel is implied in the first sentence. However, the 'force' parameter is completely unexplained. With four parameters, leaving one entirely undefined is a notable gap, though the primary modes are well covered.
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 provides standard-library docs from a specific channel's released source. It distinguishes itself from siblings like zig_langref and zig_changelog by specifying the resource (standard library) and the operation (returns /// docs and declaration text). The two modes (symbol lookup and query search) are explicitly described.
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 provides guidance on when to use symbol vs query ('Prefer exact symbols; use query to discover names'), which helps within the tool. However, it does not explicitly mention alternatives or when not to use this tool (e.g., versus zig_search or zig_langref). The guidance is implied by the tool's focus on std docs, but it lacks explicit exclusion or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upgrade the LOCAL zig toolchain to the latest release, safely.
dry_run=True (default): print the exact plan, change nothing. confirm=True AND dry_run=False: apply it (brew upgrade or official tarball). Never pass confirm=True without the user asking for the update.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | No | stable | |
| confirm | No | ||
| dry_run | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to rely on, the description takes full responsibility for disclosing behavior. It states that dry_run changes nothing, that confirm=True combined with dry_run=False applies the upgrade, and warns about the danger of confirm=True without user consent. This is unusually clear for a mutation tool; it also implies a side effect (modifying the local toolchain) transparently.
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 well-structured: one sentence states the purpose, the next two explain the two modes with their preconditions, and a final imperative warns about misuse. No filler or redundant information; each 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?
While the description covers the two critical operational aspects (dry-run and confirm), it omits the channel parameter entirely and does not mention what the output schema contains (e.g., what a successful upgrade returns). For a tool that mutates the local environment, the missing channel documentation is a real gap. The safety warning is strong, but the parameter coverage is incomplete, leaving the agent to guess about channel.
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 description competently explains dry_run and confirm, their defaults, and their interaction. However, the channel parameter is completely ignored. The schema provides no descriptions (0% coverage) and no enums, so the agent has no idea what values channel accepts or how it affects the upgrade (e.g., does 'stable' vs 'master' change the install method or version?). This is a significant gap for a parameter that likely affects the outcome.
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 action ('upgrade the LOCAL zig toolchain') and distinguishes it from siblings like zig_version_status and zig_changelog which are about checking status or docs. It even explains the two modes (dry_run and apply) and which one is safe by default, leaving no ambiguity about what the tool accomplishes.
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 explicit when-to-use and when-not-to-use guidance: dry_run is the default, confirm should never be passed without the user explicitly requesting the update. This tells the agent exactly when to apply vs. just preview, and the warning about confirm covers safety. The mention of 'brew upgrade or official tarball' gives practical method context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare local zig version with the latest upstream release.
Returns local version/path, latest stable, master, up_to_date flag and, when behind, a suggested next step. Call this before version-sensitive answers and whenever Zig code misbehaves in ways a newer compiler fixes.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It describes the return values and the underlying comparison action, and implicitly implies a read-only operation (no mutation language). However, it does not explicitly state side effects, network requirements, or error behavior, which for a status tool could be expected. It adds value beyond the name but leaves 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 two sentences, front-loading the core purpose and then detailing the output and usage context. Every sentence earns its place with no redundant words, and the structure is 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?
The tool is simple (one optional boolean parameter) and has an output schema, so the description needn't explain return structure. However, the lack of any explanation for the 'force' parameter and no mention of prerequisites (e.g., network access or presence of ZIG) leaves gaps. The description covers the main use case but not all context needed for safe and correct invocation.
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 a single boolean parameter 'force' with a default but no description, and schema coverage is 0%. The description does not mention this parameter at all, leaving the agent to guess what 'force' does (e.g., bypass cache, force network fetch). Since there is zero coverage and no explanation, the description fails to provide needed semantics for this parameter.
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 'Compare' with a clear resource ('local `zig version` with the latest upstream release') and enumerates exactly what is returned. It also differentiates from siblings like zig_update by focusing on status rather than modification, so an agent can select it without ambiguity.
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 states when to use the tool: 'before version-sensitive answers' and 'whenever Zig code misbehaves in ways a newer compiler fixes.' It does not mention when not to use it or point to alternatives, which would make it a 5, but the guidance is clear and actionable.
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.1.0perf_guidancezig_changelogzig_langrefzig_searchzig_stdzig_updatezig_version_statusScored across 7 tools
Each tool targets a distinct purpose: version checking, updating, language reference, standard library docs, changelog, performance guidance, and a unified search that complements the others. No two tools appear to do the same thing, and descriptions clarify boundaries.
Most tools follow a 'zig_' prefix, but the second element varies in style (noun, verb_noun, abbreviation). 'perf_guidance' breaks the prefix pattern. Still, names are short, descriptive, and predictable enough for an agent to infer purpose.
Seven tools is well-scoped for a documentation and toolchain server. Each tool earns its place, covering version checks, updates, references, and search, without bloat or missing essentials.
The surface covers the core documentation lifecycle: version status, update, language reference, std docs, changelog, performance guidance, and a cross-cutting search. There are no obvious gaps for the stated purpose of providing Zig documentation and version management.
Serves your design system and coding standards to coding agents, so they stop guessing.
Versioned documentation registry and semantic search for AI tools and coding assistants.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Search and read Rust documentation for the standard library and any crate on crates.io
