AgentDock MCP Harness
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| repo.inspectA | Inspect a local Git repository without modifying its working tree. |
| task.createA | Create an ACTIVE coding task in a clean detached Git worktree based on source HEAD. |
| task.resumeB | Resume a durable Task by task_id and return restored process metadata. |
| task.finishA | Explicitly mark an ACTIVE Task COMPLETED after processes stop and the worktree is committed. |
| task.cancelA | Cancel an ACTIVE Task, best-effort stopping its running processes while preserving the worktree. |
| task.cleanupA | Remove the worktree of a COMPLETED or CANCELLED Task while preserving durable Task metadata. |
| file.readA | Read a UTF-8 file. Relative paths use the Task worktree; absolute paths use the host OS. |
| file.searchB | Search files using deterministic text matching and a glob. Relative paths use the Task worktree; absolute paths use the host OS. |
| file.patchB | Patch an existing file if its SHA-256 still matches. Relative paths use the Task worktree; absolute paths use the host OS. |
| file.writeB | Create or replace a UTF-8 file. Relative paths use the Task worktree; absolute paths use the host OS. |
| git.diffA | Return structured Task worktree changes and unified diff, including untracked files. |
| git.commitA | Stage all Task worktree changes and create a real local Git commit without push, merge, or deploy. |
| audit.getB | Return structured persisted Task audit entries after a sequence cursor. |
| approval.getB | Return a durable approval request by Task and approval_id. |
| approval.respondC | Resolve or escalate a durable approval request. |
| process.startC | Start an asynchronous Task process using explicit argv or shell mode. |
| process.statusC | Return current status and execution metadata for a Task process. |
| process.outputA | Read process stdout/stderr incrementally from a pull cursor. |
| process.cancelA | Best-effort cancel a running Task process and its Linux process group. |
| skill.listA | List installed server-side skills without invoking or executing them. |
| skill.searchB | Search installed server-side skills by name, category, and description. |
| skill.readA | Read the recommended installed SKILL.md or one of its supporting files. Follow the returned instructions in the chat model; if they reference another skill or local resource, read that resource explicitly instead of treating skills as executable server code. |
| skill.installB | Install a Git-backed skill source into AgentDock state. This stores instructions only; it does not execute a skill or run an LLM. |
| skill.updateA | Reinstall an existing skill source from its recorded Git URL/ref and report whether the source commit changed. |
| workflow.startA | Start durable guided-development state for a new software goal. Use this when the user wants development guidance or does not know the next step; classify session_span and route_clarity from the conversation/repository. Existing state is protected unless replace=true, and first-use setup plus deterministic routing are enforced. |
| workflow.listA | List durable guided-development workflows so the assistant can recover active projects across chats before asking the user to repeat context. |
| workflow.updateA | Persist progress inside the current guided-development phase without crossing a phase boundary. Use it to keep open decisions, routing observations, and artifact paths durable across chats. |
| workflow.guideA | Read durable guided-development state and recommend the next workflow skill without executing it. Use this whenever the user says continue, asks what to do next, or says they do not know the next development step; then read the recommended skill and follow it in the chat model. |
| workflow.advanceA | Advance guided-development state only after the recommended skill has actually reached an explicit phase boundary. Never use this to skip unresolved decisions; invalid jumps fail closed and the durable history records the transition. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 29 tools
Each tool targets a distinct resource and action, with clear prefixes for domains (skill, git, audit, approval, process, repo, task, workflow, file). Within each domain, verbs are specific (list, search, read, install, update, commit, get, respond, start, status, output, cancel, inspect, create, resume, finish, cleanup, guide, advance, patch, write, diff) with no overlapping purposes. The only mild overlap is between git.diff and repo.inspect, but their descriptions clarify that git.diff is Task-specific while repo.inspect is generic, so ambiguity is minimal.
All 29 tools follow the consistent pattern <domain>.<action> with lowercase snake_case actions. The action verbs are uniform across domains (list, search, read, install, update, create, start, etc.), and there are no style mixing or irregular naming conventions. The pattern is predictable and easy to infer.
With 29 tools, the count is on the heavier side, exceeding the typical 3-15 range and even the 25+ threshold that suggests over-scoping. However, the server covers a broad domain (skills, tasks, processes, workflows, files, git, audit, approvals), so each tool appears to serve a specific need. Still, it feels slightly bloated, and some tools could potentially be consolidated (e.g., task.resume and process.status overlap in restoring metadata), so a score of 3 is appropriate.
The tool surface covers the full lifecycle for tasks (create, resume, finish, cancel, cleanup), processes (start, status, output, cancel), workflows (start, list, update, guide, advance), and files (read, search, patch, write). Git operations include commit, diff, and inspect. Skills have list, search, read, install, update. Approvals and audit are covered. Minor gaps include no task.list to enumerate tasks, no process.list to enumerate running processes, and no skill uninstall/delete, but these are non-critical and agents can work around them via existing tools.