kintsugi
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 | {} |
| prompts | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| kintsugi_scan_codeB | Deterministically scan a source snippet or file path against verified Kintsugi Golden Scars (AST + Regex) before writing or committing. |
| kintsugi_list_scarsB | List verified Golden Scars ( |
| kintsugi_record_failureC | Compile a runtime/test failure into a new self-verified Golden Scar and persist it into |
| kintsugi_compile_skillsC | Compile |
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 4 tools
Each tool owns a distinct stage of the scar lifecycle: scanning code (kintsugi_scan_code), browsing the catalog (kintsugi_list_scars), authoring a new scar (kintsugi_record_failure), and exporting to skill files (kintsugi_compile_skills). The scan-vs-list boundary is clearly separated by input (code snippet/path vs catalog filters), so an agent can pick correctly without ambiguity.
All four tools use the identical `kintsugi_` namespace plus a verb_noun pattern (scan_code, list_scars, record_failure, compile_skills). No casing or verb-style deviation anywhere in the set.
Four tools is a tight, well-scoped surface for a scar knowledge-base server, and each one maps to a distinct workflow step with no filler or redundancy. Nothing feels missing at the count level; the gaps are lifecycle operations, not volume.
The create (record_failure) → read (list_scars) → apply (scan_code) → distribute (compile_skills) pipeline is coherent, but there is no way to update, deprecate, or delete an existing scar once persisted to scars.json. An agent that records a bad or stale scar has no dead-end-free path to correct it.