여러 AI 코딩 도구가 구조화된 프로젝트 상태(결정, 작업, 버그)를 공유할 수 있게 해 주는 로컬 MCP 서버입니다. 다시 설명할 필요 없이 도구들이 서로 조율할 수 있습니다.
Claude Code Cursor Codex
│ │ │
│ read/write │ read/write │
└──────────────┼─────────────┘
▼
┌───────────────────────┐
│ samskriti-shared-layer │ (local MCP server, stdio)
└───────────┬───────────┘
▼
┌───────────────────┐
│ SQLite store │ ~/.samskriti/ (100% local)
└───────────────────┘한 AI 도구로 결정을 내리고 나서 다른 도구로 전환하면 모든 것을 처음부터 다시 설명해야 합니다. 각 어시스턴트는 이전에 이미 결정되었거나 시도되었거나 기각된 내용에 대해 전혀 모른 채 시작합니다. 이 서버는 프로젝트의 공유되고 구조화된 원장(ledger)을 제공하여 어떤 도구든 다른 도구가 기록한 내용을 읽을 수 있게 합니다.
Related MCP server: session-coord-mcp
pipx로 설치합니다(권장 — samskriti-shared-layer 명령이 PATH에 추가되어 AI 도구가 찾을 수 있습니다):
pipx install git+https://github.com/Escalate17/samskriti-shared-layerpipx가 없으신가요? 먼저 설치하세요: python3 -m pip install --user pipx && python3 -m pipx ensurepath (그런 다음 터미널을 다시 시작하세요).
설치가 제대로 되었는지 확인하려면:
samskriti-shared-layer --help도움말 텍스트가 보이면 연결할 준비가 된 것입니다.
samskriti-shared-layer setup # Claude Code
samskriti-shared-layer setup --cursor # Cursor
samskriti-shared-layer setup --codex # Codex
samskriti-shared-layer setup --all # all three이 명령은 기존 설정을 먼저 백업한 후 MCP 설정 블록을 올바른 파일에 자동으로 작성하므로 JSON을 직접 수정할 필요가 없습니다. 그런 다음 도구를 완전히 종료하고 다시 여세요 — MCP 서버는 도구가 시작될 때만 로드되므로, 실행 중인 세션은 재시작하기 전까지 이를 인식하지 못합니다.
AI 도구의 MCP 설정에 서버를 추가한 후 도구를 완전히 재시작하세요.
Claude Code (~/.claude.json):
{
"mcpServers": {
"samskriti-shared-layer": {
"command": "samskriti-shared-layer",
"args": []
}
}
}Cursor (~/.cursor/mcp.json):
{
"mcpServers": {
"samskriti-shared-layer": {
"command": "samskriti-shared-layer",
"args": []
}
}
}Codex (~/.codex/config.toml):
[mcp_servers.samskriti-shared-layer]
command = "samskriti-shared-layer"
args = []도구가 명령을 찾지 못한다면 PATH 문제입니다 —
which samskriti-shared-layer를 실행하여 전체 경로를 확인하고 그 전체 경로를command값으로 사용하세요.
Claude Code에서 /mcp를 입력하면 samskriti-shared-layer가 8개의 도구와 함께 표시되어야 합니다. (Cursor와 Codex도 설정에 유사한 MCP 상태 표시기가 있습니다.)
record_project_entry — 항목을 저장합니다 (goal, update, decision, convention, bug, task, rejected_idea).
get_project_state — 카테고리별로 그룹화된 읽기 쉬운 요약을 읽습니다.
search_project_state — 항목 전체에서 키워드 검색.
update_project_entry — 항목의 제목, 내용 또는 상태를 편집.
list_projects — 추적 중인 모든 프로젝트를 나열.
또한 가장 일반적인 작업을 위한 세 가지 단축키 — catchup, open, log —가 있습니다. 아래의 도우미 명령을 참조하세요.
이미 설치하셨나요? 새 명령을 적용하려면
pipx reinstall samskriti-shared-layer를 실행하세요. 이전 빌드를 설치했다면(pipx list에서samskriti-shared-layer-local로 표시됨), 한 번 마이그레이션하세요:pipx uninstall samskriti-shared-layer-local && pipx install git+https://github.com/Escalate17/samskriti-shared-layer.
/sam 슬래시 명령매번 *“samskriti-shared-layer MCP를 사용해 …”*라고 입력하는 것은 번거롭습니다. Claude Code와 Cursor 모두 사용자 정의 슬래시 명령을 지원합니다 — 폴더에 넣는 Markdown 프롬프트 파일입니다. 이 명령은 도구에 직접 바인딩되지는 않지만, 에이전트에게 이 서버를 사용하도록 지시하는 프롬프트를 주입하므로 /sam <message>가 올바르게 동작합니다. (Codex에는 MCP용 슬래시 명령 메커니즘이 없습니다. 그냥 *“samskriti-shared-layer를 사용해 …”*라고 말하면 에이전트가 도구를 선택합니다.)
Claude Code — slash-commands/claude-code/sam.md를 다음 중 한 곳에 저장하세요:
~/.claude/commands/sam.md (모든 프로젝트에서 사용 가능), 또는
<your-project>/.claude/commands/sam.md (해당 프로젝트에서만).
그런 다음 Claude Code에서: /sam what's open 또는 /sam log we're dropping the Redis cache.
파일의 $ARGUMENTS 플레이스홀더는 /sam 뒤에 입력한 모든 내용을 받습니다.
Cursor (1.6+) — slash-commands/cursor/sam.md를 다음에 저장하세요:
~/.cursor/commands/sam.md (전역), 또는
<your-project>/.cursor/commands/sam.md (해당 프로젝트에서만).
그런 다음 Cursor의 Agent 상자에서 /를 입력하고 sam을 선택한 다음 메시지를 추가하세요.
아직 슬래시 명령을 MCP 호출에 직접 바인딩하는 진정한 클라이언트 기능은 없습니다 — 이 명령 파일이 지원되는 가장 유사한 방법이며 오늘도 작동합니다.
세 가지 단축키가 가장 일반적인 작업을 처리합니다. 도구 이름으로 직접 호출하는 것이 아니라 /sam에 일반 영어를 덧붙여 트리거하거나, 그냥 평범한 말로 요청합니다.
원하는 작업 | 도구 | 기능 |
상황 파악 |
| 프로젝트 요약 — 최신 항목과 아직 열려 있는 작업 수. |
진행 중인 작업 보기 |
| 활성(열린) 작업을 각각의 ID와 함께 나열. |
결정 기록 |
| 결정을 빠르게 기록. 제목을 생략하면 텍스트에서 자동으로 유도. |
두 가지 호출 방법 — 모두 동작합니다:
/sam 슬래시 명령 (위의 명령 파일을 추가한 경우 Claude Code / Cursor):
/sam catch me up
/sam what's open
/sam log we're switching local storage to SQLite/sam 뒤에 일반 영어를 입력합니다. 독립적인 /catchup, /open, /log 명령은 없습니다 — 항상 /sam 뒤에 원하는 내용을 붙입니다.
일반 언어 (Codex를 포함한 모든 MCP 도구에서 작동):
use samskriti-shared-layer to catch me up
use samskriti-shared-layer to show what's open
use samskriti-shared-layer to log: we're switching local storage to SQLite도구 A (예: Claude Code)에서: “‘demo’ 프로젝트에 결정을 기록하세요: 로컬 저장소로 SQLite를 사용합니다.”
도구 B (예: Cursor)에서: “‘demo’ 프로젝트의 상태를 가져오세요.”
도구 B는 도구 A가 방금 기록한 결정을 다시 읽습니다 — 다시 설명할 필요가 없습니다.
100% 로컬. 클라우드 없음, 계정 없음, 데이터는 기기를 절대 떠나지 않습니다. 상태는 ~/.samskriti/ 아래의 SQLite 데이터베이스에 저장됩니다(SAMSKRITI_HOME 또는 SAMSKRITI_PROJECT_DB 환경 변수로 재정의할 수 있습니다). AI 클라이언트 자체의 데이터 및 개인정보 처리 방침은 여전히 적용됩니다.
이것은 Samskriti라는 이름으로 유지 관리하는 세 가지 중 하나이며, 공통된 전제를 공유합니다: 중요한 상태는 매번 대화 기록에서 재구성되는 것이 아니라 명시적으로 계산되고 저장되어야 한다.
samskriti — 에이전트가 경험한 것으로부터 정서적·관계적 상태를 결정론적으로 계산하는 엔진으로, 어떤 언어 모델에도 의존하지 않습니다. Python SDK를 갖춘 C++입니다. (논문)
samskriti-luau — Roblox용 동일 모델로, NPC가 플레이어가 자신을 대했던 방식을 기억합니다.
samskriti-shared-layer — 이 저장소입니다. 캐릭터가 아닌 여러분의 프로젝트에 동일한 아이디어를 적용합니다: 결정, 작업, 기각된 아이디어가 매 세션마다 컨텍스트에서 다시 유도되는 대신, 어떤 도구든 읽을 수 있는 구조화된 원장에 저장됩니다.
여러분의 코드베이스에 대해 아무것도 모른 채 시작하는 AI 어시스턴트와 지난주에 당신이 자신을 털었다는 사실을 잊어버린 게임 캐릭터는 같은 실패입니다. 둘 다 결코 주어지지 않은 상태를 재구성하도록 모델에 요청하고 있습니다. 이 서버는 화려하지는 않지만 그 문제를 해결하는 버전이며, 제가 매일 사용하는 것입니다.
초기 단계 / 검증 중. 실제 워크플로우로 테스트되고 있는 작동하는 프로토타입입니다. 버그, 거친 부분, 누락된 기능이 있을 수 있습니다 — 이슈와 피드백은 언제나 환영합니다.
MIT — LICENSE를 참조하세요.
Returns a concise, readable summary of project state, grouped by category.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project name or absolute root path | |
| category | No | Optional specific category to filter by |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the output is 'concise, readable summary, grouped by category' but does not disclose read-only nature, performance, or any side effects. Minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, front-loaded with verb and object. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with full schema parameter coverage and no output schema, the description adequately conveys categorization. However, it does not specify what 'state' includes (e.g., status, metrics), leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds 'grouped by category' hinting at the category parameter, but this is already implied by the parameter description. Meets baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Returns' and resource 'summary of project state' making the purpose clear. It implicitly distinguishes from siblings like list_projects (list only) and search_project_state (search), but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as search_project_state or list_projects. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a list of all known projects tracked by Samskriti V1.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only states it returns a list; no mention of pagination, ordering, performance characteristics, or potential large results. This lack of detail can cause agent uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with no wasted words. All information is front-loaded and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters or output schema, the description is minimal. It covers the basic purpose but lacks details on return format, ordering, or any limitations. For a simple listing tool, it is adequate but could be more complete (e.g., 'Returns an array of project objects with id and name').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. Baseline score of 4 applies as description adds no parameter info but is not needed. The tool has no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a list of all known projects tracked by Samskriti V1, with a specific verb and resource. It distinguishes from siblings like get_project_state (single project) and search_project_state (filtered).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like search_project_state for filtered results. The description implies listing all projects but does not explicitly state when to prefer this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stores a structured project-state entry (goal, update, decision, convention, bug, task, rejected_idea).
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project name or absolute root path | |
| category | Yes | Category: goal, update, decision, convention, bug, task, rejected_idea | |
| title | Yes | Concise summary title | |
| content | Yes | Detailed description or payload | |
| source_agent | No | Optional name of the agent calling this tool (e.g. 'claude-code') | |
| status | No | Optional status: active, completed, resolved, superseded |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It only says 'Stores' without clarifying if entries are appended or overwritten, or if duplicates are allowed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but omits important details. While not verbose, it does not fully earn its place given the missing behavioral and usage information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and description does not mention return value or success/error behavior. Does not explain whether entries are idempotent or require prior project existence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for all parameters. Description adds no extra meaning beyond the schema, such as value formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it stores a structured project-state entry and lists the allowed categories. It distinguishes from siblings like get_project_state (read) and update_project_entry (update).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus update_project_entry or whether the project must already exist. Lacks prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the project state ledger using a simple keyword query.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project name or absolute root path | |
| query | Yes | Keywords to match against title/content |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only mentions 'simple keyword query' without explaining output format, pagination, case sensitivity, wildcards, or any side effects. This minimal information is insufficient for an agent to understand the tool's behavior beyond the basic intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no extraneous words. However, it lacks structure such as front-loading key details or breaking down complex information. While efficient, it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should explain what the search returns. It does not mention the return format, whether results are filtered or sorted, or any limitations. This leaves a significant gap in context for the agent to correctly invoke and interpret the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters ('project' and 'query'), achieving 100% coverage. The description adds only the qualifier 'simple', which does not significantly enhance meaning beyond the schema. Therefore, it meets the baseline for high schema coverage without adding substantial value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search'), the resource ('project state ledger'), and the method ('simple keyword query'). It effectively distinguishes this tool from its siblings (get_project_state, list_projects, record_project_entry, update_project_entry) by indicating a different purpose: searching instead of retrieving full state, listing, recording, or updating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for keyword-based searching but does not explicitly state when to use this tool versus alternatives. No guidance on when not to use it or which sibling might be better suited for specific scenarios is provided, leaving the agent to infer from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing project entry's title, content, or status.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Unique UUID of the entry to edit | |
| title | No | Optional new title | |
| content | No | Optional new content | |
| status | No | Optional new status (active, completed, resolved, superseded) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as permissions, idempotency, side effects, or error handling. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, front-loaded with the action and resource, with no extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with no output schema, the description covers the what and the modifiable fields. However, it lacks information on return values, error conditions, or idempotency, which would be helpful for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value by listing the allowed status values in parentheses, which is not fully captured in the schema's description for the 'status' parameter. Schema coverage is 100%, so baseline is 3; the extra enum detail raises it to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Update' with the resource 'project entry' and lists the fields that can be modified (title, content, status). It clearly distinguishes from sibling tools like 'record_project_entry' (create) and 'get_project_state' (read).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys usage: modify an existing entry. However, it does not explicitly state when not to use it (e.g., for creating new entries) or provide alternatives. Despite this, the context is clear given the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_project_statelist_projectsrecord_project_entrysearch_project_stateupdate_project_entryScored across 5 tools
Each tool has a distinct purpose: summarizing state, listing projects, recording entries, searching, and updating. No overlapping functionality.
All tool names follow a consistent verb_noun pattern (e.g., get_project_state, record_project_entry), ensuring predictability.
With 5 tools, the server covers essential operations without being overwhelming or insufficient for project state management.
Covers core operations (list, get, record, search, update) but lacks explicit project creation and deletion, which may be minor gaps.
Project management shared by people and AI agents, with persistent project state through MCP.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Hosted MCP server and Agent Skills for specs, engineering threads, and project memory.
