nox-mcp
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@nox-mcpRun the tests using Python 3.12"
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.
nox-mcp
A Model Context Protocol (MCP) server that enables AI assistants to run nox sessions. This allows LLMs to discover and execute your project's test, lint, build, and other automation tasks.
Features
Discover sessions — List all available nox sessions with descriptions and Python versions
Run sessions — Execute sessions by name, tags, or keyword expressions
Filter by Python version — Override the default Python version for any session
Structured output — Returns JSON responses for easy parsing by AI tools
Related MCP server: mcp-creator
Installation
Requires Python 3.10+ and nox installed in your PATH.
pip install nox-mcpOr with uv:
uv pip install nox-mcpQuick Start
Configure your MCP client
Add nox-mcp to your MCP client configuration. For example, in Claude Desktop's claude_desktop_config.json:
{
"mcpServers": {
"nox": {
"command": "nox-mcp"
}
}
}Or if using uvx:
{
"mcpServers": {
"nox": {
"command": "uvx",
"args": ["nox-mcp"]
}
}
}Available Tools
Once configured, your AI assistant can use these tools:
nox_list_sessions
List all available nox sessions in the current project.
Returns: List of session objects with name, python version, and descriptionnox_run_session
Run one or more nox sessions.
Parameter | Type | Description |
| list[str] | Session names to run (e.g., |
| list[str] | Filter sessions by tags |
| str | Keyword expression (e.g., |
| str | Python version override (e.g., |
| int | Max seconds to wait (default: 300) |
Example Workflow
Ask your AI assistant: "What nox sessions are available?"
The assistant calls
nox_list_sessionsand shows you the optionsAsk: "Run the tests with Python 3.12"
The assistant calls
nox_run_session(sessions=["tests"], python="3.12")
Requirements
Python 3.10+
nox installed and available in PATH
An MCP-compatible client (Claude Desktop, etc.)
Development
# Clone the repository
git clone https://github.com/rvforest/nox-mcp.git
cd nox-mcp
# Install dependencies
uv sync
# Run tests
uv run nox -s test
# Run all checks
uv run nox -s checkLicense
MIT License — see LICENSE for details.
Available Tools
2 toolsnox_list_sessionsA
List all available nox sessions.
Use this tool to discover which nox sessions are available in the current project before running them. Returns structured session data including session names, Python versions, and descriptions.
Returns: A list of session objects, each containing session metadata like 'session' (name), 'python' (version), and 'description'.
Example response: [{"session": "tests", "python": "3.11", "description": "Run tests"}]
| Name | Required | Description | Default |
|---|---|---|---|
| timeout | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates a read-only operation ('List') and describes the return format with an example, which is sufficient for a listing tool. No destructive behavior is suggested.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with separate sections for purpose, usage hint, return type, and example. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema is fully described via the example, and the single parameter is optional with a default. However, the lack of explanation for the 'timeout' parameter leaves a minor gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'timeout' with a default of 30, but the description does not mention this parameter at all. Since schema coverage is 0%, the description should explain it; its absence is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('all available nox sessions'), clearly stating the tool's purpose. It also contrasts with the sibling tool 'nox_run_session' by implying this is for discovery before running.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this tool to discover which nox sessions are available in the current project before running them,' providing clear context and implied timing. However, it does not explicitly state when not to use it or mention alternatives beyond the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nox_run_sessionA
Run nox sessions.
Use this tool to execute one or more nox sessions in the current project. You can filter sessions by name, tags, or keywords. Use nox_list_sessions first to discover available sessions.
Args: sessions: List of session names to run (e.g., ["tests", "lint"]). Session names must contain only alphanumeric characters, hyphens, or underscores. tags: List of tags to filter sessions (e.g., ["ci", "quick"]). Only sessions matching these tags will run. keywords: A keyword expression to filter sessions (e.g., "test and not slow"). Uses Python expression syntax for matching session names. python: Python version to run sessions with (e.g., "3.11", "3.12"). Overrides the session's default Python version. timeout: Maximum seconds to wait for nox to complete. Defaults to 300.
Returns: A dictionary with 'exit_code' (0 = success), 'stdout', and 'stderr' from the nox command execution.
Example: Run tests with Python 3.11: nox_run_session(sessions=["tests"], python="3.11")
| Name | Required | Description | Default |
|---|---|---|---|
| sessions | No | ||
| tags | No | ||
| keywords | No | ||
| python | No | ||
| timeout | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes basic behavior (running nox sessions) and return values, but lacks details on destructive actions, auth needs, or error conditions beyond exit codes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with intro, args, returns, and example. Front-loaded purpose, every sentence adds value. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers usage, parameters, return values, and example. Output schema exists. Minor gaps: doesn't specify error handling for invalid sessions or timeouts, but adequate for a command-executing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description provides thorough parameter documentation: constraints on sessions (alphanumeric, hyphens, underscores), tags (list), keywords (expression), python version, timeout default. Adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Run' and resource 'nox sessions', specifying execution of one or more sessions. It distinguishes from sibling tool nox_list_sessions by advising to list sessions first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to use nox_list_sessions first to discover sessions, providing clear context. It mentions filtering options but does not explicitly state when not to use this tool.
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. Dates show when Glama detected each change.
2 tool updates
v0.1.0- First observed
nox_list_sessions - First observed
nox_run_session
TDQS
The two tools have clearly distinct purposes: one lists available sessions, the other runs them. There is no overlap or ambiguity.
Both tools follow a consistent verb_noun pattern with 'nox_' prefix (nox_list_sessions, nox_run_session), making them predictable and easy to understand.
With only 2 tools, the server is minimal but appropriately scoped for listing and running nox sessions. It covers the essential interactions without unnecessary complexity.
The tool set is complete for its intended purpose: discovering available sessions and executing them. There are no missing operations since sessions are defined externally in noxfiles.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
- ZapierOAuthcom.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
Related MCP Servers
- AlicenseBqualityCmaintenanceAn MCP server that supercharges AI assistants with powerful tools for software development, enabling research, planning, code generation, and project scaffolding through natural language interaction.1132101MIT
- AlicenseAqualityCmaintenanceA tool that enables AI assistants to conversationally scaffold, build, and publish Python MCP servers to PyPI. It automates the entire development lifecycle, including package naming, tool scaffolding, GitHub repository setup, and package publishing.10MIT
- AlicenseAqualityDmaintenanceAn MCP server that enables AI agents to list and run tasks defined in Taskfile.yml, useful for automated development workflows.24MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server that bridges AI assistants to real terminal sessions, enabling creation, management, and interaction with persistent PTY processes for running commands, monitoring output, and debugging.1MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/rvforest/nox-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server