Enhances OpenAI chat completions by injecting temporal context (time, session duration, message gaps, and stale file detection) into prompts, so the model becomes aware of when events occurred.
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., "@pysince-mcp stamp read of config.py"
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.
Your agent already read the file. since tells it when the file changed.
Coding agents act on files they read minutes ago. Those files change: a formatter runs, a teammate pushes, another agent edits, a git pull lands. The agent never sees it, and acts on the stale version with full confidence. since tells it, on every tool call, exactly what changed.
pip install pysinceZero dependencies. Works in Claude Code, Cursor, Copilot, and Antigravity. Any MCP client.
Agents read a file, reason about it for many steps, then act on it but the file changed underneath them, and nothing tells them. It has a name: the stale world model problem. On long-horizon coding tasks, frontier model success drops from around 70% to roughly 23%, and about 36% of those failures trace to context drift, not reasoning quality. The canonical shape: an agent reads a file at step 3, reasons about it through step 30, and writes it back at step 31, but another process edited it at step 17. The agent silently overwrites the newer version, and the task looks like it succeeded.
This shows up across every major agent tool:
OpenAI Codex will overwrite any changes it didn't create: edit files while it works and it restores them, "every time."
GitHub Copilot agents overwrite their own edits because "the editor's state is different from what the AI has in its session-based memory."
Claude Code subagents read stale file versions, and its file cache diverges from disk with Read/Grep returning the stale copy - the reporter concludes only an out-of-band disk check catches it.
Continue has the same class of bug.
With parallel agents, this compounds into silent file overwrites and stale views of the codebase, where agents "proceed silently on corrupted data rather than surfacing exceptions."
It's a recognized production blocker - 32% of agent teams cite output consistency as their #1 issue and there are whole guides written just on stopping agents from overwriting your work.
since is the lightweight, single-install out-of-band check: it fingerprints every file the agent reads and, on every tool call, reports which ones changed on disk before the agent acts.
Related MCP server: cachebro
Every MCP tool response surfaces all files that changed since the agent last read them. The agent does not have to remember to check. since volunteers it:
Files changed since last read:
config.json (content changed, mtime changed) - read 4m ago
alerts.py (content changed, mtime changed) - read 3m agoThe agent re-reads those files before acting, instead of writing from a stale copy.
Strongest when files change outside the agent's view: another process, a teammate on the same repo, a formatter, a pre-commit hook, a parallel agent, or context that drifted over a long session.
Less useful for quick single-file edits an agent already re-reads on its own. Skip it for throwaway scripts. Reach for it when agents share files, sessions run long, or more than one actor touches the tree.
since runs as a local MCP server. Add it to your client's MCP config.
VS Code:
{
"servers": {
"pysince": {
"type": "stdio",
"command": "pysince-mcp",
"args": [],
"cwd": "${workspaceFolder}"
}
}
}Antigravity:
{
"mcpServers": {
"pysince": {
"command": "python",
"args": ["-m", "since.mcp"]
}
}
}Then add this line to your agent's system instructions so it knows when to call the tools:
On the first read of any file, call
stamp_file_read. Before editing a file, callcheck_staleness. When the response lists changed files, re-read them before acting on their contents.
Tool | When to call it | What it does |
| After reading any file | Records mtime and content hash |
| Before editing a file | Reports if it changed, and lists every other tracked file that changed too |
| Anytime | How long the session has been tracked |
| Manually | Marks a source stale on demand |
check_staleness is the core. It never answers only about the one file you asked about. It reports the full set of tracked files that have drifted, so the agent cannot stay blind to a change it did not think to check.
since stamps every file read with its mtime and a SHA-256 hash. On any later call it compares stored fingerprints against the current file: mtime first because it is fast, full hash only if mtime moved. No daemon, no polling, no background process. Just a comparison against disk at the next turn, which is why it catches changes the agent's own cached view cannot.
The same primitive, aimed at conversations instead of files. Wrap your chat function and the model sees a timeline: when each message happened, how long the gaps were, and what context has gone stale.
from since import Store, since_time
from openai import OpenAI
store = Store("~/.since/chat.db")
client = OpenAI()
@since_time(store=store, timezone="Asia/Kolkata")
def chat(messages):
return client.chat.completions.create(model="gpt-4o-mini", messages=messages)
resp = chat(messages=[{"role": "user", "content": "hello"}])
print(resp.choices[0].message.content)The model receives a compact time block before each turn:
Now: Wed Jul 01, 02:36 AM (night)
Session: 9h 2m total, 4m active across 3 sittings, 8 messages
Gap: 6h since the last messageSo instead of "I don't have information about previous conversations," it can say "welcome back, it has been about 6 hours since we last spoke."
The decorator reads the OpenAI response shape by default. For other providers, pass an extract_reply function that returns the reply text from your provider's response object.
Python 3.10+
Zero dependencies
pip install pysinceThe PyPI name is pysince because since was already taken. You import it, and the repo is named, since.
Check whether a previously-stamped file has changed since you last read it. If no prior stamp exists it will tell you to stamp first. Call this before editing any file you stamped earlier — if stale, re-read it.
| Name | Required | Description | Default |
|---|---|---|---|
| filepath | Yes | Path to the file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacking annotations, the description discloses the check behavior and edge case handling. While return format is not detailed, the core behavior is transparent.
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?
Two sentences efficiently deliver purpose, usage, and behavior without extraneous 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?
For a simple tool with one parameter and no output schema, the description covers purpose, usage, and edge case, making it complete.
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 parameter description 'Path to the file'. The description adds no additional meaning beyond the schema, so baseline 3 applies.
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 tool checks whether a previously-stamped file has changed, and differentiates from sibling tools like stamp_file_read by describing its specific purpose.
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?
Explicitly states when to call it ('before editing any file you stamped earlier') and what to do if no stamp exists ('tell you to stamp first'). Provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manually mark all events from a source as stale. Used when you know a resource has changed and want to ensure stale warnings fire.
| Name | Required | Description | Default |
|---|---|---|---|
| source_id | Yes | Source ID to invalidate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool marks events as stale and triggers stale warnings, but lacks details on reversibility, permissions, or side effects.
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?
Two sentences with no redundant text. Action and use case are front-loaded, and every sentence 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 one-parameter tool with no output schema, the description adequately explains the purpose and effect. It could briefly mention the return value or confirmation, but completeness is high given the tool's simplicity.
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 a single parameter 'source_id' described as 'Source ID to invalidate'. The description adds no additional parameter context beyond the schema, baseline 3 applies.
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 specific verb+resource ('mark all events from a source as stale') and differs from sibling tools like check_staleness which likely checks staleness rather than triggering it.
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?
States when to use ('when you know a resource has changed'), providing clear context. Does not explicitly state when not to use or name alternatives, but the use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How long has this session been running and how many messages have been exchanged. Useful for understanding context age.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description fails to disclose side effects or safety profile; only states what it returns without indicating if it's read-only or requires authorization.
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?
Two concise sentences front-loading purpose and usage, with no wasted words.
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?
With no output schema, description should specify return format (e.g., units, data types); currently vague on details of duration and message count.
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 are defined, and schema coverage is 100%; description does not need to explain parameters.
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?
Clearly states it returns session duration and message count, and distinguishes from sibling tools like check_staleness which check data freshness.
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?
Provides usage context ('useful for understanding context age'), but lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this immediately after reading a file for the first time. Must be called BEFORE check_staleness can detect changes to that file. Records current mtime and content hash.
| Name | Required | Description | Default |
|---|---|---|---|
| filepath | Yes | Path to the file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it records mtime and content hash and is a prerequisite for check_staleness. Lacks side-effect details but adequate given no annotations.
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?
Three sentences, front-loaded with important usage instruction, no waste.
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?
Covers purpose, usage, and recorded data. Lacks error handling and return info, but simple tool with no output schema.
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 already describes filepath as 'Path to the file'; description adds no additional meaning, so baseline 3 applies.
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 tool records mtime and content hash after reading a file, and distinguishes it from sibling check_staleness by specifying it must be called before staleness detection.
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?
Explicitly instructs to call immediately after first file read and before check_staleness, providing clear when-to-use and ordering relative to sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool serves a distinct purpose: stamping, checking staleness, invalidating sources, and querying session duration. No overlap in functionality.
Uses snake_case consistently, but 'session_duration' is a noun phrase while others are verb phrases (check_staleness, invalidate_source, stamp_file_read). Minor inconsistency.
Four tools is well-scoped for a file staleness tracker. Each tool covers a necessary operation without redundancy.
Core operations (stamp, check, invalidate) are present. Missing a tool to list all stamped files, but the essential workflow is covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Securely search and manage workspace context files for AI agents and teams.
Artifact store for AI agents — read, write, and search files by path; share by rendered URL.
Cross-agent artifact workspace with provenance across Claude Code, Codex, Cursor, LangGraph.
Wall-clock awareness for LLM agents. Two tools: elapsed-time-between-turns + day rollover detection.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/LNSHRIVAS/since'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
