複数のAIコーディングツールが構造化されたプロジェクト状態（決定事項、タスク、バグ）を共有できるようにするローカルMCPサーバーです。これにより、毎回説明し直すことなくツール間で連携できます。
Claude Code Cursor Codex
│ │ │
│ read/write │ read/write │
└──────────────┼─────────────┘
▼
┌───────────────────────┐
│ samskriti-shared-layer │ (local MCP server, stdio)
└───────────┬───────────┘
▼
┌───────────────────┐
│ SQLite store │ ~/.samskriti/ (100% local)
└───────────────────┘あるAIツールで決定を下しても、別のツールに切り替えると最初からすべてを説明し直さなければなりません。各アシスタントは、何がすでに決定され、試され、却下されたのかを知らないまま、まっさらな状態で始まります。このサーバーは、プロジェクトの共有・構造化台帳をツール群に提供し、どのツールも他のツールが書き込んだ内容を読めるようにします。
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 — 追跡中のすべてのプロジェクトを一覧表示します。
さらに、最も一般的な操作のための3つのショートカット — 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 のエージェントボックスで / と入力し、sam を選択して、メッセージを追加します。
スラッシュコマンドをMCP呼び出しに直接バインドする本格的なクライアント機能はまだありません — このコマンドファイルは、現在サポートされている最も近い代替手段であり、今日から使えます。
3つのショートカットは、最も一般的な操作をラップします。ツール名で直接呼び出すことはありません — /sam に平易な言葉を続けるか、単に平易な言葉で依頼するだけです。
やりたいこと | Tool | 動作 |
状況把握 |
| プロジェクトの要約 — 最新エントリと、まだオープンしているタスクの数を表示します。 |
進行中を確認 |
| 進行中（オープン）のタスクをそれぞれのID付きで一覧表示します。 |
決定を記録 |
| 決定をすばやく記録します。タイトルを省略した場合は、テキストから自動的にタイトルを生成します。 |
呼び出し方は2通り — どちらも機能します：
/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 という名前で保守している3つのプロジェクトのうちの1つで、共通の前提を共有しています：重要な状態は毎回トランスクリプトから再構築するのではなく、明示的に計算して保存されるべきです。
samskriti — エージェントが経験したことから、感情状態と関係状態を、言語モデルを使わずに決定的に計算するエンジン。C++ と Python SDK を備えています。（論文）
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.
