Provides Zig language intelligence including diagnostics, formatting, hover info, go-to-definition, references, completions, document symbols, and building.
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., "@mcp-server-zig Show me the errors in src/main.zig"
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 server that provides Zig language intelligence for Claude Code. Wraps ZLS (Zig Language Server) and exposes 8 tools for diagnostics, formatting, hover info, go-to-definition, references, completions, document symbols, and building.
Node.js >= 18
Zig compiler on PATH (zig version)
ZLS on PATH (zls --version)
# macOS
brew install zig zls
# Or download from:
# https://ziglang.org/download/
# https://github.com/zigtools/zls/releasesRelated MCP server: Zignet
Add to Claude Code:
claude mcp add --transport stdio mcp-server-zig -- npx -y mcp-server-zigOr from source:
git clone https://github.com/sadopc/mcp-server-zig.git
cd mcp-server-zig
pnpm install && pnpm build
claude mcp add --transport stdio zig -- node $(pwd)/build/index.jszig_diagnosticsGet errors and warnings for a Zig source file.
Parameter | Type | Description |
| string | Absolute path to the .zig file |
zig_formatFormat Zig code using zig fmt.
Parameter | Type | Description |
| string? | Path to .zig file to format in-place |
| string? | Zig source code string to format |
Provide either file_path or code, not both.
zig_hoverGet type information and documentation for a symbol at a position.
Parameter | Type | Description |
| string | Absolute path to the .zig file |
| number | Zero-based line number |
| number | Zero-based character offset |
zig_definitionGo to definition — find where a symbol is defined.
Parameter | Type | Description |
| string | Absolute path to the .zig file |
| number | Zero-based line number |
| number | Zero-based character offset |
zig_referencesFind all references to a symbol.
Parameter | Type | Description |
| string | Absolute path to the .zig file |
| number | Zero-based line number |
| number | Zero-based character offset |
zig_completionsGet completion suggestions at a position.
Parameter | Type | Description |
| string | Absolute path to the .zig file |
| number | Zero-based line number |
| number | Zero-based character offset |
| number? | Max completions to return (default: 20) |
zig_document_symbolsGet the document symbol outline (functions, structs, variables, etc.).
Parameter | Type | Description |
| string | Absolute path to the .zig file |
zig_buildRun zig build in a project directory.
Parameter | Type | Description |
| string | Path to project directory (containing build.zig) |
| string[]? | Additional args for |
Claude Code ←(MCP/stdio)→ mcp-server-zig ←(LSP/stdio)→ ZLS subprocess
←(shell exec)→ zig fmt / zig buildZLS tools (diagnostics, hover, definition, references, completions, symbols): The server spawns ZLS as a subprocess, communicates via LSP over stdio. ZLS is started lazily on first tool call and auto-restarts on crash.
CLI tools (format, build): These call zig fmt and zig build directly — no ZLS needed.
"ZLS spawn error" — ZLS is not installed or not on PATH. Run which zls to verify.
"zig fmt failed" — Zig compiler is not installed or not on PATH. Run which zig to verify.
Diagnostics are empty — ZLS needs time to analyze the file. The server waits 200ms by default. For large projects, diagnostics may take longer to appear.
Tools hang — Check that ZLS is compatible with your Zig version. ZLS and Zig versions should match.
MIT
Run zig build in a project directory and return the build output
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | Absolute path to the Zig project directory (containing build.zig) | |
| args | No | Additional arguments to pass to `zig build` |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions running 'zig build' and returning output but does not disclose side effects (e.g., file creation), error handling, or prerequisites beyond the project path. Minimal behavioral disclosure.
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?
A single, front-loaded sentence that conveys the action and expected result with no unnecessary words. Extremely concise and well-structured.
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 two parameters and no output schema, the description is fairly complete but lacks information on return format, error behavior, or potential side effects. Adequate but not thorough.
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% with descriptions. The description adds minimal extra context: clarifying that project_path should contain 'build.zig' and that args are additional arguments. This is adequate but does not significantly enhance 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 explicitly states the verb 'Run', the resource 'zig build', and the scope 'in a project directory'. This clearly defines what the tool does and is distinct from sibling tools like zig_completions or zig_format.
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 explicit guidance on when to use or when not to use this tool versus alternatives. It is implied for building a Zig project, but lacks exclusions or context on when other tools might be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get completion suggestions at a specific position in a Zig file via ZLS
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the .zig file | |
| line | Yes | Zero-based line number | |
| character | Yes | Zero-based character offset | |
| limit | No | Max number of completions to return (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist to cover behavioral traits. The description only states the operation without disclosing side effects, authentication needs, error handling, or response format. For a tool with no annotations, this is insufficient.
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 with all essential elements: action, resource, method, and target. No redundant words, and the main purpose is front-loaded.
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?
Despite 100% schema coverage, the tool has no output schema and 4 parameters. The description fails to explain what the completion results look like, pagination, or error scenarios. For a completions tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add extra meaning beyond the schema; it only mentions 'via ZLS', which is a implementation detail, not parameter-specific.
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: 'Get completion suggestions at a specific position in a Zig file via ZLS'. It uses a specific verb ('Get') and resource ('completion suggestions'), and distinguishes from sibling tools like zig_build, zig_definition, etc.
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 is provided on when to use this tool versus alternatives. The description does not mention prerequisites, limitations, or context where this tool is preferred over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Go to definition — find where a symbol is defined in a Zig codebase via ZLS
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the .zig file | |
| line | Yes | Zero-based line number | |
| character | Yes | Zero-based character offset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It mentions 'via ZLS' but doesn't state if it requires a project file, what happens if symbol not found, or if it's a read-only operation. This is insufficient.
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?
Single sentence is concise and front-loaded with core purpose. Could add more detail without being verbose, but current structure is efficient.
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 no output schema, description explains purpose but not return values. Sibling tools exist but no guidance on when to use this one. For a simple tool, it is minimally adequate but incomplete in context.
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%, with clear parameter descriptions. The description adds no additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Go to definition — find where a symbol is defined', which is a specific verb+resource combination. It distinguishes from sibling tools like zig_hover, zig_references, etc., 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?
No explicit when-to-use or when-not-to-use guidelines are provided. The description implies use for navigating to a symbol's definition but doesn't compare to alternatives like zig_references or zig_hover.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get diagnostics (errors, warnings) for a Zig source file via ZLS
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the .zig file to diagnose |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure, but it only states it gets diagnostics via ZLS. It omits important traits like whether it requires an active ZLS instance, if it performs any side effects, or the format of return data.
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 sentence with no wasted words, but it could be slightly more informative without losing conciseness (e.g., mentioning that it returns a list of errors and warnings).
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?
Despite having only one parameter with full schema coverage, the tool has no output schema, so the description should explain the return format. It does not, leaving the agent unsure of what to expect. Additionally, no usage context is given.
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 single parameter file_path is fully described in the schema as an absolute path to a .zig file. The description adds no extra meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly uses a specific verb ('Get'), identifies the resource ('diagnostics for a Zig source file'), and distinguishes from sibling tools like zig_build or zig_hover by focusing on diagnostic information via ZLS.
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 is provided on when to use this tool versus alternatives such as zig_hover or zig_references. The description does not mention prerequisites or contexts where diagnostics are appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the document symbol outline (functions, structs, variables) of a Zig file via ZLS
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the .zig file to get symbols for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions 'via ZLS' but does not disclose behavioral traits such as side effects, prerequisites (e.g., file must exist), or error handling. For a read-only tool, minimal disclosure is acceptable but not fully adequate.
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 sentence with no unnecessary words, efficiently conveying the tool's purpose and key detail (via ZLS). It is appropriately front-loaded.
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 is adequate. It specifies the file parameter and the kind of output (symbol outline with examples). It could mention return format or error behavior, but is sufficient for basic usage.
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% with the parameter 'file_path' described as 'Absolute path to the .zig file to get symbols for'. The description adds no extra meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the document symbol outline (functions, structs, variables) of a Zig file via ZLS. It specifies the resource and output, distinguishing it from siblings like zig_definition or zig_hover.
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 explicit guidance on when to use this tool versus alternatives. The purpose is self-explanatory given sibling tool names, but no when-not-to-use or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Format Zig code using zig fmt. Provide either a file path to format in-place, or a code string to format and return.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | No | Absolute path to .zig file to format in-place | |
| code | No | Zig source code string to format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that file_path causes in-place formatting (mutation) whereas code returns formatted code (read). But it omits prerequisites (e.g., zig installed), error conditions, and side effects beyond the mode distinction.
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 sentence that immediately identifies the tool's purpose and key modes. Every word contributes, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no output schema, the description adequately covers the modes. However, it could mention that formatting requires the zig tool, that file_path expects an absolute path to a .zig file (implied but not explicit), and that code must be valid Zig source.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds value by clarifying the mutual exclusivity of the two parameters and the side effects (in-place vs. return), which is not present in 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 action (Format Zig code using `zig fmt`) and specifies two modes: formatting a file in-place or formatting a code string and returning it. This distinguishes it from sibling tools like zig_build or zig_completions.
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 tells when to use each parameter (file_path for in-place, code for return), but does not explicitly state when not to use this tool or mention alternatives. However, the sibling tools are all different, so implicit differentiation exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get type information and documentation for a symbol at a specific position in a Zig file via ZLS
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the .zig file | |
| line | Yes | Zero-based line number | |
| character | Yes | Zero-based character offset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry behavioral disclosure. It states the tool 'gets' information, implying read-only behavior, but does not explicitly declare no side effects or required permissions.
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?
Single sentence effectively states purpose and resource, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Input schema is complete, but lacking output schema and description does not specify return format; adequate for a simple query but missing details for full completeness.
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%, and the description adds no extra meaning beyond aligning with the parameters; straightforward but sufficient for a simple tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves type information and documentation for a symbol at a specific position in a Zig file via ZLS, distinguishing it from siblings like zig_definition and zig_completions.
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 explicit guidance on when to use this tool over alternatives (e.g., zig_definition or zig_document_symbols); the description only implies usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all references to a symbol at a specific position in a Zig file via ZLS
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the .zig file | |
| line | Yes | Zero-based line number | |
| character | Yes | Zero-based character offset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the purpose and fails to disclose behavioral traits such as whether the file must be saved, performance implications, or return format.
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?
Single sentence is very concise, but it omits useful guidance. It could be improved by adding usage context without becoming verbose.
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 no output schema and no annotations, the description is incomplete. It does not describe the return format or any side effects, leaving the agent uninformed about results.
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 schema already documents all parameters. The description adds minimal value beyond implying that 'position' corresponds to line and character.
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 finds all references to a symbol at a position in a Zig file, using ZLS. It distinguishes from siblings like zig_definition (go-to-definition) and zig_hover (hover info).
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 explicit when-to-use or when-not-to guidance is given. The description implies usage for reference finding, but fails to differentiate from alternatives like zig_definition.
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.
v1.0.0zig_buildzig_completionszig_definitionzig_diagnosticszig_document_symbolszig_formatzig_hoverzig_referencesEach tool serves a clearly distinct purpose: building, formatting, and various LSP features like completions, definitions, diagnostics, document symbols, hover, and references. No two tools overlap in functionality.
All tools follow a consistent 'zig_<action>' pattern with snake_case, making it predictable and easy to understand the purpose from the name alone.
With 8 tools, the server covers the essential Zig development workflow (build, format, LSP features) without being bloated. The count is well-scoped for a language-specific MCP server.
The toolset covers core development tasks: building, formatting, and common LSP operations (completions, diagnostics, hover, definitions, references, document symbols). Minor gaps like renaming or code actions are absent but not critical for basic usage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live SEO workflow tools for Claude Code, Codex, and AI agents.
Teamfight Tactics data & AI coaching for Claude and ChatGPT — 19 tools, built-in Riot key.
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
One workspace of tools for Claude and ChatGPT: connect 600+ apps, generate media, build tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sadopc/mcp-server-zig'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
