The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Sippion listing page.
English | 日本語
Sippion is a local, read-only MCP server that helps AI coding agents find the right parts of a repository before they start opening source files broadly. Its primary job is to organize and bound repository context before it is passed to an AI model, so clients avoid spending model-input tokens on irrelevant source while preserving the evidence needed to solve the task.
Sippion exposes one MCP tool, repo_context, which combines bounded lexical search,
structural context, and source-only semantic ranking to return a small,
relevant set of code excerpts.
Install Sippion with one command. The bootstrap verifies its downloaded
installer checksum and GitHub artifact attestation before executing the
installer. The installer then verifies the selected binary checksum and its
GitHub artifact attestation before installing it and running transactional
sippion setup.
The default path fails closed unless the GitHub CLI (gh) is installed, has
gh attestation support, and can authenticate to GitHub. This deliberately
keeps release provenance verification enabled on the primary install path.
After installation:
Both attestation checks are bound to the Sippion repository, the expected release signer workflow, and the exact commit SHA resolved from the selected release tag.
Sippion pre-registers all three clients, even if one is not installed yet.
Each client launches Sippion with --root-auto. Sippion selects the nearest
recognized Git/project boundary and refuses automatic selection of the user's
home directory or filesystem root. On Unix, shared group/other-writable
ancestor directories are not trusted as automatic boundaries. On Windows,
--root-auto is deliberately limited to projects under the canonical current
user profile because Sippion cannot safely verify arbitrary shared-directory
ACLs through stable safe Rust APIs; trusted projects elsewhere can use an
explicit --root. You do not need to register Sippion separately for every
repository under the normal automatic scope.
A checksum-only direct installer mode remains available as an explicit opt-out for controlled environments where provenance was verified by another trusted mechanism. See Security and trust boundary.
Sippion is published in the Official MCP Registry as
io.github.Sitten-Tokyo/sippion. The canonical Registry record can be inspected
through the stable API at
the latest Sippion Registry entry.
Each release intended for Registry distribution contains four checksummed, provenance-attested MCPB bundles alongside the native binaries:
The MCPB manifest asks the host for an explicit project root and launches the
same local stdio server. The bootstrap + sippion setup path above remains the
recommended route when you want Sippion to configure Codex, Claude Code, and
Antigravity automatically; Registry/MCPB distribution is an additional
standards-based installation and discovery channel.
A client can ask Sippion for focused repository context such as:
Sippion returns bounded excerpts and structural evidence instead of dumping a large part of the repository into the model context.
Typical flow:
This is useful for large repositories, unfamiliar codebases, and multi-agent workflows where broad source exploration would otherwise consume time and context.
Optional session_id and agent_id values can coordinate cooperating agents
in process memory. They are not persisted.
Sippion itself is:
It does not run repository code, proxy model traffic, store provider credentials, start a daemon, or modify the repository.
Repository reads are bounded, reject symlinks and unsafe hard links, revalidate source identity around reads, and redact high-confidence secrets before output. Repository text is treated as untrusted data, not as instructions to the AI.
For the full trust boundary and installation trust model, see Security and trust boundary.
sippion setup configures the current user for:
Restart an already-running client after installation so it reloads its MCP configuration.
Useful commands:
setup is idempotent and transactional across the managed client files. It
refuses to rewrite a Sippion-managed text block if its management markers are
missing, duplicated, or out of order, rather than risking unrelated user
settings. Managed files and their managed parent directories are refused when
they are symlinks. On Unix, MCP client configuration files are created or
repaired as owner-only 0600; rollback also restores the previous permission
bits. Persistent .sippion-backup copies are not created, and legacy copies
from older releases are removed transactionally. If any client update fails,
files touched by that setup attempt are restored.
doctor checks registration health and exits non-zero when any expected
registration is unhealthy. uninstall is transactional too: it snapshots the
managed configuration/rule files before removal and restores the pre-attempt
state if any removal fails. It removes Sippion-managed client configuration and
rules but does not remove unrelated settings or the binary.
See Client setup for manual configuration and diagnostics.
To infer a safe project root from the current directory:
Automatic discovery uses the nearest recognized Git/project marker. It does not
continue past a nearer project manifest merely to find a farther .git marker;
on Unix it also stops before trusting a group/other-writable shared directory.
Resolving the current user's home directory is part of the safety check, so
failure to resolve it stops automatic discovery instead of silently disabling
the home/ancestor guard.
On Windows, --root-auto is limited to projects under the canonical current
user profile. To use a trusted project elsewhere, bind it explicitly:
Home-directory, filesystem-root, and home-ancestor scans are rejected by
default. An intentional broad manual scan requires the explicit
--allow-broad-root opt-in. Setup never enables that override.
To lower the adaptive scan ceiling:
Retrieval starts with a RAM-only lexical index, expands scan work only while the previous round is still yielding useful evidence, parses ranked candidates, and can add a bounded set of deterministic import/semantic neighbors. Verified excerpts and structural facts are then selected by utility per estimated token, with redundant same-file context discounted. The estimated-token target is a soft packing goal; an independent byte cap is the hard model-visible output guard. Structural parsing currently covers Rust, Python, JavaScript/TypeScript, Go, Java, C#, C, and C++. Search-term matching is Unicode-aware while filesystem safety policy remains deliberately separate and conservative.
Sippion is a repository-context tool, not a compiler or language server. It does not claim compiler-authoritative type resolution or LSP-grade references.
See Architecture and Integration boundaries for details.
The project pins Rust 1.85.0 and commits Cargo.lock.
CI also audits Cargo.lock against the RustSec advisory database.
The native binary is target/release/sippion or
target/release/sippion.exe on Windows.
Supported release binaries:
Release workflows build all four targets, generate portable SHA-256 files, and produce GitHub artifact attestations. Third-party GitHub Actions are pinned to full commit SHAs. Pull-request supply-chain smoke builds and assembles the release payload without minting distributable attestations, then separately verifies a published installer and binary with the same strict repository, signer-workflow, and source-SHA policy used by the installers.
For an automated prerelease after a version bump reaches main, create a
one-shot release/vX.Y.Z[-prerelease] branch that points exactly at current
main. The release workflow validates the version, creates or verifies the tag,
publishes the prerelease, and deletes the one-shot branch after success.
Manual draft-release dispatches must be run from the exact tag ref supplied as
input so the workflow source SHA and built source SHA cannot diverge.