canonical-vault-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GITHUB_REPO | No | Change only if the repo is renamed | canonical-vault |
| GITHUB_OWNER | No | Change only if the repo moves | kushkillerjsixx66 |
| GITHUB_TOKEN | No | A GitHub PAT with repo (or just public_repo, since the vault is public) read scope. Without it you're capped at 60 GitHub API requests/hour shared across every caller; with it, 5000/hour. | |
| GITHUB_DEFAULT_REF | No | Default branch tools read from when no ref is given | main |
| GITHUB_WRITE_TOKEN | No | A separate, fine-grained PAT scoped to Contents: Read and write on canonical-vault only. Setting this activates vault_propose_change / vault_open_pr. | |
| GITHUB_WRITE_BRANCH_ALLOWLIST | No | Comma-separated branches the write tools may touch. The server refuses to boot if this ever includes GITHUB_DEFAULT_REF. | grok,claude,chatgpt,gemini,copilot |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| vault_list_directoryA | List the files and subdirectories at a given path in the canonical-vault repository (kushkillerjsixx66/canonical-vault). Args:
Returns: For JSON format: { "path": string, "ref": string, "entries": [{ "name": string, "path": string, "type": "file"|"dir", "size": number }] } Examples:
Error Handling:
|
| vault_get_fileA | Fetch the decoded text content of a single file from the canonical-vault repository (kushkillerjsixx66/canonical-vault). Args:
Returns: The raw file text, prefixed with a small header (path, ref, sha, size). Binary or oversized files (> 500000 bytes) return an error instead of garbled content. Examples:
Error Handling:
|
| vault_get_file_historyA | Get the commit lineage (history) affecting a file or directory in canonical-vault — i.e. every commit that touched that path, most recent first. Args:
Returns: For JSON format: { "path": string, "count": number, "commits": [{ "sha": string, "message": string, "author": string, "date": string, "url": string }], "has_more": boolean } Examples:
Error Handling:
|
| vault_get_commitA | Get full detail for a single commit in canonical-vault: message, author, stats, and the list of files it changed (with per-file diff stats). Args:
Returns: For JSON format: { "sha": string, "message": string, "author": string, "date": string, "stats": {...}, "files": [{ "filename": string, "status": string, "additions": number, "deletions": number }] } Examples:
Error Handling:
|
| vault_search_filesA | Search file names and contents across the canonical-vault repository (kushkillerjsixx66/canonical-vault) using GitHub code search. Args:
Returns: For JSON format: { "total": number, "count": number, "results": [{ "path": string, "url": string }], "has_more": boolean } Examples:
Error Handling:
|
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool has a distinctly separate purpose: listing a directory, reading a file, tracing commit history, inspecting a single commit, and searching the repository. The descriptions even include explicit 'Don't use when' guidance to prevent confusion.
All tools follow a uniform `vault_` prefix with a verb_noun pattern (list_directory, get_file, get_file_history, get_commit, search_files). Naming is idiomatic, consistent, and immediately signals the action and target.
Five tools is a well-scoped set for a read-only repository browsing server. Each tool covers a core operation without redundancy or bloat, making the surface easy to grasp and use.
For a read-only vault browsing use case, the set fully covers the necessary operations: navigating (list), reading content (get file), exploring change history (history/commit), and searching. There are no obvious missing capabilities that would block an agent.