Loading ToolBench

Reading the current corpus…

cortex MCP server · C · ToolBench

cortex

Rust pre-apply verification gate for coding AI with MCP (Model Context Protocol) server support for Claude Code, Cursor, and other AI editors

<=2025-11-25STDIO2 tools

60/100

Definition Quality80

Protocol Readiness47

Supportability35

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · detected: Logging

Deprecated protocol patterns detected

Summary

Two tools with clear, domain-specific names (propose_edit, propose_batch) and detailed descriptions (100+ chars each). Input schemas are fully visible with typed parameters and descriptions. However, output schemas are not documented, LLMs cannot predict what these tools return. Error handling guidance is minimal. The descriptions are strong on WHAT (write files, atomic batch) and WHY (greenfield projects, verification sandbox), but lack explicit guidance on when to use each tool or what happens on failure. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite both being destructive WRITE operations.

Tools (2)

propose_batchwritesource verified80/100

Write MULTIPLE files atomically in a single call. ALL files are applied to the verification sandbox together, then `cargo check` runs ONCE. This is the correct tool for greenfield multi-file projects where each file depends on its siblings (lib.rs declares mods, main.rs uses lib, etc.). Put EVERY file the project needs into the `files` array in ONE call.

propose_editwritesource verified80/100

Write or overwrite a SINGLE file. For greenfield multi-file work (creating a new project) you MUST use propose_batch instead — individual propose_edit calls will be rejected by the verifier because each file alone doesn't compile without its siblings.

Issues (5)

HIGHtool ↗

Output schemas not documented. LLMs cannot predict return types, fields, or structure. Both tools lack documented responses.

propose_editpropose_batch

HIGHtool-annotations ↗

No tool annotations despite destructive WRITE risk. Missing readOnlyHint=false and destructiveHint=true would help agents reason about side effects and retry safety.

propose_editpropose_batch

HIGHrecovery-guide ↗

Error handling guidance absent. Descriptions do not explain what happens on validation failure, compilation error, or file conflict. LLMs have no recovery path.

propose_editpropose_batch

MEDIUMtool-description ↗

Tool selection guidance incomplete. Description of propose_edit warns against multi-file greenfield work but does not explain when propose_batch is preferred or how to decide between them.

propose_edit

Recommendations

Document output schema for both tools. Specify: success boolean, verification_result object (passed: bool, errors: string[]), file_paths: string[], compilation_output: string. This enables agents to check verification status and extract error details.
Add tool annotations: readOnlyHint=false, destructiveHint=true, idempotentHint=false. This signals to agents that these calls modify state, should not be retried blindly, and require careful planning.
Enhance error handling in descriptions: 'On verification failure, returns errors array with line numbers and messages. Agent should revise content and retry. On file conflict, returns conflict details, agent must resolve before proceeding.'
Add explicit decision guidance: 'Use propose_edit for single-file changes. Use propose_batch when creating a new project where files depend on each other (e.g., lib.rs declares mods, main.rs uses lib). Batch ensures all files compile together.'
Consider adding a dry_run parameter (boolean, default false) to both tools. When true, runs verification without persisting changes, letting agents preview errors before committing.

Spec posture evidence

Inferred effective spec: <=2025-11-25.

Relies on Logging (deprecated) - log to stderr or use OpenTelemetry

Score history

Overall score trend

First recorded score · v2 rubric

60/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	C	60	<=2025-11-25	v2