MCP AIDC problems and fixes

Decide whether the server launch, request validation, AIDC startup, the command itself or the check afterwards failed. Each has its own signal, and fixing the wrong one wastes a retry.

Confirm the executable path and args: ["serve"] in the client configuration, and run mcp-aidc serve --help from the same environment. Keep stdout for the MCP connection and read diagnostics on stderr. A server that seems to hang in a terminal is waiting for MCP messages.

The configured executable or the project directory cannot be used. Pass an absolute executable through --aidc-binary and an absolute, existing projectDir, then restart the server. Do not put extra arguments in the executable string.

A missing action, tool or version is rejected before AIDC runs; refresh tools/list and use the published names. Results use the MCP fields: read isError and the content array, where a completed command's text holds command, exitCode, stdout, stderr and truncated.

Use an absolute projectDir with its intended .aidc.yaml. Individual install failures can leave setup with a successful exit, so read per-tool messages and query the installed versions afterwards. A failed command does not roll back earlier effects.

Query current with the same project directory and check the scope. Session scope follows the shell context the server inherited, not your conversation. Use project scope for a lasting selection.

Upgrade previews by default: review it, then repeat with apply:true and the same target. Uninstall without confirm:true only returns a reminder, not a list of what it would remove. upgrade all:true can succeed with a failed tool, so compare fresh queries with your intended list.

truncated:true means a stream exceeded 16 KiB; narrow the query to one tool. Commands wait up to 15 minutes, and a timeout is not a rollback. Inspect the state before retrying.