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., "@nock resolve: create a new file called test.txt" 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.

nock

by wrong-nebula

Overview Schema Source Related Servers Discussions Admin

Python

Local

Nock

Nock sits between a coding agent (ChatGPT / Codex, Cursor, Claude Desktop, …) and your local tools.

The cloud model does the thinking. A tiny on-device model (Needle) tries to pick the right tool. Destructive actions wait for a confirm token. If Needle is unsure or the request is off-topic, Nock refuses without sending your tool list to the cloud.

The host only sees four tools: nock.resolve, nock.call, nock.search, nock.status.

Install

python3 -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"

Optional — so nock.resolve can pick tools instead of always refusing:

pip install -e ".[needle]"

That extra pulls JAX. First resolve also downloads the ~14 MB Needle engine.

Related MCP server: agentic-governance-gateway

Point Codex / ChatGPT desktop at it

They share ~/.codex/config.toml. Easiest:

codex mcp add nock -- /ABS/PATH/nock/.venv/bin/nock serve --warmup

Use the absolute path to the venv nock binary. Restart the app, then /mcp should list nock.

Your tools live here, not in Codex

~/.config/nock/config.toml:

[discover]
include_host_configs = false

[servers.fs]
command = "npx"
args = ["-y", "@modelcontextprotocol/server-filesystem", "/ABS/PATH/to/a/folder"]
default_risk = "safe"

[servers.fs.tools.write_file]
risk = "destructive"

Keep Codex’s MCP list to Nock only. Nock starts the filesystem (and anything else you add).

How the host should use it

nock.resolve with the user text.
fast → nock.call the returned envelope.
shortlist → pick one of the listed tools, then nock.call.
escalate → answer without tools. Do not call nock.search.
If nock.call returns type: nock.confirm, call again with confirm=true and confirm_token.

Reads should not confirm. Writes should.

Commands

nock serve          # stdio MCP server (what the host launches)
nock status         # dry config check (does not talk to a running serve)
nock doctor         # binaries, Needle, duplicate servers
nock hosts          # copy-paste snippets for Codex, Claude, Cursor, Continue
nock index          # warm Needle’s tool index

Tests

pytest

MIT. Needle is a separate project from Cactus Compute.

Available Tools

4 tools

nock.callCall a namespaced upstream MCP toolB

Destructive

Proxy tools/call to an upstream server. Destructive tools return a confirm card unless confirm=true and confirm_token matches.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`server`	Yes
`confirm`	No
`arguments`	No
`confirm_token`	No

TDQS

B3.2/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description adds valuable detail: 'Destructive tools return a confirm card unless confirm=true and confirm_token matches.' This goes beyond the annotation by explaining the confirmation gate. No contradiction found.

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 short sentences that front-load the core purpose and add a key behavioral note. Every word earns its place; no redundancy or filler.

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?

With 5 parameters, no output schema, and a sparse description, the tool lacks explanations of parameter structure and return values. The description does not cover how arguments are passed or what the call returns, making it incomplete for reliable invocation.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It only implicitly references confirm and confirm_token via the confirmation rule, but does not explain server, name, or arguments. An agent cannot infer how to populate these parameters from the description.

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 'Proxy tools/call to an upstream server' which specifies the action and resource. However, it doesn't explicitly differentiate from sibling tools like nock.resolve or nock.search, so it misses the opportunity to disambiguate.

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?

There is no guidance on when to use this tool versus alternatives. The description only states the generic proxy action, leaving the agent to infer the appropriate context for calling vs. resolving, searching, or checking status.

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

nock.resolveResolve a user utterance to a local toolA

Read-only

Map natural language to one leaf tool call against the local MCP catalog. One hop only. On mode=fast, pass the envelope to nock.call. On mode=shortlist, pick from shortlist. On mode=escalate, do not ask for more tools and do not invent catalog names.

ParametersJSON Schema

Name	Required	Description	Default
`k`	No
`text`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds meaningful behavioral constraints: 'One hop only,' 'do not ask for more tools,' and 'do not invent catalog names.' This adds transparency about limitations and expected behavior beyond the annotations.

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 concise at three sentences and front-loads the core purpose. However, it uses undefined jargon ('envelope,' 'shortlist') that could be clarified without much additional length, so it is efficient but slightly cryptic.

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?

The description covers the tool's routing logic and mode-specific behavior, and the presence of an output schema covers return values. Yet it leaves gaps such as the meaning of 'k,' how mode is determined, and what happens in error or edge cases. For a 2-parameter tool with 0% schema coverage, more context would be needed for fully reliable invocation.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate, but it does not explain the 'text' or 'k' parameters at all. It introduces terms like 'envelope,' 'shortlist,' and 'mode' without connecting them to the schema, leaving the agent without meaningful parameter-level guidance.

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 states a specific verb and resource: 'Map natural language to one leaf tool call against the local MCP catalog.' It distinguishes itself from siblings by naming nock.call and by describing mode-specific routing, making its role clear relative to nock.search and nock.status.

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 gives explicit mode-based guidance (fast, shortlist, escalate) and tells the agent what to do in each case, including 'pass the envelope to nock.call' and 'do not invent catalog names.' It lacks a direct contrast with nock.search or nock.status, and the modes are not present in the schema, but the routing instructions are specific and actionable.

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

nock.searchSearch the local tool catalogA

Read-only

Return up to k MCP Tool objects matching query via the local Nock ranker. Does not execute anything. Disabled by default.

ParametersJSON Schema

