Server data from the Official MCP Registry
Review-first stdio MCP for Movi: analyze, review, overlay edit, and dry-run preview.
Review-first stdio MCP for Movi: analyze, review, overlay edit, and dry-run preview.
Valid MCP server (1 strong, 2 medium validity signals). No known CVEs in dependencies. Imported from the Official MCP Registry.
10 files analyzed · No issues found
Security scores are indicators to help you make informed decisions, not guarantees. Always review permissions before connecting any MCP server.
This plugin requests these system permissions. Most are normal for its category.
From the project's GitHub README.
Movi is a review-first local file organizer and workbench for messy photos, screenshots, documents, and audio. It lets AI assist with the manifest first, then lets you inspect, label, and approve the plan before deterministic apply or rollback touches your files.
Safe First Look · 10-Second Tour · Good Fit / Not A Fit · Public Proof · Docs · Distribution · Integrations · Submission Manifest · MCP Descriptor · Review-First Skill Packet · OpenClaw Bundle · Browser Surface · Releases · Discussions · Security · Movi MCP v1 · Codex Integration · Claude Code Integration · Developer Guide
Movi is a review-first local AI file organizer. It turns a chaotic intake folder into a review queue, then into a reviewed manifest, and only then into safer file moves you can dry-run, audit, and roll back. The current shipped surface stays intentionally narrow: Movi Review, Movi Rules, Movi Inbox, Movi Copilot v1, and Movi MCP v1 all describe real current surfaces, but they still stay inside one safety story instead of pretending Movi is an autonomous organizer.
Public maintenance posture: limited-maintenance open source.
Current proof posture: reproducible smoke-tier evidence with a live release trail, Pages front door, and repo-side safety gates. It is not broad benchmark-grade proof yet, but the current front door already clears a truthful public-entry bar, and the proof routes stay explicit in Public Proof instead of being buried in operator-only docs.
Read Movi like a workshop with one front desk and several labeled shelves:
README.md plus the root manifest.yamlserver.jsonexamples/skills/examples/openclaw/docs/mcp.mdapps/mcp/README.mdCleaning up a mixed folder usually fails for one of two reasons: either the tool is too manual, or the AI is allowed to move files before you can inspect the plan.
Movi splits those jobs on purpose:
analyze is where AI helps understand the filesapply is where deterministic rules execute the approved manifestrollback is where you can undo with the same paper trailThink of it like moving house: AI makes the packing list, but the moving crew still follows an approved checklist instead of guessing in the hallway.
If you are asking, "is this a real product surface or just a careful README," the shortest honest answer is:
If you want the full outsider-facing proof map, open Public Proof. If you want the shortest hands-on route, stay on this page and run Safe First Look.
For external readers, Movi keeps one simple language rule:
README.md, DISTRIBUTION.md, INTEGRATIONS.md, manifest.yaml, and any later root truth surface only after it is explicitly synced to the same wording standard.zh-CN for operator comfort, walkthroughs, and day-to-day use.movi-organizer: the repository name and CLI/runtime identity.apply.overlay -> resolved snapshot -> dry-run -> execute.Movi belongs to a very specific lane:
Current honest ecosystem fit:
Movi MCP v1 already ships as a local-first stdio surface with review-safe toolsModeration verdict: suspicious and Detected: suspicious.vt_suspicious.OpenHands/extensions#161; current GitHub state is OPEN / REVIEW_REQUIRED / BLOCKED.block/Agent-Skills#25; validation passed, and the current visible blocker is upstream security review / CODEOWNERS handling.heilcheng/awesome-agent-skills#181; the current visible blocker is upstream preview authorization rather than a missing Movi packet.not_submitted.not_submitted, because Movi is still a review-first local MCP workflow rather than an Opencode-centered project/resource fit.not_published.analyze draft a manifest and a review queue you can triage before touching the file system.apply in dry-run mode until the plan looks right, then rely on rollback-ready receipts if a batch needs to be undone.Movi is built for the frustrating middle ground between "do everything by hand" and "let AI rename files without supervision." The before/after difference comes from review-first planning, not hidden mutation.
| Good fit | Not a fit |
|---|---|
| You want AI help classifying messy folders without giving AI direct file-move authority | You want a zero-review magic organizer that mutates files immediately |
| You need a repeatable audit trail for screenshots, PDFs, photos, and recordings | You want a hosted SaaS with team dashboards and always-on support |
| You care about dry-run, manifest review, and rollback | You need enterprise SLAs or guaranteed support windows |
This safe first look uses the built-in sample fixture set and keeps apply in --dry-run mode. It demonstrates the review-first loop on governed fixture data, not a public-tier benchmark or a recorded human baseline.
bash tooling/runtime/bootstrap_env.sh
mkdir -p .runtime-cache/storefront-demo
MOVI_ALLOW_HOST_EXECUTION=1 bash tooling/runtime/run_analyze.sh \
--offline \
--config ./contracts/runtime/config.example.toml \
--input ./tests/fixtures/golden_input \
--manifest ./.runtime-cache/storefront-demo/manifest.jsonl \
--report ./.runtime-cache/storefront-demo/report.json
cp ./.runtime-cache/storefront-demo/manifest.jsonl ./.runtime-cache/storefront-demo/manifest.apply.jsonl
MOVI_ALLOW_HOST_EXECUTION=1 bash tooling/runtime/run_apply.sh \
--config ./contracts/runtime/config.example.toml \
--manifest ./.runtime-cache/storefront-demo/manifest.apply.jsonl \
--input-root ./tests/fixtures/golden_input \
--output ./.runtime-cache/storefront-demo/output \
--dry-run \
--verify-sha1 \
--report ./.runtime-cache/storefront-demo/apply-report.json
After step 3, inspect:
./.runtime-cache/storefront-demo/manifest.jsonl./.runtime-cache/storefront-demo/manifest.apply.jsonl./.runtime-cache/storefront-demo/report.json./.runtime-cache/storefront-demo/apply-report.jsonWhat this route proves:
analyze -> manifest -> dry-run apply loop works on the canonical fixture packWhat this route does not prove yet:
If this quickstart fails, the next stop is docs/usage.md, which explains the full operator route and runtime expectations.
If you want to explore the workflow as an app instead of a shell session:
npm run dev:stack
That route starts the Web API and WebUI so you can walk through setup, analyze, Movi Review, Movi Rules, apply, report, rollback, and Movi Inbox from the browser.
Inside the current browser flow, Inbox can hand a batch into Analyze, Analyze can hand the drafted manifest into Review, Collection Intelligence v2 helps you judge one batch slice at a time, and Report can send you back into a focused Review pass for conflicts, human-check rows, or learning suggestions.
If you want the public release storyline instead of the repo history, start with the latest GitHub Releases and use CHANGELOG.md for the unreleased lane.
apply and rollback stay deterministic: AI helps plan, not execute arbitrary moves.dry-run, allowed-root, and manifest validation are first-class, not buried extras.If you are wiring Movi into another tool or an agent workflow, use the surface that matches the job:
If you want the shortest client-specific route instead of the generic MCP page:
Think of it like a workshop with three doors: the CLI is the loading dock, the Web API is the control room, and Movi MCP is the supervised service window for agents. None of those doors secretly lead around review.
No. analyze may call Gemini when you are not in offline mode. apply and rollback do not call Gemini.
Yes. The quickstart above uses fixture files and keeps apply in --dry-run mode.
No. Movi is a limited-maintenance open-source repository with a local-first workflow. Bring your own environment and review the manifest before real changes.
Movi now keeps runtime cleanup on four separate rails so a small cache cleanup never turns into a destructive workspace reset or an accidental Docker-wide prune.
bash tooling/cleanup/prune_repo_runtime.sh when you only want to trim repo-side runtime noise such as .runtime-cache and forbidden residue under the checkout.bash tooling/cleanup/prune_machine_cache.sh --safe for the lowest-risk cleanup, --rebuildable for governed host caches, or --aggressive-host when you intentionally want to reclaim the host-side fallback venv under ~/.cache/movi-organizer.bash tooling/cleanup/prune_docker_runtime.sh --dry-run to audit the container-first runtime surface, --rebuildable to prune repo-related build cache, and --aggressive only when you explicitly mean to consider current image or named volumes.bash tooling/runtime/runtime_reset.sh --confirm-workspace-reset is intentionally separate because it also clears workspace .movi state. Treat it like resetting a workbench, not like emptying a cache folder.Container-first default:
movi-ci:local plus movi-web-stack_* volumes).~/.cache/movi-organizer/venv/default is treated as a rebuildable fallback surface, not the long-term primary runtime asset.If review-first cleanup is the workflow you keep wishing existed, star the repo so you can find Movi again when the next messy folder lands.
Delivery-complete truth for the current snapshot still depends on fresh gate evidence, not on static prose.
Treat bash tooling/gates/quality_gate.sh as the delivery-complete receipt for the current snapshot, and treat repository docs as guidance rather than a live platform dashboard.
If you only want the shortest honest map of what is true right now, follow these four routes:
Public readiness gates:
bash tooling/gates/public_readiness_gate.sh repobash tooling/gates/public_readiness_gate.sh releaseAuto-generated: the current source package version comes from
pyproject.toml.current-head releaseboundaries depend on local/CI runtime evidence, and a clean checkout does not carry a repo-local release evidence summary by default.
4.0.5v4.0.5requires_local_release_evidenceunknown in clean checkoutnpm run release:truth, then read current_head_release_truth.status before making current-head release claims.published_release_verified can be described as a verified published closure.Auto-generated: runtime services, default ports, runtime paths, and entrypoint facts live in generated runtime topology.
movi-ci, movi-web-api, movi-webuiloopback:18080loopback:5173<workspace-root><repo-runtime-cache>Auto-generated: current Web API facts come from
contracts/api/web_api.openapi.yaml; the full method/path list lives in generated reference.
/api/jobs, /api/jobs/history, /api/jobs/stream, /api/jobs/{job_id}, /api/jobs/{job_id}/review-queue, /api/jobs/{job_id}/review-queue/batch-triage, /api/jobs/{job_id}/review-rules/apply, /api/jobs/{job_id}/review-rules/from-examples, /api/jobs/{job_id}/review-rules/preview/api/jobs/{job_id}/events, /api/jobs/{job_id}/events/stream, /api/jobs/{job_id}/stream/api/jobs/{job_id}/manifest, /api/jobs/{job_id}/manifest/batch, /api/jobs/{job_id}/manifest/conflicts, /api/jobs/{job_id}/manifest/conflicts/resolve, /api/jobs/{job_id}/manifest/rows/{row_id}, /api/jobs/{job_id}/manifest/view, /api/jobs/{job_id}/manifest/{row_id}/preview/api/jobs/analyze, /api/jobs/apply, /api/jobs/rollback, /api/jobs/{job_id}/cancel, /api/jobs/{job_id}/retry/api/jobs/{job_id}/audit, /api/jobs/{job_id}/report/api/preferences/learned-rules, /api/preferences/naming-templates, /api/preferences/review-rules, /api/preferences/runtime, /api/preferences/runtime/validate, /api/preferences/strategy-packs, /api/preferences/views, /api/preferences/watch-sourcesoverlay / resolved snapshot are internal model and file-output concepts, not stable public HTTP routes.Auto-generated: CI truth-chain, failure-domain policy, navigation entrypoints, and executable gate facts come from required checks matrix, runner contract, and ci.yml.
build-ci-image -> change-detection -> {webui-build-test, quality-gate-full} -> functional-gate -> testquality-gate-fullwebui-build-test (frontend correctness), functional-gate (critical smoke), test (Python version parity)pre-commit bootstraps directly on hosted runners, while live-integration and mutation-manual reuse reusable-build-runtime-image.yml; runtime image build keeps provenance artifact wiring when the platform supports attestations.nightly-drift-audit.yml, collect_ci_run_metrics.py, generate_ci_evidence_bundle.py.npm run ci:local writes repo-local CI metrics, a repo-local evidence bundle, and governed upstream receipts under the repo-local runtime cache directory; these are local derived reports, not Branch Protection truth. Read truth.truth_class, truth.remote_traceability, and truth.authoritative_terminal_receipt before treating the bundle as anything stronger. Older pass receipts remain historical audit evidence only; current closeout wording must follow the latest canonical terminal receipt.bash tooling/gates/pre_push_gate.sh (standard/strict/full) for fast local feedback before remote CI.Be the first to review this server!
by Modelcontextprotocol · Developer Tools
Read, search, and manipulate Git repositories programmatically
by Toleno · Developer Tools
Toleno Network MCP Server — Manage your Toleno mining account with Claude AI using natural language.
by mcp-marketplace · Developer Tools
Create, build, and publish Python MCP servers to PyPI — conversationally.
by Microsoft · Content & Media
Convert files (PDF, Word, Excel, images, audio) to Markdown for LLM consumption
by mcp-marketplace · Developer Tools
Scaffold, build, and publish TypeScript MCP servers to npm — conversationally
by mcp-marketplace · Finance
Free stock data and market news for any MCP-compatible AI assistant.