Provides automated git change tracking for development work sessions, capturing file diffs and repository state changes to log development progress on tasks.
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., "@Eureka Labo Task Management MCP Server complete_task_work {"taskId": "cm123", "summary": "Fixed login form validation bugs"}"
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.
Model Context Protocol (MCP) server for Eureka Labo task management with automated git change tracking.
📋 Task Management - List, create, update tasks via MCP
🔄 Work Sessions - Track development work with git integration
📊 Change Logging - Automatically capture and log file changes
🎨 React Diff Support - Generate diffs compatible with react-diff-viewer
🔐 API Key Auth - Secure project-scoped access
Related MCP server: Eureka Labo MCP Server
Node.js 18+
Git repository for workspace
Eureka Labo API access with generated API key
cd /path/to/eurekalabo/mcp-server
npm installOpen your project in Eureka Labo UI
Go to Project Settings → API Keys
Click "Create API Key"
Select permissions:
read:project
read:tasks
write:tasks
assign:tasks
read:members
Copy the key (shown only once!)
Important: The API key is project-scoped, meaning it automatically grants access to the specific project it was created for. The MCP server will automatically detect which project you're working with.
cp .env.example .envEdit .env:
# Your Eureka Labo API URL (production URL with HTTPS)
EUREKA_API_URL=https://eurekalabo.162-43-92-100.nip.io
# Your project-specific API key (starts with pk_live_)
EUREKA_API_KEY=pk_live_your_personal_api_key_here
# WORKSPACE_PATH is optional - automatically uses Claude Code's current directory
# Only uncomment if you need to override:
# WORKSPACE_PATH=/path/to/your/git/repositoryAdd to ~/.claude/mcp.json:
{
"mcpServers": {
"eureka-tasks": {
"command": "npx",
"args": [
"tsx",
"/Users/yourname/workspace/eurekalabo/mcp-server/src/index.ts"
],
"env": {
"EUREKA_API_URL": "https://eurekalabo.162-43-92-100.nip.io",
"EUREKA_API_KEY": "pk_live_..."
}
}
}
}Note:
The MCP server automatically uses the directory where Claude Code is opened. No need to specify WORKSPACE_PATH!
The project ID is automatically fetched from your API key on initialization, so you don't need to configure it manually.
# List all tasks
@eureka-tasks list_tasks
# Filter by status
@eureka-tasks list_tasks {"status": "todo"}
# Get specific task
@eureka-tasks get_task {"taskId": "cmXXXXXXXXXXX"}
# Create task
@eureka-tasks create_task {
"title": "Implement JWT authentication",
"description": "Add JWT token verification middleware",
"priority": "high"
}
# Update task
@eureka-tasks update_task {
"taskId": "cmXXXXXXXXXXX",
"status": "in_progress"
}# 1. Start work on a task (captures git baseline)
@eureka-tasks start_work_on_task {"taskId": "cmXXXXXXXXXXX"}
# 2. Do your development work (edit files)
# Note: コミットは不要です！未コミットの変更も自動的にキャプチャされます。
# 3. Complete work (captures all changes and logs to task)
@eureka-tasks complete_task_work {
"taskId": "cmXXXXXXXXXXX",
"summary": "bcryptを使用したJWT認証を実装しました"
}
# This will:
# - Capture all changes from baseline (includes uncommitted changes!)
# - Store full diffs in task metadata (for react-diff-viewer in UI)
# - Update task description with formatted change summary in Japanese
# - Update task status to "done"重要な変更点:
✅ コミット不要: 未コミットの変更も自動的にキャプチャされます
✅ リアルタイム変更: working directoryの現在の状態を取得
✅ 柔軟性: コミットしてもしなくても、どちらでも動作します
タスク説明フォーマット（完了後）：
## 🎯 実装概要
bcryptを使用したJWT認証を実装しました
## 📊 変更統計
- **変更ファイル数**: 3個
- **追加行数**: +243行
- **削除行数**: -12行
- **ブランチ**: `feature/auth`
- **コミット**: `def456g`
## 📁 変更ファイル一覧
✏️ `src/middleware/auth.ts` (+45/-12)
➕ `tests/auth.test.ts` (+78/0)
➕ `docs/auth.md` (+120/0)
---
*詳細な差分はタスクのメタデータに保存されており、UIでreact-diff-viewerを使用して表示できます。*# List project members (for task assignment)
@eureka-tasks list_project_members {"projectId": "cmXXXXXXXXXXX"}
# Upload file attachment
@eureka-tasks upload_task_attachment {
"taskId": "cmXXXXXXXXXXX",
"filePath": "/path/to/file.pdf"
}
# Check active work sessions
@eureka-tasks get_active_sessions
# Cancel work session
@eureka-tasks cancel_work_session {"taskId": "cmXXXXXXXXXXX"}1. 開発者がUIでタスクを作成: "ユーザー認証の追加"
2. Claude Codeが作業を開始:
Claude> @eureka-tasks start_work_on_task {"taskId": "cm123"}
Response: ✅ Started work session (baseline: abc123)
3. Claude Codeがファイルを編集:
- src/middleware/auth.ts
- tests/auth.test.ts
- docs/auth.md
4. コミットは不要！（オプション）
# 未コミットの変更も自動的にキャプチャされます
# コミットしたい場合はしてもOK：
git add .
git commit -m "Add JWT authentication"
5. Claude Codeが作業を完了:
Claude> @eureka-tasks complete_task_work {
"taskId": "cm123",
"summary": "包括的なテストを含むJWT認証を実装しました"
}
Response: ✅ 作業セッションを完了しました
- ファイル変更: 3個
- 追加: +243行
- 削除: -12行
タスク説明とメタデータを更新しました。
6. Eureka Labo UIで表示:
- タスクステータス: "完了"
- タスク説明: 日本語の概要 + ファイル一覧 + 統計
- タスクメタデータ: react-diff-viewer用の完全な差分
• oldValue: 変更前のファイル全体
• newValue: 変更後のファイル全体（working directoryから取得）
• unifiedDiff: git unified diff形式
- 変更ログ: シンタックスハイライト付きの並列差分表示Changes are stored in relational tables WorkSession and WorkSessionChange:
-- WorkSession table
CREATE TABLE "WorkSession" (
"id" TEXT PRIMARY KEY,
"taskId" TEXT REFERENCES "Task"(id) ON DELETE CASCADE,
"sessionId" TEXT UNIQUE,
"startedAt" TIMESTAMP NOT NULL,
"completedAt" TIMESTAMP,
"summary" TEXT,
"gitBaseline" TEXT NOT NULL,
"gitFinal" TEXT NOT NULL,
"branch" TEXT NOT NULL,
"statistics" JSONB NOT NULL, -- { filesChanged, linesAdded, linesRemoved }
"createdAt" TIMESTAMP DEFAULT NOW(),
"updatedAt" TIMESTAMP DEFAULT NOW()
);
-- WorkSessionChange table
CREATE TABLE "WorkSessionChange" (
"id" TEXT PRIMARY KEY,
"workSessionId" TEXT REFERENCES "WorkSession"(id) ON DELETE CASCADE,
"file" TEXT NOT NULL,
"changeType" TEXT NOT NULL, -- 'added' | 'modified' | 'deleted'
"linesAdded" INTEGER NOT NULL,
"linesRemoved" INTEGER NOT NULL,
"language" TEXT NOT NULL,
"oldValue" TEXT NOT NULL, -- Full old file content
"newValue" TEXT NOT NULL, -- Full new file content
"unifiedDiff" TEXT NOT NULL, -- Git unified diff
"createdAt" TIMESTAMP DEFAULT NOW()
);Example Data:
// WorkSession record
{
"id": "cm123abc456",
"taskId": "cmXXXXXXXXXXX",
"sessionId": "session_1738051200000",
"startedAt": "2025-01-28T10:00:00Z",
"completedAt": "2025-01-28T10:45:00Z",
"summary": "Implemented JWT authentication",
"gitBaseline": "abc123def",
"gitFinal": "def456ghi",
"branch": "feature/auth",
"statistics": {
"filesChanged": 3,
"linesAdded": 243,
"linesRemoved": 12
},
"changes": [
// WorkSessionChange records (joined)
{
"id": "cmCHG001",
"workSessionId": "cm123abc456",
"file": "src/middleware/auth.ts",
"changeType": "modified",
"linesAdded": 45,
"linesRemoved": 12,
"language": "typescript",
"oldValue": "// full old file content",
"newValue": "// full new file content",
"unifiedDiff": "@@ -10,5 +10,8 @@ ..."
}
]
}Automatic syntax highlighting for:
TypeScript/JavaScript (.ts, .tsx, .js, .jsx)
Python (.py)
Go (.go)
Rust (.rs)
Java (.java)
C/C++ (.c, .cpp, .h, .hpp)
Ruby (.rb)
PHP (.php)
And 20+ more languages
cd /path/to/your/project
git init
git add .
git commit -m "Initial commit"# 以下を確認：
# 1. ファイルが実際に編集されているか
# 2. 正しいディレクトリで作業しているか（gitリポジトリ内）
# 3. start_work_on_task を実行してからファイルを編集したか
# デバッグ：
git status # 変更されたファイルを確認
git diff # 差分を確認Check API key is correct in .env
Verify key hasn't expired in Eureka Labo UI
Ensure key has required permissions
complete_task_workを実行する前に、必ずstart_work_on_taskを実行してください。
# 正しい順序：
@eureka-tasks start_work_on_task {"taskId": "..."} # 1. 開始
# ファイル編集 # 2. 作業
@eureka-tasks complete_task_work {"taskId": "...", "summary": "..."} # 3. 完了# Run in development mode
npm run dev
# Build for production
npm run build
# Start production build
npm startmcp-server/
├── src/
│ ├── index.ts # MCP server entry point
│ ├── config.ts # Environment configuration
│ ├── api/
│ │ └── client.ts # Eureka API wrapper
│ ├── tools/
│ │ ├── task-tools.ts # Task CRUD operations
│ │ └── work-session.ts # Work session management
│ └── tracking/
│ └── git-tracker.ts # Git diff capture
├── package.json
├── tsconfig.json
└── .envMIT
Cancel an active work session without logging changes.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | Task ID to cancel session for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the cancellation does not log changes, which is a useful behavioral note. However, it does not mention other side effects (e.g., session state, any cleanup) or expected outcomes, leaving some ambiguity.
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 redundant or extraneous information. It is efficiently structured and front-loaded with the primary action.
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 low complexity (one parameter, no output schema), the description adequately covers the key context: it targets an active session and specifies that no changes are logged. It does not elaborate on error cases or return values, but for this simple tool, the coverage is sufficient.
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 has one parameter, taskId, with a clear description ('Task ID to cancel session for'). Since schema coverage is 100% and the parameter's purpose is directly tied to the tool's action, the description adds sufficient meaning beyond the raw name.
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 verb (cancel), the resource (work session), and the scope (active session). It also adds the nuance 'without logging changes,' which distinguishes it from related tools like complete_task_work. The purpose is unambiguous.
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 when to use the tool (when you need to cancel an active work session) but does not explicitly state alternatives or conditions for not using it. It is sufficient for basic usage but lacks explicit guidance compared to the high bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Complete work on a task. Captures all git changes since work started and logs them to the task.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | Task ID to complete | |
| summary | Yes | Brief summary of work completed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it captures git changes and logs them, but with no annotations it does not fully describe side effects such as marking the task complete or potential failure conditions.
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 short, focused sentences with the main purpose front-loaded; no unnecessary wording.
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 two-parameter tool, the description covers core behavior well, though it leaves some edge-case expectations implicit, such as what happens when no git changes exist.
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%, but parameter descriptions are minimal and do not add extra meaning about how summary is used or any formatting/constraint details.
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 the tool completes work on a task and captures/logs git changes, distinguishing it from sibling tools like start_work_on_task or update_task.
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?
Implies use when finishing task work, but does not explicitly mention when not to use it or contrast it with sibling alternatives such as start_work_on_task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a GitHub pull request for all tasks in the current branch. Generates PR description from work sessions. Requires GitHub integration configured for the project.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | PR title (optional - will auto-generate from tasks if not provided) | |
| baseBranch | No | Base branch to merge into (default: main) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states it creates a pull request, which is a state-changing action. It also mentions that it generates the PR description from work sessions, giving insight into the tool's behavior. No annotations exist to contradict this, so the description carries the burden adequately, though it does not detail all potential side effects (e.g., whether task statuses are updated).
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 concise, consisting of two sentences that efficiently convey the core functionality, a generation detail, and a prerequisite. It is well-structured and free of unnecessary 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?
Given the absence of annotations and a simple schema with two optional parameters, the description covers the essential context: what it does, how it generates the PR description, and a key prerequisite. It does not mention return values or error handling, but the output schema is absent and the tool's purpose is clear enough for an agent to invoke it correctly in typical scenarios.
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 provides descriptions for both parameters (title and baseBranch), covering 100% of them. The description does not add additional semantic meaning beyond the schema, so it stays at the baseline score. The optional nature and defaults are implied by the schema but not elaborated in the description.
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's action: 'Create a GitHub pull request for all tasks in the current branch.' It specifies the resource (GitHub pull request) and scope (all tasks in current branch), making it distinct from sibling tools like list_tasks or create_task.
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 a clear prerequisite ('Requires GitHub integration configured for the project') and implies when it would be used (when a PR needs to be created for tasks). However, it does not explicitly mention alternatives or when not to use it, though the purpose is specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new task in the project.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Task title | |
| status | No | Initial status (default: todo) | |
| dueDate | No | Due date (ISO 8601 format) | |
| priority | No | Priority level (low, medium, high, critical) | |
| assigneeId | No | User ID to assign task to | |
| description | No | Task description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining side effects, permissions, and outcomes. It merely says 'create a new task' without mentioning whether it modifies existing data, what defaults are applied, what happens on duplicate titles, or what success/error responses look like.
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, focused sentence with no filler or redundancy. It efficiently communicates the essential purpose.
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?
The tool is simple and has no output schema or nested objects, but the description does not mention return values, validation rules, or any post-creation behavior. It is minimally adequate but leaves some contextual gaps.
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?
All six parameters have schema descriptions, so schema coverage is 100%. The tool description itself adds no additional parameter context beyond what the schema already provides, but since the schema is complete, the baseline score of 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 action ('Create') and the resource ('a new task in the project'), which distinguishes it from sibling tools like update_task, start_work_on_task, and create_pull_request.
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 gives no explicit guidance about when to use this tool versus alternatives. It relies entirely on the name and general context, so an agent has no stated criteria for choosing create_task over update_task or start_work_on_task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all active work sessions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation through the word 'list,' but it does not explicitly state that no side effects occur or disclose any permissions or limitations. Since no annotations are provided, the description carries the full burden, and while it is not misleading, it lacks explicit assurances.
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, direct sentence with no unnecessary words or redundancy. It is highly concise and immediately conveys the essential action and target.
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 list operation with no output schema, the description adequately states that the result is a list of active work sessions. It does not specify the output format or define 'active,' but given the absence of parameters and output schema, this level of detail is sufficient for most use cases.
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?
There are no parameters, and the schema coverage is 100% (empty object). The description adds no parameter-specific details because there is nothing to document, so the baseline score 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 clearly states the verb 'list' and the resource 'active work sessions,' making the tool's purpose unambiguous. It is distinct from sibling tools like list_tasks or list_project_members because it explicitly targets work sessions.
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 provides no guidance on when to use this tool versus alternatives. It does not mention any conditions or scenarios that would make this tool preferable over similar list operations, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific task, including change history.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | Task ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not state whether the operation is read-only, whether authentication is required, or whether any side effects occur. As a 'get' it is likely safe, but this is not explicitly disclosed.
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?
A single, clear, and concise sentence that conveys the tool's purpose without unnecessary words or repetition.
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 fetch operation, the description is largely complete: it names the target, the action, and the included detail ('change history'). It does not mention output format or error behavior, but these are not critical for such a basic tool.
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 fully describes the only parameter as 'Task ID', so coverage is 100%. However, the description adds no extra meaning about the format, source, or possible values of taskId beyond the schema.
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?
States a specific verb ('get'), a distinct resource ('a specific task'), and the included scope ('change history'). Clearly differentiated from sibling list_tasks, which would be used for multiple tasks.
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 phrase 'specific task' implies use when retrieving one task rather than listing all, but it does not explicitly state when to prefer this over list_tasks or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tasks worked on in the current git branch. Shows tasks that are part of the branch session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only listing operation, but with no annotations it does not explicitly state side effects, permissions, or behavior beyond returning tasks. It leaves the agent to infer that it is safe and non-mutating.
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 very concise, containing only two short sentences with no redundant wording. It is well structured and easy to scan.
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?
The description explains the basic purpose and output type ('tasks'), but with no output schema and no annotations it leaves details about the returned task fields, ordering, and the exact meaning of 'branch session' unspecified.
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?
There are no parameters, so the schema fully covers parameter semantics. The description adds no parameter detail, but none is needed.
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 verb 'list' and the resource 'tasks', scoped to the current git branch and branch session. It adequately distinguishes itself from the broader list_tasks tool, though 'branch session' is not defined.
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 is provided about when to use this tool versus alternatives such as list_tasks. The description does not mention conditions, contexts, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all members of the project (for task assignment). Project is automatically determined from API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the project is automatically determined from the API key, which is a useful behavioral detail. However, it does not explicitly state that the operation is read-only or mention any other side effects, rate limits, or authentication requirements, leaving much to inference.
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 short sentences with no redundant information. It directly states the action and a key operational detail, making it easy to parse and act upon.
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 list tool with no parameters and no output schema, the description provides sufficient context: it states what it lists, the purpose, and the auto-determination of the project. It does not specify the response format, but the name and purpose make it reasonably clear that a list of members is returned.
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 tool has zero parameters, so no semantic explanation is needed. The description adds value by clarifying that the project is inferred from the API key, effectively explaining why no project parameter is required. This exceeds the baseline for no-parameter tools.
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 specifies the verb 'list' and the resource 'members of the project', with a parenthetical purpose 'for task assignment' that distinguishes it from sibling tools focused on tasks, sessions, and attachments. The description is unambiguous about what this tool does.
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 phrase 'for task assignment' implies when to use it (to obtain assignable members), but it does not explicitly state when not to use it or how it compares to alternatives like list_tasks or get_task. Guidance is present but only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tasks for the project. Optionally filter by status, assignee, or search term.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of tasks to return | |
| search | No | Search in task title and description | |
| status | No | Filter by status (todo, in_progress, done, cancelled) | |
| assigneeId | No | Filter by assignee user ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'list' and the absence of any mutation language make it clear this is a read-only operation. No annotations are provided, but the description carries enough transparency for the expected behavior. It does not detail potential side effects, but none are anticipated for a listing 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 a single, concise sentence that front-loads the primary action ('List tasks') and then lists optional filters. There is no redundant or extraneous information, making it easy to parse quickly.
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 list operation, the description is sufficiently complete. It defines the scope (project tasks) and available filters. It does not mention results ordering, default limit, or pagination, but these are not essential for the core use case. The description covers the necessary context for an agent to decide when and how to use the tool.
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 all four parameters (limit, search, status, assigneeId) having descriptions. The description's summary of filters adds a small amount of context beyond the schema, but it largely restates the parameter descriptions. Since the schema already handles semantics, a baseline score 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 clearly states the tool's purpose: 'List tasks for the project.' It is specific and distinguishes from siblings like get_task (single task) and create_task/update_task (mutations). The optional filters are mentioned, giving a concise summary of capabilities.
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 (when you need a collection of tasks) and mentions optional filters, but it does not explicitly contrast with alternatives such as get_task for single tasks or start_work_on_task for work sessions. The guidance is implicit rather than explicit, so it's adequate but not highly instructive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Begin working on a task. Captures git baseline for change tracking. Requires clean working directory (no uncommitted changes).
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | Task ID to start working on |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions capturing a git baseline and requiring a clean working directory, which are important side effects and preconditions. However, it does not state what happens if the directory is dirty, nor does it mention any return value or further side effects, leaving some behavioral ambiguity.
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, concise and to the point. The primary action is stated first, with additional context (git baseline and clean directory requirement) provided in a logical order. No unnecessary words or redundancy.
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 tool's simplicity and lack of an output schema, the description provides sufficient context for an agent to understand the tool's role. It includes a key precondition (clean working directory) and a side effect (git baseline), which are relevant for decision-making. It could be slightly more detailed about error behavior, but overall it is adequate.
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 only parameter, taskId, is described as 'Task ID to start working on', which is clear and sufficient. Since schema coverage is 100%, the baseline is 3, and the description does not add extra detail beyond the schema, so it remains at that 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 clearly states the action ('Begin working') and the resource ('a task'), making the purpose unambiguous. It also distinguishes this tool from listing/getting tasks by implying a state change, which is distinct from the sibling tools.
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 does not explicitly contrast with alternatives like update_task or complete_task_work, but the phrase 'Begin working' strongly implies it is for initiating work rather than modifying or completing. No explicit when-to-use or when-not-to-use guidance is given, but the purpose is clear enough for basic differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing task.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | New task title | |
| status | No | New status | |
| taskId | Yes | Task ID | |
| priority | No | New priority | |
| assigneeId | No | New assignee user ID | |
| description | No | New task description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral aspects such as idempotency, partial updates, or side effects. No annotations are provided to fill this gap, leaving the agent uninformed about whether the update replaces all fields or only provided ones.
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 clear sentence with no redundant information. It is efficiently structured and easy to parse.
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 simple parameter set and no output schema, the description is adequate but minimal. It lacks context about expected outcomes (e.g., confirmation of update, updated task representation) or any special behavior, making it only partially 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?
Each parameter has a basic description like 'New task title', which adds slight clarity by indicating they are new values. However, it does not explain constraints (e.g., valid statuses, priority levels) or relationships between parameters, so it stays at baseline given full schema coverage.
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 verb 'Update' and the resource 'existing task', which is specific enough. It distinguishes from sibling tools like create_task and complete_task_work, though it could be more explicit about which fields are updatable.
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 is provided on when to use this tool versus alternatives. It does not mention that it should be used for modifying task attributes, nor does it differentiate from start_work_on_task or complete_task_work which might also involve updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a file attachment to a task.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | Task ID | |
| filePath | Yes | Local file path to upload |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior itself, but it only says 'upload'; it omits whether the attachment replaces existing files, required permissions, size limits, or side effects on the task.
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 redundant words or irrelevant details.
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 or return behavior is described, and with no annotations the description leaves out failure modes, confirmation of success, and any operational context for a write operation.
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 descriptions cover both parameters, so baseline is 3; however, 'Task ID' and 'Local file path to upload' add little beyond the parameter names, and no extra constraints or formats are given.
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 ('Upload') and identifies the resource ('file attachment to a task') and destination via taskId. It clearly distinguishes from sibling tools such as list_tasks and get_task.
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 is given about when to use this tool versus alternatives, or when not to use it. There is no mention of prerequisites, such as task existence or file availability.
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.0cancel_work_sessioncomplete_task_workcreate_pull_requestcreate_taskget_active_sessionsget_tasklist_branch_taskslist_project_memberslist_tasksstart_work_on_taskupdate_taskupload_task_attachmentScored across 12 tools
Tools are mostly distinct, with clear separation between task CRUD, work sessions, members, attachments, and PR creation. Minor potential confusion exists between list_tasks and list_branch_tasks, but descriptions clarify the branch-specific scope.
Uses a consistent snake_case verb_noun pattern overall. Slight inconsistency between start_work_on_task and complete_task_work breaks the parallel structure, but the pattern is still readable and predictable.
12 tools is well within the ideal range and each tool serves a distinct purpose in the task management and GitHub workflow. No redundant or extraneous tools.
Covers task CRUD, work session lifecycle, attachments, members, and PR creation. Missing a delete_task/archive tool is a minor gap, but the core task management and integration workflow is otherwise complete.
Manage projects, tasks, time tracking, and team collaboration through natural language.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
Manage tasks, Focus Zone, notes, projects, and task history from compatible AI assistants.
