mcp-taskflow 0.1.2 → 0.1.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +8 -0
- package/README.md +89 -4
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
package/README.md
CHANGED
|
@@ -1,30 +1,40 @@
|
|
|
1
1
|
# TaskFlow MCP
|
|
2
2
|
|
|
3
|
+
<div align="center">
|
|
4
|
+
|
|
3
5
|
[](https://badge.fury.io/js/mcp-taskflow)
|
|
4
6
|
|
|
7
|
+
**A local Model Context Protocol (MCP) server that gives AI agents structured task planning, execution tracking, and guided research workflows.**
|
|
8
|
+
|
|
9
|
+
**[Quick Start](#quick-start-)** • **[Client Setup](#client-setup-)** • **[Tools](#tools-overview-)** • **[Documentation](#documentation-)**
|
|
5
10
|
|
|
11
|
+
</div>
|
|
6
12
|
|
|
7
13
|
## Table of Contents 📌
|
|
8
14
|
|
|
9
15
|
- [Overview](#overview-)
|
|
16
|
+
- [Why Use It](#why-use-it-)
|
|
17
|
+
- [How It Augments Modern AI Tools](#how-it-augments-modern-ai-tools-)
|
|
10
18
|
- [What Is MCP?](#what-is-mcp-)
|
|
19
|
+
- [How TaskFlow Works](#how-taskflow-works-)
|
|
11
20
|
- [Quick Start](#quick-start-)
|
|
12
21
|
- [Installation](#installation-)
|
|
13
22
|
- [Basic Usage](#basic-usage-)
|
|
23
|
+
- [Client Setup](#client-setup-)
|
|
14
24
|
- [Tools Overview](#tools-overview-)
|
|
15
25
|
- [Example: Agent-in-the-Loop (ReBAC Feature)](#example-agent-in-the-loop-rebac-feature-)
|
|
16
26
|
- [Documentation](#documentation-)
|
|
17
27
|
- [Development](#development-)
|
|
18
28
|
- [Versioning](#versioning-)
|
|
29
|
+
- [Release and Git-Based Usage](#release-and-git-based-usage-)
|
|
19
30
|
- [License](#license-)
|
|
20
|
-
|
|
21
|
-
A local Model Context Protocol (MCP) server that gives AI agents structured task planning, execution tracking, and guided research workflows.
|
|
31
|
+
- [Credit](#credit-)
|
|
22
32
|
|
|
23
33
|
## Overview ✨
|
|
24
34
|
|
|
25
35
|
TaskFlow MCP helps agents turn vague goals into concrete, trackable work. It provides a persistent task system plus research and reasoning tools so agents can plan, execute, and verify tasks without re‑sending long context every time.
|
|
26
36
|
|
|
27
|
-
|
|
37
|
+
## Why Use It ✅
|
|
28
38
|
|
|
29
39
|
- **Lower token use**: retrieve structured task summaries instead of restating context.
|
|
30
40
|
- **Smarter workflows**: dependency‑aware planning reduces rework.
|
|
@@ -32,10 +42,38 @@ TaskFlow MCP helps agents turn vague goals into concrete, trackable work. It pro
|
|
|
32
42
|
- **More reliable execution**: schemas validate tool inputs.
|
|
33
43
|
- **Auditability**: clear task history, verification, and scores.
|
|
34
44
|
|
|
45
|
+
## How It Augments Modern AI Tools 🧭
|
|
46
|
+
|
|
47
|
+
TaskFlow MCP complements modern AI tooling. Tools like GitHub CLI and Skills help with repo workflows and onboarding, while TaskFlow MCP focuses on durable task state, structured planning/execution, and repeatable workflows across sessions. Use it to add persistent task memory and structured agent prompts on top of your existing toolchain.
|
|
48
|
+
|
|
35
49
|
## What Is MCP? 🤔
|
|
36
50
|
|
|
37
51
|
MCP is a standard way for AI tools to call external capabilities over JSON‑RPC (usually STDIO). This server exposes tools that an agent can invoke to plan work, track progress, and keep context consistent across long sessions.
|
|
38
52
|
|
|
53
|
+
## How TaskFlow Works 🧭
|
|
54
|
+
|
|
55
|
+
TaskFlow MCP adds a structured workflow layer on top of normal LLM chat. The server validates tool inputs and returns deterministic, structured prompts for planning and research, while persisting task state on disk so agents can resume without re‑sending long context.
|
|
56
|
+
|
|
57
|
+
```mermaid
|
|
58
|
+
flowchart LR
|
|
59
|
+
subgraph Host["MCP Host: VS Code"]
|
|
60
|
+
subgraph Client["MCP Client"]
|
|
61
|
+
Agent["Agent / Model"]
|
|
62
|
+
end
|
|
63
|
+
end
|
|
64
|
+
|
|
65
|
+
Agent -- "JSON-RPC (STDIO)" --> Server["MCP Server (taskflow)"]
|
|
66
|
+
Server -- "Structured prompts / results" --> Agent
|
|
67
|
+
Server --> Store["Data Store (DATA_DIR/.mcp-tasks)"]
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
In practice:
|
|
71
|
+
|
|
72
|
+
- The **host** runs the MCP client and the model.
|
|
73
|
+
- The **client** calls MCP tools over JSON‑RPC via STDIO.
|
|
74
|
+
- The **server** validates inputs, builds structured prompts, and returns them to the client.
|
|
75
|
+
- The **data store** keeps task state across sessions so the agent can resume without context loss.
|
|
76
|
+
|
|
39
77
|
## Quick Start 🚀
|
|
40
78
|
|
|
41
79
|
```bash
|
|
@@ -77,6 +115,7 @@ $env:DATA_DIR="${PWD}\.mcp-tasks"
|
|
|
77
115
|
Use `npx` to run the MCP server directly from GitHub. Replace `<DATA_DIR>` with your preferred data path.
|
|
78
116
|
|
|
79
117
|
Path examples:
|
|
118
|
+
|
|
80
119
|
- Windows: `<DATA_DIR>` = `C:\repos\mcp-taskflow\.mcp-tasks`
|
|
81
120
|
- macOS/Linux: `<DATA_DIR>` = `/Users/you/repos/mcp-taskflow/.mcp-tasks`
|
|
82
121
|
|
|
@@ -159,6 +198,49 @@ TaskFlow MCP exposes a focused toolset. Most clients surface these as callable a
|
|
|
159
198
|
|
|
160
199
|
Below is a simple, human‑readable script that shows how a user might ask an agent to plan and execute a feature. The agent uses TaskFlow MCP tools behind the scenes, but you don’t need MCP details to follow the flow.
|
|
161
200
|
|
|
201
|
+
### Plain Chat vs TaskFlow (ReBAC Example)
|
|
202
|
+
|
|
203
|
+
**Without TaskFlow (plain chat)**
|
|
204
|
+
Prompt:
|
|
205
|
+
|
|
206
|
+
```text
|
|
207
|
+
Create a ReBAC system from scratch.
|
|
208
|
+
```
|
|
209
|
+
|
|
210
|
+
Typical outcome:
|
|
211
|
+
|
|
212
|
+
- The model returns a large, one‑shot answer.
|
|
213
|
+
- No durable task list or dependencies.
|
|
214
|
+
- Hard to resume later without re‑explaining context.
|
|
215
|
+
- Team members have no shared, structured view of progress.
|
|
216
|
+
|
|
217
|
+
**With TaskFlow (structured workflow)**
|
|
218
|
+
Prompt:
|
|
219
|
+
|
|
220
|
+
```text
|
|
221
|
+
Create a ReBAC system from scratch. Plan the work, split tasks, then execute and verify.
|
|
222
|
+
```
|
|
223
|
+
|
|
224
|
+
Typical outcome:
|
|
225
|
+
|
|
226
|
+
- The model generates a plan via `plan_task`.
|
|
227
|
+
- Tasks are created and tracked via `split_tasks` (with dependencies).
|
|
228
|
+
- Each task is executed and marked in progress via `execute_task`.
|
|
229
|
+
- Results are verified and scored via `verify_task`, with adjustments logged.
|
|
230
|
+
- State is persisted in the datastore, so anyone can `list_tasks` and `get_task_detail` to continue or review.
|
|
231
|
+
|
|
232
|
+
**Why this matters for teams**
|
|
233
|
+
|
|
234
|
+
- The task list, notes, and verification results are stored on disk and can be shared in the repo or a shared data directory.
|
|
235
|
+
- A teammate can open the same workspace and immediately see the current task state without reading long chat history.
|
|
236
|
+
|
|
237
|
+
**Dependency management**
|
|
238
|
+
|
|
239
|
+
- Tasks can declare explicit prerequisites, so the agent knows what must happen first.
|
|
240
|
+
- Dependencies prevent blocked work: a task can’t be executed until its upstream tasks are complete.
|
|
241
|
+
- Dependencies are stored with tasks, so any teammate can see the critical path and pick up the next unblocked item.
|
|
242
|
+
- For example: “Integrate with existing auth” cannot start until both “Define ReBAC model” and “Design storage layer” are completed.
|
|
243
|
+
|
|
162
244
|
**User**
|
|
163
245
|
“I want to add a Relationship‑Based system. Create a task list and start working through it.”
|
|
164
246
|
|
|
@@ -188,6 +270,7 @@ Below is a simple, human‑readable script that shows how a user might ask an ag
|
|
|
188
270
|
“I’ll mark the first task as in progress and add notes as I go.”
|
|
189
271
|
|
|
190
272
|
**Progress updates**
|
|
273
|
+
|
|
191
274
|
- Task 1: In progress — “Drafted entity/relationship schema and example checks”
|
|
192
275
|
- Task 1: Completed — “Added model doc and validation rules”
|
|
193
276
|
- Task 2: In progress — “Evaluating graph storage options”
|
|
@@ -202,6 +285,7 @@ Below is a simple, human‑readable script that shows how a user might ask an ag
|
|
|
202
285
|
- **Next step**: start Task 2 with the normalized model in place
|
|
203
286
|
|
|
204
287
|
**Why this helps**
|
|
288
|
+
|
|
205
289
|
- The agent keeps a durable task list and status updates.
|
|
206
290
|
- You can stop and resume without losing context.
|
|
207
291
|
- Large features become manageable, with explicit dependencies.
|
|
@@ -235,6 +319,7 @@ This project uses **Changesets** for versioning and release notes. See `CONTRIBU
|
|
|
235
319
|
Git-based execution assumes the repository is buildable and includes a valid `bin` entry in `package.json`. For production or shared use, prefer a tagged release published via Changesets.
|
|
236
320
|
|
|
237
321
|
Typical flow:
|
|
322
|
+
|
|
238
323
|
1. Add a changeset in your PR.
|
|
239
324
|
2. CI creates a release PR with version bumps and changelog entries.
|
|
240
325
|
3. Merging the release PR publishes to npm and creates a GitHub release.
|
|
@@ -252,6 +337,7 @@ npx git+https://github.com/CalebGerman/mcp-taskflow.git mcp-taskflow
|
|
|
252
337
|
```
|
|
253
338
|
|
|
254
339
|
**Prerequisites**:
|
|
340
|
+
|
|
255
341
|
- `bin` entry points to `dist/index.js`
|
|
256
342
|
- `pnpm build` completes successfully
|
|
257
343
|
|
|
@@ -272,4 +358,3 @@ Also informed by related MCP server patterns and workflows:
|
|
|
272
358
|
```text
|
|
273
359
|
https://www.nuget.org/packages/Mcp.TaskAndResearch
|
|
274
360
|
```
|
|
275
|
-
|