How do I use noir-mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@noir-mcp-server Search the standard library for pedersen hash" 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.

noir-mcp-server

Official

by noir-lang

Overview Schema Related Servers Score Discussions

TypeScript

Local

noir-mcp-server

MCP server for Noir development — clones and searches Noir documentation, standard library, examples, and community libraries.

Install

Claude Code

claude mcp add noir-mcp -- npx noir-mcp-server@latest

Codex

codex mcp add noir-mcp -- npx noir-mcp-server@latest

Claude Desktop / Cursor / Windsurf

Add to your MCP config file (e.g. ~/.claude/mcp.json, claude_desktop_config.json):

{
  "mcpServers": {
    "noir": {
      "command": "npx",
      "args": ["noir-mcp-server@latest"]
    }
  }
}

OpenCode

Add to your config file (e.g. ~/.config/opencode/opencode.json):

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "noir": {
      "type": "local",
      "command": ["npx", "-y", "noir-mcp-server@latest"],
      "enabled": true,
    },
  },
}

From source

git clone https://github.com/critesjosh/noir-mcp-server.git
cd noir-mcp-server
npm install && npm run build

Then point your MCP config to the built file:

{
  "mcpServers": {
    "noir": {
      "command": "node",
      "args": ["/path/to/noir-mcp-server/dist/index.js"]
    }
  }
}

Related MCP server: Repo Docs MCP

Tools

Tool	Description
`noir_sync_repos`	Clone/update repos. Default: core only. Add `categories: ["libraries"]` for packages.
`noir_status`	Check repo clone status
`noir_search_code`	Search `.nr` files across repos
`noir_search_docs`	Search Noir documentation
`noir_search_stdlib`	Search standard library
`noir_list_examples`	List available examples
`noir_read_example`	Read example source
`noir_read_file`	Read any file from repos
`noir_list_libraries`	List libraries with descriptions & clone status

Repository Categories

Core (synced by default):

noir — Compiler, stdlib, tooling, docs
noir-examples — Official example circuits

Libraries (sync with categories: ["libraries"]):

noir-bignum — Big integer arithmetic
noir_bigcurve — Elliptic curve operations
noir_json_parser — JSON parsing (RFC 8259)
noir_string_search — Substring search/proof
noir_sort — Array sorting
sparse_array — Sparse array implementation
zk-kit.noir — Merkle trees, ECDH, and more

Reference (sync with categories: ["reference"]):

awesome-noir — Curated ecosystem index

