feat: add MCP server for artifact cleanup

[NotYash1066]

Summary

• add an irona --mcp stdio Model Context Protocol server
• expose scan_artifacts and clean_artifacts tools backed by the existing scanner/deleter logic
• document MCP client configuration and recommend adding Cargo's bin directory to PATH so configs can use command = "irona" instead of a local absolute binary path

Closes #16

Verification

• cargo test passed: 54 tests
• pre-commit hook passed: fmt, clippy, build
• installed binary smoke-tested with MCP initialize and tools/list
• tested the MCP connection in Codex; Codex discovers the irona tools and scan_artifacts / clean_artifacts work end to end

Notes

This intentionally keeps cleanup destructive only through explicit clean_artifacts path arguments; scan_artifacts is read-only.

[kunjee17]

Thanks for this — the MCP layer is well built. The JSON-RPC framing is correct, notifications properly get no response (message.get("id")? returning None is the right shape), the tool definitions carry real outputSchema and annotations rather than the bare minimum, and you kept it to a single new dependency with hand-rolled JSON, which fits how the rest of this codebase is written. 54 tests passing and clippy clean on my machine too.

Two things came up in review that I wanted to explain rather than just point at.

clean_artifacts will delete any path it is given

Caller-supplied strings go straight to remove_dir_all with nothing in between:

let path = PathBuf::from(path);
sizes.push(scanner::dir_size(&path));
original_paths.push(path.clone());
delete_inputs.push((index, path));   // no validation

I tested it against the built binary rather than assuming. A plain directory with a text file in it and no marker file:

$ echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"clean_artifacts",
  "arguments":{"paths":["/tmp/irona-notartifact/my-documents"]}}}' | irona --mcp
{"result":{"structuredContent":{"deleted_count":1,"total_freed_bytes":10, ...

Gone.

I read your note that cleanup is "destructive only through explicit clean_artifacts path arguments", and in a normal CLI that reasoning would hold — the caller typed the path. What makes this different is that the caller is a model. The argument is generated, not typed, so it can be wrong from a hallucination or from something the model read earlier in the session. destructiveHint: true helps, but it is advisory and clients are not obliged to confirm on it, so there is no backstop when they don't.

The fix is small: canonicalize each path and check it against the scanner's own detection before deleting.

The scanner refactor cost the TUI its streaming

Turning par_iter().for_each(|..| tx.send(..)) into par_iter().map(..).collect() means nothing is sent until the whole parallel phase finishes. dir_size is the slow part — it walks every file under each candidate — and the TUI used to fill in progressively while that ran. Now the list stays empty until the entire scan completes, which is very visible on a large workspace.

Both callers can be served by pulling phase 1 into a shared helper: scan keeps streaming, scan_artifacts collects.

Where this landed

I could not push to your fork branch from my environment, so rather than leave this waiting I opened #19, which carries your commit forward unchanged with one fix commit on top addressing both points, plus tests. Your authorship is preserved in the history. I'm closing this one in favour of that.

Genuinely nice work — the issues above are about the trust boundary an MCP tool sits on, not about the implementation. Two smaller things I left alone and noted on #19 as follow-ups: initialize echoes back whatever protocolVersion the client sends including unsupported ones, and scan_artifacts has no cap on result count, so scanning a large tree could return a lot of entries into a model's context.

[kunjee17]

Landed via #19 — your commit carried forward with a delete guard on clean_artifacts and the TUI's streaming scan restored. The MCP layer itself shipped essentially as you wrote it. Thanks for building this.