How do I use noir-mcp-server?

1. Click on "Deploy 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 Source Related Servers Discussions Admin

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?

No annotations are provided, so the description carries full burden. It discloses the source of examples but does not detail what information is returned (e.g., names, paths) or any limitations, leaving behavior unclear.

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 one sentence, concise and front-loaded. It efficiently communicates the core purpose, though it could be slightly expanded with output details.

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's simplicity (one optional parameter, no output schema), the description covers the main functionality. However, it lacks output format details, which are not compensated by other fields.

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 describes the single optional parameter 'category' with examples. The description does not add further meaning beyond the schema, and schema coverage is 100%, so baseline 3 applies.

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 example circuits from specific sources (noir-examples and noir/examples), distinguishing it from siblings like noir_list_libraries which lists 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 for browsing available examples but provides no explicit guidance on when to use this versus 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

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It mentions listing with descriptions and clone status but does not state that the operation is read-only, whether it requires network access, or any other behavioral traits.

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 action, no redundant information. Every sentence adds value.

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 simple list tool with one optional parameter and no output schema, the description adequately covers purpose and basic output. Minor gap: it doesn't specify if data is live or cached.

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 a clear description for the category parameter. The tool description adds no further meaning beyond what the schema 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 the action (list), the resource (Noir library and reference repos), and what information is provided (descriptions and clone status). It distinguishes itself from siblings like noir_list_examples by specifying repo types.

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 indicates usage for discovery ('Use to discover community packages and tools'), giving context but no explicit when-not-to-use or alternatives. It is adequate but lacks deeper guidance.

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

Behavior3/5

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

No annotations are provided, so the description bears full responsibility. It states 'Read' implying a read-only operation, but does not detail error handling, expected output format, or behavior when the example name is invalid. This is minimally adequate for a simple read tool.

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 consists of two short, front-loaded sentences with no superfluous information. Every word serves a purpose: the first sentence states the action, the second provides usage context.

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's simplicity (single parameter, no output schema), the description covers the core purpose and how to find available examples. It could mention potential errors or return format, but the current level of detail is adequate for a straightforward read operation.

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 input schema is fully described with a concrete example for the 'name' parameter. The description adds no additional meaning beyond what the schema provides, which meets the baseline for 100% schema coverage.

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 specifies the action ('Read') and the resource ('source code of a Noir example circuit'). It distinguishes from the sibling tool 'noir_list_examples' by directing the user to use that tool for discovering available examples.

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 recommends using 'noir_list_examples' to find examples, providing clear context for when to use this tool. While it lacks explicit 'when not to use' guidance, the provided instruction is sufficient.

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

noir_read_fileB

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

B3.4/5.0

Behavior2/5

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

No annotations provided, so description must bear full burden. It reveals it's a read operation but lacks details on error handling, output format, file type restrictions, or permissions. Basic behavior only.

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?

Two sentences with no wasted words. Very concise, though could benefit from additional context. Still effective.

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?

Low complexity tool with 1 param and no output schema. Description covers basic purpose but lacks details on error behavior, output expectations, or file limits. Adequate but with gaps.

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%, so baseline is 3. Description adds slight context ('any file') but mostly echoes schema. Insufficient extra value to raise score.

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 verb 'Read' and resource 'any file from the cloned repositories', and specifies the method 'by path'. It distinguishes from siblings like noir_read_example which reads specific example files.

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 use when needing to read a specific file from repos, but does not explicitly state when not to use or list alternatives. Guidance is minimal.

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?

No annotations provided, so description carries full burden. Mentions search scope and regex support, but does not disclose prerequisites like needing to sync repos first, nor any potential side effects or limitations.

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, each providing distinct value: purpose, capability, and use cases. No unnecessary words, perfectly front-loaded.

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 search functionality, regex, and file pattern. Lacks mention of prerequisite (repos must be synced) and return format. With no output schema, slightly more context on results would be useful.

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%, so baseline is 3. Description adds value by noting regex support for query and default file pattern, but does not enrich beyond schema much.

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 specifies verb ('search'), resource ('Noir source code across all cloned repos'), and scope ('supports regex patterns', '.nr files'). Distinguishes from siblings like noir_search_docs and 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 Guidelines4/5

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

States when to use ('finding function implementations, patterns, and examples'), but does not explicitly state when not to use or list alternatives, which could help given the sibling tools.

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

