Agent-Native Calendar
Agent-Native Google Calendar - manage events, sync, and public booking
Beschreibung vom Entwickler (englisches Original)
MCP server for agent task workflows with phases, prompts, gates, and multi-agent coordination
Diese drei werden nie zu einer Punktzahl zusammengefasst: Meinungen, Messungen und Beliebtheit sind verschiedene Dinge.
Für diesen Server haben wir noch keine Zusammenfassung in einfacher Sprache geschrieben. Unten stehen die Fakten, die wir aus der Registry gelesen haben.
Wähle die KI-App, die du nutzt, und kopiere die Einstellungen.
Welche App nutzt du?
Wähle oben deine App. Wir merken sie uns, damit der Button beim nächsten Mal „In … installieren“ anzeigt.
Die .mcpb-Datei des Entwicklers herunterladen
Der Link führt zur Datei des Entwicklers selbst; wir hosten sie nicht und verpacken sie nicht neu. Öffne die Datei, dann installiert Claude Desktop sie.
Führe das in deinem Terminal aus
Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
Dieser Server läuft auf deinem Computer, und ChatGPT kann sich nur mit Servern im Internet verbinden. Wähle eine andere App.
Deine Auswahl bleibt in einem Cookie auf diesem Gerät; kein Konto nötig.
Diese Einstellungen werden aus dem Registry-Eintrag des Entwicklers erzeugt. Wenn in der README etwas anderes steht, folge der README.
Läuft auf deinem Computer; die Tool-Liste erscheint nach der Installation in deiner KI-App.
Wir prüfen Informationen, die jeder sehen kann; den Code haben wir nicht gelesen. Checks, die nicht zutreffen, werden nicht mitgezählt. · Geprüft am 6. Nov. 2026
Der Registry-Name wurde mit dem GitHub-Konto Oortonaut bestätigt, dem das Repo gehört
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieser Server läuft auf deinem Computer; es gibt keinen Endpunkt im Internet
Läuft auf deinem Computer und nutzt stattdessen lokale Einstellungen
Läuft auf deinem Computer; Tool-Listen können wir nur von Endpunkten im Internet lesen
Verglichen mit allen aktiven Servern dieser Kategorie in der Registry. Sterne zählen nur, wenn dem Herausgeber das Repo gehört.
Er hat 1 von 1 zutreffenden Basischecks bestanden. Den Code haben wir nicht gelesen. Bevor du einen Schlüssel oder Token hinzufügst, sieh nach, welche Zugriffe der Server verlangt, und nutze einen Schlüssel, der nur die Berechtigungen hat, die du brauchst.
Die Registry nennt keinen erforderlichen Schlüssel, manche Server bitten dich aber bei der ersten Nutzung, dich anzumelden.
Er läuft auf deinem Computer. Deine KI-App startet ihn bei Bedarf, und die Daten laufen nicht über die Server des Entwicklers (außer der Server ruft selbst einen Onlinedienst auf).
Das GitHub-Repo wurde zuletzt – geändert, und die neueste Version (0.3.0) kam vor 9 Monaten in die Registry.
Apps, die MCP unterstützen, etwa Claude Desktop, Claude Code, Cursor und VS Code. Außerdem brauchst du MCPB auf deinem Computer.
In derselben Kategorie: Agent-Native Calendar, Excel MCP Server, MCP Server for Excel
Server derselben Kategorie von anderen Entwicklern, sortiert nach Sternen.
So liest du eine Karte:★ GitHub-SterneiDrei Säulen: Bewertungen · Checks · NutzungiAktualisiert = neueste Version in der Registry veröffentlichti
Agent-Native Google Calendar - manage events, sync, and public booking
Create and edit Excel files with AI: charts, PivotTables, formulas. No Excel needed.
Excel automation for AI - Sheets, Power Query, DAX, VBA, Tables, Ranges and more. Windows only.
Unverändert aus dem Repo des Entwicklers übernommen. PopNx MCP hat den Inhalt weder geprüft noch empfiehlt es ihn. HTML, Bilder und Skripte wurden entfernt. Links führen von dieser Website weg.
Agent task workflows that actually work.
When you have AI agents working on complex tasks, things go wrong fast. Agents lose context, skip steps, forget to coordinate. Task Graph solves this with structured workflows: phases to guide work, prompts for automatic guidance, gates to enforce quality, and coordination primitives for multi-agent scenarios—all through the Model Context Protocol.
The problem: You've got complex tasks that need structured execution. Maybe a single agent working through phases, or multiple agents coordinating in parallel. Without proper workflows, agents lose track, skip steps, and produce inconsistent results.
What you get:
| Feature | Description |
|---|---|
| Task Hierarchy | Unlimited nesting with parent/child relationships |
| DAG Dependencies | Typed edges (blocks, follows, contains) with cycle detection |
| Phases | Categorize work type (explore, implement, review, test, deploy) |
| Workflows | Named workflow topologies (solo, swarm, relay, hierarchical) |
| Transition Prompts | Automatic agent guidance on status/phase changes |
| Gates | Exit requirements for status/phase transitions |
| Atomic Claiming | Strict locking with limits and tag-based routing |
| File Coordination | Advisory locks with reasons and change polling |
| Cost Tracking | Token usage and USD cost per task |
| Time Tracking | Automatic accumulation from state transitions |
| Live Status | Real-time "current thought" visible to other agents |
| Full-text Search | FTS5-powered search across tasks and attachments |
| Attachments | Inline content, file references, or media storage |
| Agent Feedback | Inter-agent communication with categorized feedback (conditional on config) |
| Dynamic Overlays | Runtime workflow customization via add/remove overlay tools |
# Install
cargo install task-graph-mcp
{
"mcpServers": { "task-graph": { "command": "task-graph-mcp" } } }
connect(workflow="swarm", tags=["code"]) → "bright-lunar-swift-fox" list_tasks(ready=true, agent="bright-lunar-swift-fox") → claimable work claim(worker_id="bright-lunar-swift-fox", task="add-auth") → you own it update(..., phase="implement") → enter implementation phase thinking(agent="bright-lunar-swift-fox", thought="Adding JWT...") → visible to others update(worker_id="bright-lunar-swift-fox", task="add-auth", status="completed", attachments=[{type:"commit", content:"abc123"}]) → done
cargo install task-graph-mcp
Download the latest release for your platform from GitHub Releases:
| Platform | Download |
|---|---|
| Linux (x64) | task-graph-mcp-x86_64-unknown-linux-gnu.tar.gz |
| macOS (Intel) | task-graph-mcp-x86_64-apple-darwin.tar.gz |
| macOS (Apple Silicon) | task-graph-mcp-aarch64-apple-darwin.tar.gz |
| Windows (x64) | task-graph-mcp-x86_64-pc-windows-msvc.zip |
Extract and place the binary in your PATH.
git clone https://github.com/Oortonaut/task-graph-mcp.git
cd task-graph-mcp cargo build --release
The binary will be at target/release/task-graph-mcp.
Add to your MCP client configuration:
{
"mcpServers": { "task-graph": { "command": "task-graph-mcp", "args": [] } } }
task-graph-mcp [OPTIONS]
Options: -c, --config Path to configuration file -d, --database Path to database file (overrides config) -v, --verbose Enable verbose logging -h, --help Print help -V, --version Print version
Full reference: See docs/CONFIGURATION.md for complete configuration documentation including workflows, prompts, gates, roles, and tags.
Create .task-graph/config.yaml:
server:
db_path: .task-graph/tasks.db media_dir: .task-graph/media # Directory for file attachments skills_dir: .task-graph/skills # Custom skill overrides stale_timeout_seconds: 900 default_format: json # or markdown
paths: style: relative # or project_prefixed
auto_advance: enabled: false # Auto-transition unblocked tasks target_state: ready # Target state (requires custom state in states config)
Task states are configurable. Default states: pending, working, completed, failed, cancelled.
To add a ready state for auto-advance:
states:
initial: pending disconnect_state: pending # State for tasks when owner disconnects (must be untimed) blocking_states: [pending, working] definitions: pending: exits: [ready, working, cancelled] ready: exits: [working, cancelled] working: exits: [completed, failed, pending] timed: true # Time in this state counts toward time_actual_ms completed: exits: [] failed: exits: [pending] cancelled: exits: []
auto_advance: enabled: true target_state: ready
See SCHEMA.md for full documentation on state definitions.
Dependency types define how tasks relate to each other. Default types: blocks, follows, contains, duplicate, see-also, relates-to.
dependencies:
definitions: blocks: display: horizontal # Same-level relationship blocks: start # Blocks claiming the dependent task follows: display: horizontal blocks: start contains: display: vertical # Parent-child relationship blocks: completion # Blocks completing the parent duplicate: display: horizontal blocks: none # Informational only see-also: display: horizontal blocks: none relates-to: display: horizontal blocks: none
| Property | Values | Description |
|---|---|---|
display | horizontal, vertical | Visual relationship (same-level vs parent-child) |
blocks | none, start, completion | What the dependency blocks |
Preconfigured attachment keys provide default MIME types and modes, reducing boilerplate when attaching common content types.
attachments:
unknown_key: warn # allow | warn (default) | reject definitions: commit: mime: text/git.hash mode: append checkin: mime: text/p4.changelist mode: append meta: mime: application/json mode: replace note: mime: text/plain mode: append
| Property | Values | Description |
|---|---|---|
unknown_key | allow, warn, reject | Behavior for undefined attachment keys |
definitions. .mime | MIME type string | Default MIME type for this key |
definitions. .mode | append, replace | Default mode (append keeps existing, replace overwrites) |
Built-in defaults:
| Key | MIME Type | Mode | Use Case |
|---|---|---|---|
commit | text/git.hash | append | Git commit hashes |
checkin | text/p4.changelist | append | Perforce changelists |
changelist | text/plain | append | Files changed |
meta | application/json | replace | Structured metadata |
note | text/plain | append | General notes |
log | text/plain | append | Log output |
error | text/plain | append | Error messages |
output | text/plain | append | Command/tool output |
diff | text/x-diff | append | Patches and diffs |
plan | text/markdown | replace | Plans and specs |
result | application/json | replace | Structured results |
context | text/plain | replace | Current context/state |
Usage:
# MIME and mode auto-filled from config:
attach(task="123", name="commit", content="abc1234")
attach(task="123", name="meta", content='{"v":1}')
attach(task="123", name="commit", mime="text/plain", content="override")
Environment variables:
TASK_GRAPH_CONFIG_PATH: Path to configuration file (takes precedence over .task-graph/config.yaml)TASK_GRAPH_DB_PATH: Database file path (fallback if no config file)TASK_GRAPH_MEDIA_DIR: Media directory for file attachments (fallback if no config file)TASK_GRAPH_LOG_DIR: Log directory path (fallback if no config file)| Tool | Description |
|---|---|
connect(worker_id?, tags?, workflow?, force?, db_path?, media_dir?, log_dir?, config_path?, overlays?: str[]) | Register a worker. Optional workflow selects named workflow (solo, swarm, relay, hierarchical). Returns worker_id and active paths. |
disconnect(worker_id: worker_str, final_status?: status_str = "pending") | Unregister worker and release all claims/locks. |
list_agents(tags?: str[], file?: filename, task?: task_str, depth?: int, stale_timeout?: int) | List connected workers with filters. |
cleanup_stale(timeout?: int, final_status?: status_str) | Evict stale workers and release their claims. |
add_overlay(worker_id: str, overlay: str) | Add a dynamic workflow overlay to a connected worker. |
remove_overlay(worker_id: str, overlay: str) | Remove a workflow overlay from a connected worker. |
| Tool | Description |
|---|---|
create(description: str, id?: task_str, parent?: task_str, priority?: int = 5, points?: int, time_estimate_ms?: int, tags?: str[]) | Create a task. Priority 0-10 (higher = more important). |
create_tree(tree, parent?, child_type?, sibling_type?) | Create nested task tree. child_type (default: "contains") for parent→child deps, sibling_type for sibling deps. |
get(task: task_str) | Get task by ID with attachment metadata and counts. |
list_tasks(status?: status_str[], ready?: bool, blocked?: bool, claimed?: bool, owner?: worker_str, parent?: task_str, recursive?: bool, agent?: worker_str, tags_any?: str[], tags_all?: str[], sort_by?: str, sort_order?: str, limit?: int, offset?: int) | Query tasks with filters. Use ready=true for claimable tasks. |
| update(worker_id: worker_str, task: task_str, status?: status_str, phase?: str, assignee?: worker_str, title?: str, description?: str, priority?: int, points?: int, tags?: str[], needed_tags?: str[], wanted_tags?: str[], time_estimate_ms?: int, reason?: str, force?: bool, attachments?: object[]) | Update tas
Nur der Anfang wird gezeigt; den Rest findest du im Repo