Coding tools vs runtime tools
Codex / Cursor · coding tools
Inspect the repository, understand and edit code, and run repository tests using the coding agent’s own tools.
Unfour MCP · runtime tools
Reproduce API behavior, inspect SSH/server evidence, query database state, inspect workspace/environment context, and re-run runtime checks through policy-controlled operations.
A passing repository test does not by itself confirm behavior in the target environment. The agent can use Unfour tools to gather that evidence and check a reviewed change, while you control resource scope and risky actions. Unfour does not edit the repository, act as an IDE, or run a full coding agent or CI/CD verification pipeline.
Example: verify a POST /orders code change
- 1. Code change
- 2. API returns 500
- 3. SSH evidence
- 4. Database state
- 5. Reviewed change
- 6. Re-run request
- 7. Verify
-
Codex changes POST /orders with its own tools
Codex edits the repository and runs relevant repository tests using its coding tools. Start or deploy the changed service through your normal development process, then confirm the test API, SSH connection, and database all point to that environment. Unfour does not manage this code or deployment step.
-
Unfour MCP sends the saved request; the API returns 500
Have the agent send the saved POST /orders request through approved Unfour MCP tools. In this example it returns 500. Capture the response, timing, resolved environment, and relevant identifiers as the reference for later checks.
-
Inspect server or runtime evidence
Have the agent use approved Unfour SSH tools to inspect a focused log excerpt, process state, or configuration evidence for the request’s time window. Compare the relevant identifiers; Unfour does not automatically match requests to log lines.
-
Check relevant database state
Use a focused read-only query through Unfour MCP to check relevant order records, relationships, or constraints. Compare the API and server evidence against this database state; do not edit rows simply to hide the symptom.
-
Review the proposal; Codex changes code with its own tools
The agent compares the selected evidence and proposes a bounded fix. The developer reviews it; Codex applies the reviewed code change and runs relevant tests using its own tools. Make the changed service available in the same test environment before runtime verification.
-
Re-run the original check
Have the agent re-send the saved request through Unfour MCP against the same environment, with equivalent test inputs and a reviewed side-effect/idempotency plan. Keep the original expected behavior as the comparison target.
-
Verify the response and relevant database state
Compare the response status and body with the expected result, then repeat the focused read-only database check to confirm the intended state. Record any remaining failures or uncertainty; one successful request is not full CI/CD verification.
Where Unfour fits
Unfour keeps the investigation in one desktop workspace. The tools remain useful on their own; MCP adds a controlled way for a compatible agent to query approved capabilities and connect evidence across them.
API Client
Provides the reproducible request, resolved environment, response details, timing, and redacted history that define the visible symptom.
SSH
Provides direct terminal access and approved diagnostics for application logs, process state, configuration evidence, remote files, and saved tasks.
Database
Provides schema and record evidence through saved SQLite, PostgreSQL, and MySQL connections, starting with focused read-only queries.
Local stdio MCP and workspace context
Lets a compatible client work through the active local workspace, environment policy, saved resources, and Unfour command boundaries.
Safety boundaries to keep visible
- MCP tools operate on resources saved in the selected Unfour workspace instead of unrestricted global resources.
- The default auto policy maps production environments to read-only access with safe SSH diagnostics; review any explicit policy override before use.
- When policy or backend safety requires confirmation, review the exact SQL, URL, command, path, or patch content. Full access does not guarantee a prompt for every risky action.
- SSH/database credentials are resolved through local secret storage when an operation needs them. MCP blocks secret-reveal operations, but arbitrary logs and result text still need review before sharing.
- Sensitive request, response, result, and activity fields are masked or redacted where supported.
When MCP is useful
API 500 or timeout
The request is reproducible, but the explanation requires server logs, runtime state, or a downstream database check.
Unexpected database state
The API response and stored records disagree, and identifiers or timestamps need to be traced across layers.
Server-side configuration problem
Behavior differs because process state, environment variables, deployed configuration, or a remote file does not match expectations.
Environment-specific reproduction
The same workflow behaves differently across dev, test, or production and the target context must stay explicit throughout the investigation.
When manual tools are better
MCP adds the most value when evidence must be gathered, compared, and repeated. Direct use is usually faster when no cross-layer reasoning is needed.
- Send a simple one-off API request directly in the API Client.
- Run a quick, well-understood SSH command in the terminal.
- Inspect a small table or execute a basic read-only SQL query yourself.
- Prefer manual control when the answer is already known and AI reasoning would add ceremony rather than insight.