Agent-Native Calendar
Agent-Native Google Calendar - manage events, sync, and public booking
Descripción del creador (original en inglés)
MCP server for agent task workflows with phases, prompts, gates, and multi-agent coordination
Estos tres nunca se combinan en una sola puntuación: las opiniones, las mediciones y la popularidad son cosas distintas.
Todavía no escribimos un resumen sencillo para este. Abajo están los datos que leímos del registro.
Elige la app de IA que usas y copia la configuración.
¿Qué app usas?
Elige tu app arriba. La recordamos, así que la próxima vez el botón dirá “Instalar en …”.
Descargar el archivo .mcpb del creador
El enlace lleva al archivo del propio creador; no lo alojamos ni lo reempaquetamos. Abre el archivo y Claude Desktop lo instalará.
Ejecuta esto en tu terminal
Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.
Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.
Este se ejecuta en tu computadora, y ChatGPT solo puede conectarse a servidores en internet. Elige otra app.
Tu elección se guarda en una cookie en este dispositivo; no necesitas cuenta.
Esta configuración se genera a partir de la ficha del creador en el registro. Si el README dice otra cosa, sigue el README.
Se ejecuta en tu computadora; la lista de herramientas aparece en tu app de IA después de instalarlo.
Revisamos información que cualquiera puede ver; no hemos leído el código. Las revisiones que no aplican no se cuentan. · Revisado el 6 nov 2026
El nombre en el registro se verificó con la cuenta de GitHub Oortonaut, dueña del repo
Todavía no hemos leído este repo en GitHub
Todavía no hemos leído este repo en GitHub
Este se ejecuta en tu computadora; no hay endpoint en internet
Se ejecuta en tu computadora y usa ajustes locales en su lugar
Se ejecuta en tu computadora; solo podemos leer listas de herramientas de endpoints en internet
Comparado con todos los servidores activos de esta categoría en el registro. Las estrellas solo cuentan cuando quien lo publica es dueño del repo.
Superó 1 de 1 revisiones básicas aplicables. No hemos leído el código. Antes de agregar una clave o un token, revisa qué acceso pide el servidor y usa una clave que tenga solo los permisos que necesitas.
El registro no indica ninguna clave obligatoria, aunque algunos servidores te piden iniciar sesión la primera vez que los usas.
Se ejecuta en tu computadora. Tu app de IA lo inicia cuando hace falta, y los datos no pasan por los servidores del creador (a menos que el propio servidor llame a un servicio en línea).
El repo de GitHub cambió por última vez –, y la última versión (0.3.0) llegó al registro hace 9 meses.
Las apps compatibles con MCP, como Claude Desktop, Claude Code, Cursor y VS Code. También necesitas MCPB en tu computadora.
En la misma categoría: Agent-Native Calendar, Excel MCP Server, MCP Server for Excel
Servidores de la misma categoría hechos por otros creadores, ordenados por estrellas.
Cómo leer una tarjeta:★ Estrellas de GitHubiTres pilares: reseñas · revisiones · usoiActualizado = fecha en que se publicó la última versión en el registroi
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.
Copiado tal cual del repo del creador. PopNx MCP no lo ha revisado ni lo respalda. Se quitaron HTML, imágenes y scripts. Los enlaces llevan fuera de este sitio.
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
Solo se muestra el principio; lee el resto en el repo