This server provides read-only, SQLite-backed MCP tools for accessing a developer's DevTrack context, including active ticket, commits, pending actions, voice profile, and end-of-day summaries.
Get active work context — Retrieve the current active ticket, repo path, today's commit count, and ticket-mapping confidence.
Get today's commits — List today's commits grouped by ticket ID, with optional repository-path filtering.
Get pending actions — Review the queue of actions DevTrack wants to take, including confidence scores and expiry times.
Get ticket context — Fetch full context for a specific ticket: recent commits, related pending actions, and last activity time.
Get voice profile — View the developer's inferred writing style for different contexts (commit, comment, report, task, ticket mapping).
Get end-of-day summary — Retrieve a template-based EOD narrative draft summarizing the day's commits by ticket.
Comment on issues/PRs, sync recent activity, and alert on review requests.
Comment on issues; list, view, create, and sync issues through the Go connector.
Supports posting commit comments and transitioning tickets, with server-side webhook integration for PM workflows.
Never write a standup again.
DevTrack watches your Git work, connects it to tickets, and prepares status updates and end-of-day reports in the background. It is local-first, offline-capable, and stages outbound actions for your review.
Website · Download · Documentation · Latest release
Observes commits without interrupting or replacing normal Git commands.
Reports completed work without tracking hours or time spent per task in the v3.3.0 development line.
Maps ticket-named branches such as feature/AUTH-42-refresh-token to work items.
Builds reviewable ticket updates and end-of-day reports from the work already completed.
Keeps its client-side source of truth in local SQLite and uses Ollama by default for local AI.
Shares current work and DevTrack Sage knowledge with compatible assistants through ten read-only MCP tools.
Nothing is posted merely because DevTrack generated it. PM updates, transitions, and deliveries are placed in a pending-actions queue until approved. Anonymous telemetry is also opt-in and disabled by default.
Related MCP server: devbase
DevTrack supports Windows, macOS, and Linux. Git is required. The core Go client, SQLite storage,
Git observation, queue, and MCP features do not require Python or an AI model. Managed AI features
add uv, PostgreSQL, and an LLM provider; Ollama is the default.
Use the guided download page, or install the latest stable release directly:
Linux or macOS
curl -fsSL https://devtrack.cloud/install.sh | shWindows PowerShell
irm https://devtrack.cloud/install.ps1 | iexManual binaries and checksums are available on GitHub Releases.
Stable v3.2.0 retains the former time-tracking behavior. The fixes and removal are on dev at
860b91b, prepared for v3.3.0; rolling development builds use dev-<commit>. A push to dev does
not upgrade an installed binary or publish a new stable release. See the
development release notes and qualification plan.
devtrack versionRun setup from the Git repository you want DevTrack to observe:
cd /path/to/your/repository
devtrack setup
devtrack start
devtrack status
devtrack doctorThe setup wizard configures the operating mode, repository, LLM, identity, and optional PM
integration. Choose none for the PM integration when evaluating the local-only path. Managed mode
requires PostgreSQL for the optional Python service; Go-native features remain available while that
service and the model are being prepared.
Use a ticket-named branch and commit normally:
git switch -c feature/AUTH-42-refresh-token
git commit -m "fix auth redirect"
devtrack logs
devtrack queue
devtrack eodqueue lets you inspect staged actions before approving anything. See the
Quick Start for the complete first-run walkthrough.
In the development line, capture enumerates unseen commits across local branch tips, so rapid commits and switching branches during processing are included. Keep the daemon running: existing history is seeded at startup, and catch-up for commits made while it was stopped is not guaranteed.
devtrack work start AUTH-42 selects fallback ticket context; work stop clears it and work status
shows it. These commands do not start or stop timers. devtrack work report generates a commit-based
EOD report through the configured server.
Incidents, stories, bugs, and tasks all map by their work-item reference: for example, a Jira
incident hotfix/OPS-123-restore-login, Azure DevOps story feature/ADO-456-add-export, or
GitHub issue fix/GH-42-handle-timeout. The PM system supplies the item type; the branch kind
does not. A canonical branch wins over an explicit commit reference, which wins over selected
ticket context. Run devtrack ticket convention and devtrack ticket check <branch> to inspect
the rule, or devtrack ticket link <commit-hash> <ticket-ref> to correct an observed mapping.
See work-item and ticket mapping for configuration, conflicts, and examples.
devtrack eod status and devtrack eod show read the latest report across local and server history.
devtrack queue list --all shows recent actions from both stores. Server actions use IDs such as
server:123: pass that full ID to queue approve, queue reject, or queue edit. Bare numeric IDs
address local actions. An unavailable server is reported explicitly.
Add DevTrack's read-only MCP server to the current project:
devtrack mcp setup
devtrack mcp test
devtrack mcp statusReload your MCP-capable assistant after setup. It can then read current ticket context, commits, pending actions, EOD context, voice information, and published Sage knowledge. MCP cannot approve actions or modify DevTrack data.
DevTrack Sage captures useful command activity from supported coding harnesses and turns repeated work into searchable local Markdown knowledge:
devtrack sage status
devtrack sage search "docker compose"
devtrack sage topicsLearn more in MCP and Agent Memory and DevTrack Sage.
I want to… | Guide |
Install or upgrade DevTrack | |
Complete the first-run workflow | |
Understand deployment choices | |
Configure repositories, integrations, or models | |
Find a command | |
Connect an AI assistant | |
Use local command knowledge | |
Fix an installation or runtime problem | |
Review privacy and data flow | |
Qualify automatic capture and reporting | |
Map incidents, stories, bugs, and tasks | |
Review the v3.3.0 development boundary |
Contributors and maintainers can start with the repository documentation map and architecture.
The default Go, SQLite, and Ollama path stays local. External PM systems, delivery channels, and
cloud LLMs receive data only when configured for the corresponding operation. Telemetry remains off
until explicitly enabled with devtrack telemetry on. Read the full
privacy guide before enabling external services.
DevTrack uses the DevTrack Community License: free for personal use and teams of up to 10 users; larger teams and hosted use require an enterprise license.
Returns the developer's current active ticket, repo path, today's commit count, and confidence in the ticket mapping. This is the primary context tool — call it first.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) by using 'Returns', and it adds genuinely useful behavioral detail by disclosing that the ticket mapping carries a confidence score — signaling the mapping may be imperfect. No error, rate-limit, or edge-case behavior is disclosed, but for a read-only no-parameter getter, the transparency is adequate and non-contradictory.
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 tight sentences: the first front-loads the return payload with concrete fields, the second delivers the usage priority. Every word carries information; there is no filler, redundancy, or buried context.
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 low complexity (no parameters, no output schema, simple annotations), the description covers the essential ground: what data comes back and when to call it. It does not describe the output format or edge-case behavior (e.g., what happens when no ticket is active), but for a simple getter the listed fields plus the 'call first' guidance are reasonably 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?
With zero parameters and 100% schema coverage (empty object), there is nothing for the description to clarify. The rubric's baseline of 4 for a zero-parameter tool applies; the description correctly avoids inventing parameter explanations, so no deduction is warranted.
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 ('Returns') and names the precise resource and payload: the active ticket, repo path, today's commit count, and confidence in the ticket mapping. This clearly differentiates it from siblings like get_ticket_context (single ticket), get_today_commits (commit list), and get_eod_summary (end-of-day view), making the aggregate-snapshot purpose 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 explicit directive 'This is the primary context tool — call it first' gives strong, actionable guidance on when to invoke it as the entry point. It stops short of naming sibling tools or stating when NOT to use it (e.g., when a detailed ticket or commit breakdown is needed), but the priority instruction is clear and sufficient for an agent to sequence correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns today's EOD narrative draft — a summary of the day's commits grouped by ticket, suitable for a standup or daily report. Template-based (no LLM required).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds that it is template-based and requires no LLM, which gives extra insight into its deterministic behavior without contradicting the 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?
The description is a single concise sentence that clearly conveys the tool's purpose and key characteristics without unnecessary verbosity. It is well-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 tool has no parameters and no output schema, the description fully explains what it returns (EOD narrative draft) and its intended use. No additional information is needed for an agent to understand and invoke the tool correctly.
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 no parameters, making schema coverage trivially 100%. The description adds no parameter details since none exist, 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 tool returns today's EOD narrative draft, a summary of commits grouped by ticket. It uses a specific verb ('Returns') and a specific resource, and the 'no LLM required' note differentiates it from potentially similar generation 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 provides a context ('suitable for a standup or daily report') but does not explicitly compare with sibling tools like get_today_commits or get_active_context. It lacks an explicit 'use this instead of X when...' statement, so guidance is implied rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the current pending actions queue — actions DevTrack wants to take but hasn't yet. Each action has a confidence score and an expiry time.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, and non-destructive behavior, which the description aligns with by simply returning data. No side effects or permissions are described, but the annotations cover these aspects, and the description adds context about the returned data.
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, using two sentences to convey purpose and output structure. Every word adds value, and there is no redundancy or unnecessary detail.
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 there is no output schema, the description provides sufficient context by mentioning that each action has a confidence score and expiry time. This gives the agent a reasonable expectation of the result format, though it does not enumerate all possible fields or variations.
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 no parameters, and the schema coverage is complete (0 parameters). The baseline for 0 parameters is 4, and the description does not introduce any parameter-related ambiguity. It correctly focuses on the output instead.
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: returning the current pending actions queue. It also provides specific details about the content (confidence score, expiry time) and the subject (DevTrack), making it distinct from generic getters. The verb 'returns' is explicit.
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 pending actions are needed, but it does not explicitly mention when to use this tool versus alternatives like get_active_context or get_today_commits. No alternative tools are referenced, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns full context for a named ticket: recent commits, current pending actions targeting it, and its last activity time.
| Name | Required | Description | Default |
|---|---|---|---|
| ticket_id | Yes | The ticket ID, e.g. PROJ-123 or AB-7 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds no further behavioral details (e.g., rate limits, errors, side effects) but also does not contradict the annotations, so a neutral score is appropriate.
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 that front-loads the primary purpose and lists the returned components without unnecessary verbosity. It is highly concise and well-structured.
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 lists the key components of the returned context (commits, actions, last activity), which gives a clear idea of what the tool provides. It does not specify output structure or error cases, but for a simple read-only context tool, it is reasonably 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?
The only parameter ticket_id is well-described with an example in the schema. The description does not add additional semantic nuance beyond what the schema already provides, so it meets the baseline for high 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 tool returns full context for a named ticket, listing specific components (recent commits, recent actions, last activity). The verb 'returns' and the resource 'ticket' are explicit, and it distinguishes itself from siblings like get_active_context by focusing on a named ticket.
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 by stating it returns context for a named ticket, but it does not explicitly state when to use this tool versus alternatives like get_active_context or get_pending_actions. No when-not-to-use guidance is provided, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all commits from today, grouped by ticket ID, with message and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | No | Filter by repository path. Omit for all repos. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description ('Returns') aligns with the readOnlyHint=true and destructiveHint=false annotations, with no contradiction. It does not add extra behavioral details beyond the annotations, but the annotations already cover safety, so the description is adequate.
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. It delivers all necessary information efficiently, with the key details front-loaded.
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?
Without an output schema, the description provides some output context ('with message and metadata') to hint at the return structure. This is sufficient for a simple tool, though a bit more detail could improve completeness.
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 description for repo_path ('Filter by repository path. Omit for all repos.') fully explains the parameter, achieving 100% coverage. The main description does not add further parameter context, so it stays at the baseline for schema-covered 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?
The description clearly states the action ('Returns'), the resource ('commits'), and the scope ('from today', grouped by ticket ID). None of the sibling tools (e.g., get_eod_summary, get_ticket_context) overlap with commit retrieval, so it is easily distinguished.
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 explains what the tool does but does not explicitly state when to use it over alternatives or provide usage conditions. Since siblings are distinct, the lack of explicit guidance is acceptable, but it does not meet the 'explicit when/when-not' standard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the developer's inferred writing style profile for a given context type. Use this to understand how the developer prefers to communicate before generating text on their behalf.
| Name | Required | Description | Default |
|---|---|---|---|
| context_type | No | The writing context to retrieve style inferences for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate read-only, idempotent, and non-destructive behavior. The description does not add any additional behavioral traits such as caching, error conditions, or side effects. It simply says 'returns', which is consistent with the annotations but does not go beyond them, so it meets the baseline but not higher.
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 long, free of jargon or redundant phrases, and gets straight to the point. It clearly states what the tool does and when to use it without any unnecessary 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?
For a simple getter with a single parameter and no output schema, the description is complete. It tells the agent what the tool returns, the purpose of the parameter, and the use case, so nothing essential is missing.
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 description for context_type already explains it as 'The writing context to retrieve style inferences for' with an enumerated list of values. The tool description only repeats this in different words ('given context type') without adding any new meaning or nuance, so the description adds no value 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?
The description clearly states it returns a writing style profile for a given context type, which is distinct from the sibling tools that deal with other types of information. The verb 'returns' is specific and the resource 'developer's inferred writing style profile' is well-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?
It explicitly says to use this tool to understand the developer's communication preferences before generating text, which is a clear when-to-use. However, it does not mention when not to use it or compare it to alternative tools, such as get_active_context or get_today_commits, so it lacks the explicit alternatives that would earn a 5.
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.
v3.1.1get_active_contextget_eod_summaryget_pending_actionsget_ticket_contextget_today_commitsget_voice_profileScored across 6 tools
Each tool has a distinct purpose: active context, EOD summary, pending actions, ticket context, today's commits, and voice profile. Some overlap exists around commit data, but the descriptions clearly differentiate raw commits, summaries, and ticket-specific views.
All tool names follow a consistent get_<noun> pattern with clear, descriptive suffixes. There is no mixing of naming conventions or vague verb choices.
With 6 tools, the set is well-scoped for a developer-context server. Each tool covers a meaningful slice of the domain without unnecessary bloat.
The read-only context domain is well covered: active state, daily commits, pending actions, ticket details, EOD summary, and communication style. There is no obvious missing getter, though a way to browse historical days or all tickets could be considered a minor gap.
Opinionated sprint tracker. Read/update tickets, sprints, velocity from Claude/Cursor/Zed.
Privacy-first work tracking with summaries, reports, coaching, and AI-ready long-term memory.
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
