A local MCP server that lets multiple AI coding tools share and persist structured project state via SQLite, enabling coordination without re-explaining context when switching tools.
Record project entries (record_project_entry): Store entries in categories like goal, update, decision, convention, bug, task, or rejected_idea, with optional status and source agent tracking.
Read project state (get_project_state): Retrieve a readable, grouped summary of all entries for a project, optionally filtered by category.
Search entries (search_project_state): Keyword search across entry titles and content within a project.
Update entries (update_project_entry): Edit an existing entry's title, content, or status (e.g., mark a task as completed or a decision as superseded).
List all projects (list_projects): View all projects currently tracked in the database.
Shortcut helpers (catchup, open, log): Quickly recap project status, see active tasks with IDs, or rapidly log a decision with an auto-derived title.
Slash command support: Use /sam in Claude Code or Cursor for faster access.
Automatic tool setup: Run samskriti-project setup to configure MCP for Claude Code, Cursor, or Codex without manual JSON editing.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@samskriti-project get project state for demo"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A local MCP server that lets multiple AI coding tools share structured project state — decisions, tasks, bugs — so they coordinate without re-explaining.
Claude Code Cursor Codex
│ │ │
│ read/write │ read/write │
└──────────────┼─────────────┘
▼
┌───────────────────────┐
│ samskriti-shared-layer │ (local MCP server, stdio)
└───────────┬───────────┘
▼
┌───────────────────┐
│ SQLite store │ ~/.samskriti/ (100% local)
└───────────────────┘You make a decision with one AI tool, then switch to another and have to re-explain everything from scratch. Each assistant starts cold, with no idea what was already decided, tried, or rejected. This server gives them a shared, structured ledger of your project so any tool can read what the others wrote.
Related MCP server: session-coord-mcp
Install with pipx (recommended — this puts the samskriti-shared-layer command on your PATH so your AI tools can find it):
pipx install git+https://github.com/Escalate17/samskriti-shared-layerDon't have pipx? Install it first: python3 -m pip install --user pipx && python3 -m pipx ensurepath (then restart your terminal).
To verify the install worked:
samskriti-shared-layer --helpIf you see the help text, you're ready to connect it.
samskriti-shared-layer setup # Claude Code
samskriti-shared-layer setup --cursor # Cursor
samskriti-shared-layer setup --codex # Codex
samskriti-shared-layer setup --all # all threeThis writes the MCP config block into the right file for you (backing up any existing config first), so you don't have to hand-edit JSON. Then fully quit and reopen your tool — MCP servers are loaded only when the tool starts, so a running session won't see it until you restart.
Add the server to your AI tool's MCP config, then fully restart the tool.
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 = []If your tool can't find the command, it's a PATH issue — run
which samskriti-shared-layerto get the full path, and use that full path as thecommandvalue instead.
In Claude Code, type /mcp — you should see samskriti-shared-layer listed with its 8 tools. (Cursor and Codex have similar MCP status indicators in their settings.)
record_project_entry — store an entry (goal, update, decision, convention, bug, task, rejected_idea).
get_project_state — read a readable summary, grouped by category.
search_project_state — keyword search across entries.
update_project_entry — edit an entry's title, content, or status.
list_projects — list all tracked projects.
Plus three shortcuts — catchup, open, and log — for the most common actions. See Helper commands below.
Already installed? Run
pipx reinstall samskriti-shared-layerto pick up the new commands. If you installed an earlier build (it shows up assamskriti-shared-layer-localinpipx list), migrate once:pipx uninstall samskriti-shared-layer-local && pipx install git+https://github.com/Escalate17/samskriti-shared-layer.
/sam slash commandTyping "use the samskriti-shared-layer MCP …" every time is tedious. Both Claude Code and
Cursor support custom slash commands — Markdown prompt files you drop in a folder.
They don't bind directly to a tool, but they inject a prompt that tells the agent to use
this server, so /sam <message> does the right thing. (Codex has no slash-command
mechanism for MCP; just say "use samskriti-shared-layer to …" — the agent picks the tool.)
Claude Code — save slash-commands/claude-code/sam.md to one of:
~/.claude/commands/sam.md (available in every project), or
<your-project>/.claude/commands/sam.md (that project only).
Then in Claude Code: /sam what's open or /sam log we're dropping the Redis cache.
The $ARGUMENTS placeholder in the file receives everything you type after /sam.
Cursor (1.6+) — save slash-commands/cursor/sam.md to:
~/.cursor/commands/sam.md (global), or
<your-project>/.cursor/commands/sam.md (that project only).
Then type / in Cursor's Agent box, pick sam, and add your message.
No true client feature binds a slash command straight to an MCP call yet — this command file is the closest supported equivalent, and it works today.
Three shortcuts wrap the most common actions. You never call them by tool name directly —
you trigger them with /sam plus plain English, or just by asking in plain language.
Want to… | Tool | What it does |
Catch up |
| Recap of the project — latest entries plus how many tasks are still open. |
See what's open |
| Lists the active (open) tasks, each with its ID. |
Log a decision |
| Records a decision fast; the title is auto-derived from the text if you omit it. |
Two ways to invoke — both work:
/sam slash command (Claude Code / Cursor, once you've added the command file above):
/sam catch me up
/sam what's open
/sam log we're switching local storage to SQLiteYou type /sam followed by plain English. There is no standalone /catchup,
/open, or /log command — it is always /sam plus what you want.
Plain language (works in any MCP tool, including 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 SQLiteIn tool A (e.g. Claude Code): "Record a decision in project 'demo': we're using SQLite for local storage."
In tool B (e.g. Cursor): "Get the project state for 'demo'."
Tool B reads back the decision tool A just wrote — no re-explaining.
100% local. No cloud, no account, your data never leaves your machine. State is stored in a SQLite database under ~/.samskriti/ (override with the SAMSKRITI_HOME or SAMSKRITI_PROJECT_DB environment variable). Your AI client's own data and privacy policies still apply.
This is one of three things I maintain under the name Samskriti, and they share a premise: the state that matters should be computed and stored explicitly, not reconstructed from a transcript every time.
samskriti — an engine that computes an agent's emotional and relational state from what it has experienced, deterministically, outside any language model. C++ with a Python SDK. (paper)
samskriti-luau — the same model for Roblox, where NPCs remember how a player treated them.
samskriti-shared-layer — this repo. The same idea applied to your project rather than a character: decisions, tasks, and rejected ideas live in a structured ledger that any tool can read, instead of being re-derived from context each session.
An AI assistant starting cold on your codebase and a game character forgetting you robbed it last week are the same failure. Both are asking a model to reconstruct state it was never given. This server is the unglamorous version of the fix, and the one I use every day.
Early / validating. This is a working prototype being tested with real workflows. Bugs, rough edges, and missing features are expected — issues and feedback are very welcome.
MIT — see 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. Dates show when Glama detected each change.
v0.1.0get_project_statelist_projectsrecord_project_entrysearch_project_stateupdate_project_entryEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
One memory, every AI. A shared, user-owned markdown memory your AI clients read and write over MCP.
One shared context your team's AI tools read & write over MCP. No re-explaining. Free.
MCP server for generating rough-draft project plans from natural-language prompts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Escalate17/samskriti-shared-layer'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
