A typical MCP-assisted troubleshooting loop
- 1. API symptom
- 2. Server evidence
- 3. Database state
- 4. Correlate
- 5. Fix or propose
- 6. Verify
-
Reproduce the API symptom
Run the request against the intended environment and capture the status, response, timing, and resolved request details. A reproducible symptom gives every later check a stable reference.
-
Inspect server or runtime evidence
Use approved SSH diagnostics or direct terminal access to examine the logs, process state, and configuration evidence relevant to the request.
-
Check relevant database state
Start with a read-only query that tests the current hypothesis. Look only at the records, relationships, or constraints connected to the failing request.
-
Correlate the evidence
Compare timestamps, identifiers, environment names, error messages, and persisted state. The goal is a supported explanation, not a larger pile of unrelated output.
-
Make or propose a fix
The agent can summarize likely causes or propose a bounded change. The developer reviews the evidence and decides whether to edit code, configuration, or data.
-
Re-run the original check
Send the same request again in the same environment. Confirm the original symptom is gone and that the response now matches the expected behavior.
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 shared 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.
- Guarded or high-risk actions require confirmation bound to the exact SQL, URL, command, path, or patch content.
- Credentials are resolved behind local credential boundaries only when an approved operation needs them; MCP tools do not return raw credential values.
- 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.