noir_search_docsA

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

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only states the purpose and target content, with no information about read-only nature, permissions, rate limits, or result handling.

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 two clear clauses, no redundant information, and front-loaded with the key action and resource.

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 straightforward search tool with no output schema, the description adequately conveys the domain and purpose. It lacks details on return format but is sufficient given the tool's simplicity.

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?

All three parameters have descriptions in the input schema (100% coverage). The tool description adds no additional meaning or usage context for the parameters beyond what the schema already 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 it searches Noir documentation and specifies content types: language guides, tutorials, and API documentation. This distinguishes it from sibling tools like noir_search_code and 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 Guidelines4/5

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

The description includes explicit guidance ('Use for finding...') which tells when to use it. However, it does not provide when-not-to-use instructions or mention alternatives, missing some explicit exclusion guidance.

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

noir_search_stdlibA

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

A3.8/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 says 'Search' without indicating whether it's read-only, any auth needs, or rate limits. It does not describe behavior beyond the schema.

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

Conciseness5/5

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

Two sentences that are front-loaded and concise. Every sentence serves a purpose: stating the tool's action and its use case.

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 a simple search tool with 2 parameters and no output schema, the description adequately covers purpose and usage. It is complete enough for an agent to understand when to use this 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 description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides for the two 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 as searching the Noir standard library, using a specific verb and resource. It distinguishes from siblings like noir_search_code and noir_search_docs by specifying the scope is the standard library.

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 states when to use it: 'Use for finding built-in functions, traits, and types available in Noir.' It does not explicitly mention when not to use or alternatives, but the context of sibling tools implies different search scopes.

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

A3.6/5.0

Behavior3/5

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

With no annotations, the description adequately conveys the tool's behavior (checking status). However, it does not explicitly state it is read-only or non-destructive, which would be helpful.

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, front-loaded sentence that is concise and immediately communicates the tool's purpose without extraneous words.

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 zero-parameter status tool, the description fully explains what the output contains. No output schema means the description suffices.

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 exist; schema coverage is 100%. Per guidelines, baseline is 4. No additional parameter information is needed.

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

Purpose4/5

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

The description clearly states the tool checks status of cloned Noir repositories and specifies the output: available repos, categories, commit hashes. It distinguishes from sibling listing tools like noir_list_examples and 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 Guidelines2/5

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

No guidance on when to use this tool versus alternatives. While siblings exist, the description does not provide any usage context or exclusion criteria.

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.1/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It describes the action as cloning or updating, indicates it's a prerequisite for searching, and mentions 'Force re-clone' which implies idempotence. However, it does not disclose potential side effects, required permissions, or error behavior, leaving some gaps.

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

Conciseness5/5

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

The description is concise with three sentences. The first sentence front-loads the main purpose, and each subsequent sentence adds essential information about defaults and categories without unnecessary detail.

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 tool with 4 parameters and no output schema, the description covers the core functionality and parameter usage. However, it lacks information about the return value or success indication, which would be helpful for an agent to know what to expect after running the tool.

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 the baseline is 3. The description adds value beyond the schema by explaining the default sync behavior and how categories work ('Default: syncs core repos', 'Use categories to sync additional repos'), providing context that aids parameter selection.

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's purpose: 'Clone or update Noir repositories locally' with the specific action (sync) and resource (Noir repos). It also distinguishes from sibling tools that are for searching, listing, and reading, establishing a unique role.

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 advises to 'Run this first to enable searching,' providing clear context for when to use the tool. It also explains the default behavior and how to use categories for additional repos, but does not explicitly state when not to use it or mention alternatives among siblings.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

9 tool updatesv1.2.6Jun 12, 2026
- First observednoir_list_examples
- First observednoir_list_libraries
- First observednoir_read_example
- First observednoir_read_file
- First observednoir_search_code
- First observednoir_search_docs
- First observednoir_search_stdlib
- First observednoir_status
- First observednoir_sync_repos

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-06-12 10:36 across 9 tools

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

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
5364
forkast-mcp-docs A
io.github.ForkastPredict
MCP server for querying Forkast documentation
Documentation Access Search Developer Tools
42
proverOAuth
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
10 npm
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 7 months ago (2026-02-27 10:40 UTC)
1,026 npm
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 a month ago (2026-08-10 07:38 UTC)
6
61 npm
5
MIT
@codesift/mcp
Developer Tools Code Analysis Search
rutvikchandla3
A
license
Not graded
quality
D
maintenance
MCP server for local-first lexical code search, providing tools for searching code, finding symbols, and reading chunks from indexed repositories.
Updated 3 months ago (2026-06-26 13:19 UTC)
MIT