Name	Required	Description	Default
`k`	No
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior4/5

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

Annotations already provide readOnlyHint=true, and the description reinforces this with 'Does not execute anything.' It adds useful context beyond annotations with 'local Nock ranker' and 'Disabled by default,' which are not expressed in the structured metadata. No contradiction with annotations.

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 short sentences, each with a clear purpose: the main action, the safety caveat, and the operational default. Nothing is redundant or wasted.

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 that an output schema exists and read-only annotations are present, the description is mostly complete. It covers purpose, non-execution, and the important 'Disabled by default' caveat, though it does not explain what 'disabled' means for invocation or how to enable it.

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 0%, so the description must carry parameter meaning. It does clarify that 'query' is the search text and 'k' limits the result count, but it leaves details such as null behavior, query syntax, and ranking semantics unspecified.

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 uses a specific verb and resource: 'Return up to k MCP Tool objects matching query via the local Nock ranker.' It clearly scopes the operation to the local tool catalog and distinguishes it from 'execute' style siblings with 'Does not execute anything.'

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?

Usage is implied rather than explicit: an agent can infer this is for searching the local catalog without executing, but the description gives no direct when-to-use or when-not-to-use guidance and does not name alternatives like nock.resolve or nock.call.

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

nock.statusNock sidecar healthA

Read-only

Mux health, catalog size, last index time, Needle load state. No secrets.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe read operation. The description adds value by explicitly stating 'No secrets' – a behavioral guarantee that the response won't contain sensitive data. It also lists the specific data categories returned, which helps the agent know what to expect. This goes beyond the annotations.

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?

One short sentence that front-loads the purpose and lists the key data points. 'No secrets' is a valuable safety note. Zero waste.

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 zero-parameter read-only health check with an output schema present, the description is nearly complete. It tells the agent what data will be returned and that no secrets are included. The only minor gap is not describing the output format, but the output schema exists and the description needn't explain return values. The sibling tools are all operational (resolve, call, search), so the health-check purpose is clear.

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?

The tool has 0 parameters, so the schema is trivially complete. The description doesn't need to explain parameters. The baseline for 0 params is 4, and the description adds context about what the tool returns, which is more useful than parameter docs would be.

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 names a specific resource (Nock sidecar) and a clear verb (health check), and lists the specific data points returned: Mux health, catalog size, last index time, Needle load state. It distinguishes itself from siblings like nock.call and nock.search by focusing on health/status rather than operations. It doesn't explicitly name a sibling, but the resource+verb is clear enough.

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 this is for checking health/status of the Nock sidecar, which is a common diagnostic use case. It doesn't explicitly state when to use this vs nock.resolve, nock.call, or nock.search, but the health/status focus makes the usage context reasonably clear. No exclusions or alternatives are named.

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.

4 tool updatesv0.1.0Sep 21, 2026
- First observednock.call
- First observednock.resolve
- First observednock.search
- First observednock.status

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-09-21 20:15 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct role: resolve handles natural-language routing, call executes concrete tool envelopes, search retrieves catalog metadata without executing, and status reports health. No two tools appear to do the same thing.

Naming Consistency5/5

All tools share the consistent nock.* prefix and use short, lowercase action-oriented names. The pattern is uniform and predictable across the set.

Tool Count5/5

Four tools is well-scoped for a gateway/catalog server: discovery, resolution, execution, and status. Each tool earns its place with no redundancy.

Completeness5/5

The tool surface covers the full proxy lifecycle: search the catalog, resolve natural language to a call, execute via upstream, and check server health. No obvious missing operation for the stated purpose.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Remote MCP A
com.remote-mcp.mcp
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Developer Tools Search Agent Orchestration
13
gatewayOAuth
ai.sealgate
MCP gateway with runtime security policy, tool-call-level control, and audit of agent actions.
Security Agent Orchestration
11
Doriku
io.doriku
Shared control plane for AI coding agents — tasks, memory, decisions, file locks. 12 tools.
Project Management Autonomous Agents
2
IdentArk Gateway
io.identark
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
Security Agent Orchestration
29

Related MCP Servers

projscan
Developer Tools Code Analysis Autonomous Agents
abhiyoheswaran1
A
license
Not graded
quality
A
maintenance
An MCP server that provides AI coding agents with AST-accurate, context-budget-aware codebase querying, safety gates, and team policy integration via structured tools and a local plugin layer.
Updated 2 months ago (2026-07-20 08:13 UTC)
65 npm
4
MIT
agentic-governance-gateway
Security Observability Developer Tools
TH07008
A
license
Not graded
quality
B
maintenance
An MCP server that provides a governance layer for coding agents, enforcing policies, validation, and human-in-the-loop for tool calls without requiring an API key.
Updated 2 months ago (2026-08-07 15:35 UTC)
MIT
worker-mcp
Agent Orchestration Coding Agents
noosxe
A
license
A
quality
A
maintenance
MCP server that enables a coordinator AI agent to spawn, control, and supervise local coding agents with interactive gating for high-risk operations.
Updated a day ago (2026-09-23 13:11 UTC)
10
4 npm
MIT
toke-local
Code Analysis Code Execution Version Control
rianprei
A
license
Not graded
quality
B
maintenance
A local, zero-dependency MCP server that cuts coding-agent round-trips by aggregating search, read, edit, exec, git, and savings tools into single, validated calls, with cost tracking and no data leaving the machine.
Updated a month ago (2026-08-09 03:57 UTC)
1
MIT