Labsco
MCP SERVER

TokRepo MCP Server

by henu-wang

Find a reusable skill, prompt or script for the task at hand, install it into the repo with verification and a rollback path, and push back what the session produced.

Package Registries & Dependency Supply ChainVerified
Summary
Every destructive tool defaults to a dry run and the install path has a named escape — this is a surface designed on the assumption that the caller is an agent that will get something wrong.

Installing third-party assets into a repository automatically is the kind of capability that goes badly once and then nobody uses it again. The design here is unusually careful about that: verification is its own read-only step before the write, update and uninstall are dry runs unless told otherwise, rollback is a first-class tool rather than a git suggestion, and push requires naming the files rather than uploading a directory. The session-init cap is the other detail worth noting — 500 tokens, once, rather than a catalogue riding along on every turn. The vocabulary is its own and the tools carry it, which is a fair trade for machinery this specific.

What it is

A client for TokRepo, a store of AI assets — skills, prompts, MCP configurations, scripts and workflows — organised around three atomic actions: find one for a task, install it safely, and harvest what the agent just created.

What you get
  • tokrepo_session_init is called once at session start and caps its own response at 500 tokens, returning the high-trust assets relevant to the repository rather than a catalogue.
  • Discovery has two entry points: tokrepo_find_for_task for a concrete task, and tokrepo_discover plus tokrepo_resolve_capability for planning time, when the gap is a capability rather than a task.
  • Installation is four steps and each is separate: a plan, a read-only trust verification, the install itself, and a rollback that the tool text calls the escape.
  • tokrepo_update and tokrepo_uninstall both default to dry_run=true, so the destructive form has to be asked for explicitly.
  • tokrepo_installed reads the local manifest with file status, so what was installed is knowable without inspecting the tree.
  • The harvest half: tokrepo_handoff_plan inspects local files and returns a packaging plan with a quality gate, tokrepo_harvest runs at the end of a task, and tokrepo_push sends one asset with you choosing exactly which files go.
  • tokrepo_edges returns the asset relationship graph, inbound and outbound, so a dependency is visible before it is pulled in.
Requirements

Nothing to supply for discovery and installation.

Setup effort

One command — npx -y tokrepo-mcp-server