Loading ToolBench
This is not an MCP server. Nox is a CLI-based security scanner (written in Go) that analyzes code for AI application security vulnerabilities. The three tools (analyze, validate, llm_triage) are NOT registered MCP tools, they appear only in test file names (plugin/safety_pertool_test.go) with no visible tool definitions, schemas, input parameters, or output structures in the provided source. The codebase shows a Dockerfile, Makefile, VSCode extension configuration, example project files, and Go module declarations, but NO evidence of MCP protocol implementation, tool registration, or MCP server scaffolding. The server lacks: (1) any MCP-compliant tool registration mechanism, (2) input/output schemas for the three claimed tools, (3) parameter descriptions, (4) error handling patterns, (5) protocol implementation. Without access to the actual Go implementation files (main.go, server initialization, tool handler code), schema definitions cannot be verified. The claim that this is an MCP server appears to be a miscategorization, nox is a security scanner CLI, not an MCP server.
Analyze security findings from plugin capability
Execute LLM-based triage on security findings
Validate security requirements for tool invocation
No tool schemas found. All three tools claimed to exist but no input/output JSON Schema definitions are visible in the provided source code.
Tool definitions not visible in source code. The three tools are inferred from test file names (plugin/safety_pertool_test.go) with no explicit registration, handler code, or parameter binding shown.
Generic/ambiguous tool names. 'analyze' and 'validate' are weak verbs that do not clearly distinguish what action is performed. LLMs struggle to select the right tool when names are overlapping or generic. Per pattern:tool-naming, names should start with a specific action verb and clearly indicate the outcome.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 26 | 2026-07-28+ | v2 |
Insufficient parameter descriptions. No parameter documentation is visible for any of the three tools. Per pattern:tool-description, every input parameter must have a description explaining what it controls. Without this, LLMs cannot determine valid inputs or expected formats.
No error handling or recovery guidance documented. The three tools provide no indication of what errors they may return, whether failures are retryable, or what the LLM should do next. Per pattern:recovery-guide, error responses must tell the agent what to do.
Missing output schema documentation. No documentation of what fields, types, or structure the three tools return. Per pattern:tool, tool responses must be documented so LLMs can plan downstream tool calls and extract the right data.
WRITE tools lack confirmation/dry-run pattern. Both 'validate' and 'llm_triage' are marked as WRITE (state-modifying) but no confirmation or dry-run mechanism is documented. Per pattern:confirmation-request, irreversible operations should support confirmation.