一个本地 MCP 服务器，让多个 AI 编码工具共享结构化的项目状态——决策、任务、缺陷——使它们无需重新解释即可协同。
Claude Code Cursor Codex
│ │ │
│ read/write │ read/write │
└──────────────┼─────────────┘
▼
┌───────────────────────┐
│ samskriti-shared-layer │ (local MCP server, stdio)
└───────────┬───────────┘
▼
┌───────────────────┐
│ SQLite store │ ~/.samskriti/ (100% local)
└───────────────────┘你用一个人工智能工具做出决定，再切换到另一个，又得从头解释一切。每个助手都是冷启动的，不知道之前已经决定、尝试或否决了什么。这个服务器为你的项目提供一个共享的结构化账本，让任何工具都能读到其他工具写入的内容。
Related MCP server: session-coord-mcp
使用 pipx 安装（推荐——这会将 samskriti-shared-layer 命令放到你的 PATH 中，方便你的 AI 工具找到它）：
pipx install git+https://github.com/Escalate17/samskriti-shared-layer没有 pipx？先安装它：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 —— 存储条目（目标、更新、决策、约定、缺陷、任务、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 加上你想要的指令。
通俗语言（适用于任何 MCP 工具，包括 Codex）：
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 —— 一个引擎，它根据代理所经历的事情，以确定性的方式在任何语言模型之外计算代理的情感和关系状态。C++ 编写，提供 Python SDK。（论文）
samskriti-luau —— 同一个模型用于 Roblox，NPC 会记住玩家如何对待它们。
samskriti-shared-layer —— 本仓库。同样的想法应用于你的项目而不是一个角色：决策、任务和被否决的想法都保存在结构化的账本中，任何工具都可以读取，而不是在每个会话中从上下文中重新推导。
一个对你的代码库冷启动的 AI 助手和一个忘记你上周抢劫了它的游戏角色，是同样的失败。两者都是要求模型重建从未被赋予的状态。这个服务器就是那个不起眼的修复版本，也是我每天在用的。
早期 / 验证中。这是一个正在用真实工作流测试的工作原型。出现 bug、粗糙之处和缺失的功能是意料之中的——非常欢迎提出 issue 和反馈。
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.