When this server helps (and when it doesn't)

Good fit:

Writing or editing Noir circuits with an AI agent that would otherwise lean on stale, pre-1.0 syntax from memory. The Noir docs and standard library are pinned to a specific release, so the agent works from version-correct language source rather than guessing.
Looking up how a stdlib function, trait, or type is actually defined or used (e.g. hash, Field, assert, pedersen).
Finding real, working example circuits to adapt (noir-examples, noir/examples).
Discovering ecosystem libraries and reading their source.
Grounding an agent so it stops inventing outdated syntax. Pair it with nargo check to confirm the result compiles.

Poor fit:

You want guaranteed-correct, compilable output without verifying it yourself. This server does not compile or run anything; always confirm with nargo check.
You need community libraries to exactly match your pinned compiler. Libraries are cloned at their latest branch, not a release matched to the compiler (see Limitations).
Conceptual or design questions ("what is the best way to structure a Merkle-membership circuit?"). Search is keyword/regex, not semantic; the model plus the docs site may serve you better.
Proving-backend workflows beyond reading bb.js source.
Offline use, or environments without git (and ideally ripgrep) installed.

Limitations

Read-only, no verification. It surfaces source and docs but does not compile, type-check, or run circuits. It cannot confirm that code is correct; run nargo check against a matching toolchain.
Core repos are pinned; libraries are not. The noir repo (docs, stdlib, in-repo examples) and bb.js are checked out at a fixed tag; community libraries are cloned at their main/master branch tip, which may be newer or older than the pinned compiler. Noir's compiler_version field only expresses a full-release floor (e.g. >=1.0.0) and cannot distinguish between betas, so it will not flag a beta-level mismatch. Treat library code as a reference and verify it against your toolchain.
Keyword search, not semantic. Search is ripgrep over files. It excels at finding a known symbol or string and is weak at open-ended "how do I do X" questions.
Single-line matches. Results are matching lines without surrounding context; reading the full function or doc comment usually needs a follow-up noir_read_file.
Sync required, and the first sync is slow. Repos are cloned locally over the network before search works. Core is two repos; adding library or reference categories clones more.
One version at a time. The server serves a single pinned Noir line (see Environment Variables). Switching versions means re-syncing with version, and library compatibility is still not guaranteed.
Snapshot, not live. Content reflects the pinned tag (docs/stdlib) and your last sync (libraries). Re-sync to pick up updates.
Host dependencies. Requires git; uses ripgrep when present and falls back to a slower built-in search otherwise.

Environment Variables

Variable	Default	Description
`NOIR_DEFAULT_VERSION`	`v1.0.0-beta.21`	Noir version tag for the main repo
`NOIR_MCP_REPOS_DIR`	`~/.noir-mcp`	Base directory for cloned repos

Development

npm run dev    # Watch mode
npm run build  # Build
npm start      # Run server
npm test       # Run the Vitest unit suite
node test.mjs  # Optional live integration smoke test (clones repos)

Available Tools

9 tools

noir_list_examplesA

List available Noir example circuits from noir-examples and noir/examples.

ParametersJSON Schema

Name	Required	Description	Default
`category`	No	Filter by category/keyword (e.g., 'hash', 'merkle', 'ecdsa')

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden but only states the source, omitting details like output format, ordering, or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words, front-loading the core purpose efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool, the description is adequate but lacks completeness regarding return format or how results are structured, especially given no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers the parameter (category) with 100% description, and the tool description adds no extra meaning beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('List'), the resource ('Noir example circuits'), and the scope ('from noir-examples and noir/examples'), distinguishing it from siblings like noir_list_libraries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage through the tool name and purpose, but lacks explicit guidance on when to prefer this over alternatives like noir_read_example or noir_search_code.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

noir_list_librariesA

List available Noir library and reference repos with descriptions and clone status. Use to discover community packages and tools in the Noir ecosystem.

ParametersJSON Schema

Name	Required	Description	Default
`category`	No	Filter by category: 'libraries' or 'reference'. Shows both if omitted.

TDQS

A4/5.0

Behavior3/5

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 states the tool lists repos with descriptions and clone status, implying a read-only operation, but does not explicitly confirm safety, rate limits, or side effects. This is adequate but could be more explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the key action and outcome. No superfluous information—every word serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool is simple with one optional parameter and no output schema, the description covers the purpose and usage adequately. It could mention prerequisite steps like syncing repos, but that is not necessary for basic usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (one parameter fully described). The description does not add additional meaning beyond the schema for the 'category' parameter. Baseline 3 is appropriate as schema handles it well.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists Noir library and reference repos with descriptions and clone status. It distinguishes from siblings like noir_list_examples and noir_search_code by specifying the resource type and the included details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use to discover community packages and tools', providing clear usage context. However, it does not mention when not to use this tool versus alternatives like noir_search_code for targeted queries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

noir_read_exampleA

Read the source code of a Noir example circuit. Use noir_list_examples to find available examples.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Example name (e.g., 'hello_world', 'merkle_proof')

TDQS

A4/5.0

Behavior2/5

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 'Read the source code' without any behavioral details (e.g., return format, side effects, permissions). Lacks transparency beyond the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no waste. The action is front-loaded, and the sibling reference is efficiently placed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read tool with one parameter and no output schema, the description is adequate. It references sibling for discovery and states the core function. Minor gap: no mention of return type or format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and includes a descriptive example for the 'name' parameter. The description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it reads the source code of a Noir example circuit, with a specific verb 'read' and resource 'source code of a Noir example circuit'. It distinguishes from sibling noir_list_examples by referencing it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use this tool (to read an example's source code) and when to use the sibling (noir_list_examples to find available examples). This provides clear usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

noir_read_fileA

Read any file from the cloned repositories by path. Path should be relative to the repos directory.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	File path relative to repos directory (e.g., 'noir/noir_stdlib/src/hash/mod.nr')

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so description carries full burden. It implies read-only and repository scope but doesn't detail error behavior, file types, or size limits. Adequate but minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with core action, no redundancy. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with single parameter and no output schema, description is sufficiently complete: clarifies resource scope and path convention.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and schema description already includes path format and example. Description repeats this, adding no new meaning beyond what schema provides. Baseline 3 maintained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'Read' and the resource 'file from cloned repositories', specifying the path is relative to repos directory. This distinguishes it from siblings like noir_read_example which reads specific examples.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 like noir_read_example or noir_search_code. Only provides path format hint but lacks context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

noir_search_codeA

Search Noir source code across all cloned repos. Supports regex patterns. Use for finding function implementations, patterns, and examples in .nr files.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search query (supports regex)
`filePattern`	No	File glob pattern (default: .nr). Examples: .ts, *.{nr,rs}
`repo`	No	Specific repo to search (e.g., 'noir', 'noir-bignum', 'zk-kit.noir')
`maxResults`	No	Maximum results to return (default: 30)

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It mentions regex support and scope (all cloned repos), but lacks details on return format, performance implications, or any read-only guarantees. Adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences: purpose and scope, feature (regex), and use cases. No waste, front-loaded, easy to read. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters and no output schema, the description covers purpose, scope, features, and typical use. Missing explicit statement that only .nr files are searched by default (though filePattern default is in schema) and no details on output format. Mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 adds context that the search is across all cloned repos and highlights regex for the query, providing value beyond schema. However, it does not significantly elaborate on other parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches Noir source code across all cloned repos, specifies supporting regex patterns, and gives use cases (finding function implementations, patterns, examples). This distinguishes it from siblings like noir_search_docs or noir_search_stdlib.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly guides usage by focusing on source code search, but does not explicitly state when not to use it or mention alternatives like noir_search_docs for documentation or noir_search_stdlib for standard library. No exclusions provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

noir_search_docsB

Search Noir documentation. Use for finding language guides, tutorials, and API documentation.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Documentation search query
`section`	No	Docs section to search (subdirectory under noir/docs/)
`maxResults`	No	Maximum results to return (default: 20)

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only states the tool's purpose. It does not disclose behavioral traits such as idempotency, read-only nature, or any side effects. The word 'Search' implies read-only, but this is not explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the verb 'Search' and resource, and no wasted words. Every sentence adds value: purpose and usage examples.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters, no output schema, and no annotations, the description is minimal. It does not explain search behavior (e.g., exact vs fuzzy matching), result format, pagination, or how section parameter affects results. This leaves the agent guessing about important usage details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (all three parameters have descriptions), so the baseline is 3. The description adds no additional meaning beyond what the schema provides, so it does not compensate or improve.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Search Noir documentation' with specific verb and resource, and includes examples of content types (language guides, tutorials, API documentation). It distinguishes from sibling tools like noir_search_code and noir_search_stdlib by its focus on documentation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says 'Use for finding language guides, tutorials, and API documentation,' providing general context. However, it does not specify when to avoid this tool or mention alternatives among the nine sibling tools, only implicitly differentiating by name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

noir_search_stdlibB

Search the Noir standard library (noir_stdlib). Use for finding built-in functions, traits, and types available in Noir.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query (e.g., 'hash', 'Field', 'assert', 'pedersen')
`maxResults`	No	Maximum results to return (default: 30)

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It only states the basic search function without revealing behavior like search algorithm, rate limits, authentication needs, or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, front-loaded with the action. It is concise but lacks structured sections like bullet points for readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (2 params, no output schema), the description is adequate but incomplete. It does not mention return format, pagination, or error conditions, which are gaps for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for both parameters. The description adds domain context ('noir_stdlib') but does not enhance parameter meaning beyond what the schema provides (e.g., query examples, default for maxResults).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches the Noir standard library for built-in functions, traits, and types. It distinguishes from siblings like noir_search_code and noir_search_docs by specifying the library scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says to 'Use for finding built-in functions, traits, and types' but does not explicitly say when not to use or name alternatives among siblings. Guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

noir_statusA

Check the status of cloned Noir repositories - shows which repos are available, their categories, and commit hashes.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It clearly indicates a read-only operation (checking status) without destructive actions. For a simple stateless tool with no parameters, this is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence efficiently conveys purpose and output. No unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains the return information (repos, categories, commit hashes). For a simple status check, it is adequate; missing details like format or ordering are minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters defined in the input schema, so by baseline rules score is 4. Description does not add parameter information, but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool checks status of cloned Noir repositories, listing what information is shown (available repos, categories, commit hashes). It distinctly differentiates from sibling tools like noir_list_examples or noir_search_code.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the tool is for checking status of cloned repos, implying usage context. No explicit when-not or alternatives, but sibling tool names provide enough context for differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

noir_sync_reposA

Clone or update Noir repositories locally. Run this first to enable searching. Default: syncs core repos (noir compiler/stdlib/docs, noir-examples). Use categories to sync additional repos: 'libraries' for community packages, 'reference' for awesome-noir.

ParametersJSON Schema

Name	Required	Description
`version`	No	Noir version tag for the main noir repo (e.g., 'v1.0.0-beta.3'). Defaults to latest supported version.
`force`	No	Force re-clone even if repos exist (default: false)
`repos`	No	Specific repos to sync by name (e.g., ['noir-bignum', 'noir_json_parser'])
`categories`	No	Categories to sync: 'core' (default), 'libraries', 'reference'. Example: ['core', 'libraries']

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes basic behavior (clone/update, defaults, force re-clone) but does not detail update semantics (e.g., overwrite or merge) or potential side effects. Without annotations, description carries full burden and is adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences; front-loaded with primary purpose. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers essential context: role as prerequisite, default vs. category sync. Lacks detail on return value (e.g., list of synced repos) and update behavior. Still adequately complete for a setup tool with full parameter coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description adds value by explaining the meaning of categories and default version behavior, clarifying usage beyond schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the action ('Clone or update') and the resource ('Noir repositories') with the purpose ('enable searching'). Distinguishes from sibling tools which are search/list operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises to run this tool first to enable searching, and explains categories for additional repos. Lacks explicit when-not-to-use guidance, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: listing examples vs libraries, reading specific examples vs any file, searching different scopes (code, docs, stdlib), and managing repositories. No overlapping functionalities.

Naming Consistency5/5

All tools follow a consistent noir_verb_noun pattern in snake_case, making it easy to predict functionality from names.

Tool Count5/5

9 tools is well-scoped for the server's purpose of exploring and searching the Noir ecosystem, covering necessary operations without bloat.

Completeness4/5

Covers listing, reading, searching across examples, libraries, code, docs, and stdlib, plus status and syncing. Minor gap: no tool for detailed library info beyond listing, but core workflows are well-supported.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Context Awesome A
io.github.bh-rat
MCP server for accessing curated awesome list documentation
Documentation Access Research & Data
2259
gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5361
forkast-mcp-docs A
io.github.ForkastPredict
MCP server for querying Forkast documentation
Documentation Access Search Developer Tools
42
prover
com.axiomatic-ai
Lean 4 MCP server: compile, prove theorems, and formalize math with Mathlib.
Developer Tools Code Analysis Research & Data
2

Related MCP Servers

MCP Documentation Server
Documentation Access Developer Tools Search
glassBead-tc
A
license
B
quality
D
maintenance
Provides comprehensive access to MCP documentation through structured guides, full-text search, and interactive development workflows for building servers and clients.
Updated a year ago (2025-09-19 13:06 UTC)
3
37
MIT
Repo Docs MCP
Developer Tools Documentation Access Version Control
pepperfm
A
license
Not graded
quality
D
maintenance
A generic MCP server that exposes local repository checkouts, allowing users to search and read code and documentation through natural language. It supports multiple instances, enabling seamless interaction with various codebases via configurable tool prefixes and URI schemes.
Updated 6 months ago (2026-02-27 10:40 UTC)
2,013
MIT
mcp-server-markdown
Developer Tools Documentation Access File Systems
ofershap
A
license
A
quality
D
maintenance
MCP server for markdown files — search, extract sections, list headings, find code blocks across docs.
Updated 24 days ago (2026-08-10 07:38 UTC)
6
130
5
MIT
@codesift/mcp
Developer Tools Code Analysis Search
rutvikchandla3
A
license
Not graded
quality
B
maintenance
MCP server for local-first lexical code search, providing tools for searching code, finding symbols, and reading chunks from indexed repositories.
Updated 2 months ago (2026-06-26 13:19 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/noir-lang/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server