Extracts today's commit history and code diffs from a local Git repository, enabling daily work log review.
Click on "Deploy 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., "@today-work-log Summarize my git commits and changes from today"
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.
로컬 Git 리포지토리에서 오늘의 작업 내역(커밋 + 코드 변경사항)을 추출하는 MCP(Model Context Protocol) 서버입니다.
오늘 자정(00:00) 이후 작성한 모든 커밋 조회
현재 Git 사용자의 커밋만 필터링
코드 변경사항(Diff) 포함
Merge 커밋 제외
Claude Desktop, Cursor 등 MCP 클라이언트와 연동 가능
Related MCP server: GitHub Summary MCP
cd /path/to/today-work-log-mcp
npm install
chmod +x index.js~/Library/Application Support/Claude/claude_desktop_config.json 파일에 다음 설정을 추가하세요:
{
"mcpServers": {
"today-work-log": {
"command": "node",
"args": ["/path/to/today-work-log-mcp/index.js"]
}
}
}Cursor의 MCP 설정 파일에 유사하게 추가:
{
"mcpServers": {
"today-work-log": {
"command": "node",
"args": ["/path/to/today-work-log-mcp/index.js"]
}
}
}설정 후 Claude Desktop을 재시작하면 get_todays_git_diff 도구를 사용할 수 있습니다.
예시:
오늘 작업한 내용을 요약해줘
리포지토리 경로: /path/to/your-repoClaude가 자동으로 get_todays_git_diff 도구를 호출하여 커밋 내역과 코드 변경사항을 가져온 후 요약해줍니다.
📊 오늘의 Git 작업 내역 (2026. 2. 10.)
작성자: Kim Byungsun
리포지토리: /path/to/your-repo
========================================
Commit: abc123...
Author: Kim Byungsun <email@example.com>
Date: Mon Feb 10 15:30:00 2026
Subject: feat: Add new feature
[커밋 메시지 본문]
========================================
diff --git a/file.js b/file.js
index abc123..def456 100644
--- a/file.js
+++ b/file.js
@@ -10,7 +10,7 @@
[코드 변경사항]
...Node.js
@modelcontextprotocol/sdk - MCP 공식 SDK
zod - 스키마 검증
MIT
로컬 Git 리포지토리에서 오늘 자정(00:00) 이후 작성한 커밋과 코드 변경사항(diff)을 추출합니다. TIL(Today I Learned) 작성이나 작업 내역 요약에 유용합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes | 분석할 Git 리포지토리의 절대 경로 (예: /Users/username/project/my-repo) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clarifies the time window (midnight to now) and that both commits and diffs are extracted, but it does not explain important aspects such as whether the relevant date is the commit date or author date, whether uncommitted changes are included, what branches are considered, or what the output format looks like. This leaves significant ambiguity for a git-related tool.
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 two sentences, both informative and free of redundancy. It fronts the core action and scope, then adds the use-case context, all without 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?
For a simple one-parameter tool, the description is functionally adequate, but it omits details about the output format and error behavior. Since there is no output schema and no annotations, the agent must infer what the tool returns and how edge cases are handled. This is a clear gap, but given the tool's simplicity, the description is not critically incomplete.
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 schema already covers the sole parameter fully (repo_path, with an example). The description does not add any new meaning beyond the schema; it merely restates that it applies to a 'local Git repository'. Since schema coverage is 100%, the baseline of 3 is appropriate.
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 states a specific verb ('extracts'), a clear resource ('local Git repository'), and a specific scope ('commits and code changes (diff) after midnight today'). It also mentions the intended use case, making the tool's function immediately clear. Since there are no sibling tools, differentiation isn't required.
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 explicitly mentions usage contexts ('useful for TIL (Today I Learned) writing or summarizing work history'), giving the agent clear guidance on when to invoke it. However, it does not provide any exclusions or contrast with alternatives, likely because no siblings exist, but the use-case context is sufficient for a standalone tool.
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.
v1.0.0get_todays_git_diffScored across 1 tool
With only one tool, there is no possibility of confusion or overlap. The tool's purpose is clearly defined and distinct.
The single tool name follows a clear verb_noun pattern ('get_todays_git_diff'), which is consistent and descriptive. No other names exist to introduce inconsistency.
A single tool feels too thin for a server named 'today-work-log', which implies a broader scope such as logging or summarizing work. The narrow utility might justify one tool, but the name suggests more expected functionality.
The server only extracts today's git diff, but lacks any tools for actually creating or managing work logs, or for retrieving historical data. This significant gap means agents cannot complete a full work-log workflow.
Summarize repository changes for a release
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Repo intel for AI coding agents: overview, PRs, contributors, hot files, CI, deps. Remote MCP.
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
