Which integrations are available for this server?

Provides task management with full Obsidian compatibility, including markdown files, YAML frontmatter, wiki links, Dataview queries, and graph view integration.

How do I use telos-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@telos-mcp create a task to add rate limiting to the API" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

telos-mcp

by Skye-flyhigh

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

telos-mcp

Task planning and tracking for AI agents. An MCP server with project-based organization and Obsidian-compatible markdown storage.

What it does

Gives any MCP-compatible AI agent persistent task management:

Create, update, list, delete tasks with full status tracking
Projects — organize tasks by project with metadata (tech stack, repo URL, sources)
Dependencies — blockedBy/blocks relationships between tasks
Bulk operations — create multiple tasks at once
Task tree — hierarchical view of tasks with parent-child relationships
Markdown files — each task is a folder with README.md and YAML frontmatter
Obsidian integration — full compatibility with Obsidian vaults, Dataview, and wiki links
Zero native addons — pure JavaScript, works on any Node version without rebuild
Multi-agent — owner tracking so you know who's doing what

Related MCP server: Plate MCP

Quick start

npx telos-mcp

Stable install

npm install -g telos-mcp

Or from source:

git clone https://github.com/skye-flyhigh/telos-mcp.git
cd telos-mcp && npm install && npm run build

Then point your client to "command": "node", "args": ["/path/to/telos-mcp/dist/index.js"].

Configuration

Variable	Default	Description
`TELOS_DIR`	`~/.telos`	Directory where task files are stored

Set TELOS_DIR to override the default storage location:

TELOS_DIR=/custom/path npx telos-mcp

Or in the MCP config:

{
  "mcpServers": {
    "telos": {
      "command": "npx",
      "args": ["telos-mcp"],
      "env": { "TELOS_DIR": "/custom/path" }
    }
  }
}

Client Setup

Claude Code

Add to .claude.json:

{
  "mcpServers": {
    "telos": {
      "type": "stdio",
      "command": "npx",
      "args": ["telos-mcp"],
      "env": {}
    }
  }
}

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "telos": {
      "command": "npx",
      "args": ["telos-mcp"]
    }
  }
}

Tools

Task Management

Tool	Description
`task_create`	Create a new task with subject, description, tags, dependencies, project_id
`task_update`	Update status, dependencies, project, or details of an existing task
`task_get`	Get full details of a task by ID
`task_list`	List all tasks (summary view), with optional filters
`task_delete`	Delete a task by ID (removes the folder)
`task_move`	Move a task to a different project (or to global tasks)
`task_create_bulk`	Create multiple tasks at once
`task_tree`	Get task hierarchy tree with all descendants

Project Management

Tool	Description
`telos_project_create`	Create a new project for organizing tasks
`telos_project_get`	Get full project information by key
`telos_project_list`	List all projects with optional filtering
`telos_project_update`	Update project metadata
`telos_project_archive`	Archive a project (moves to archive/year/)

Status Workflow

pending → planning → in_progress → reviewing → completed
   ↓          ↓           ↓            ↓
blocked   archived    deleted

Use status: "deleted" in task_update to remove a task (same as task_delete). Use status: "archived" to preserve task history without active tracking.

Dependencies

Tasks can block each other:

blockedBy: [1, 3] — this task can't start until tasks 1 and 3 complete
When a task is completed, it's automatically removed from dependents' blockedBy
When a task is deleted, all dependency references are cleaned up

Storage Format

Directory Structure

~/.telos/
├── tasks/                          # Global tasks (no project)
│   └── {id}-{slug}/
│       └── README.md
├── projects/
│   └── {key}/                      # e.g., "mnemo", "black-cat"
│       ├── project.md            # Project metadata
│       └── tasks/
│           └── {id}-{slug}/
│               └── README.md
└── archive/
    └── {year}/
        └── {key}/                  # Archived projects preserved
            ├── project.md
            └── tasks/

Task Format

Each task is a folder with a README.md containing YAML frontmatter:

---
id: 1
project_id: mnemo
subject: Fix authentication bug
status: in_progress
created: 2026-03-06T10:00:00.000Z
updated: 2026-03-06T12:30:00.000Z
owner: claude
activeForm: Fixing authentication bug
blockedBy: [3]
blocks: [5, 7]
tags: [backend, auth]
depth: 0
sources:
  - https://docs.example.com
  - https://github.com/org/repo/issues/42
---

Detailed description with full markdown support.

Project Format

Each project is a project.md file with YAML frontmatter and markdown body:

---
key: mnemo
display_name: Mnemo MCP
tech_stack: [typescript, mcp]
repo_url: "https://github.com/skye-flyhigh/mnemo"
status: active
created: "2026-03-06T10:00:00.000Z"
updated: "2026-03-06T12:00:00.000Z"
archived_at: null
archived_reason: null
sources:
  - https://modelcontextprotocol.io
---

Memory management for AI agents. Description goes here as markdown body.

Obsidian Integration

Telos is designed for Obsidian compatibility:

Markdown files — Every task is a README.md, every project is a project.md
YAML frontmatter — Metadata in standard YAML format
Wiki links — [[project-key]] links between tasks and projects
Dataview queries — Dynamic tables for task and project lists
Graph view — Visual task ↔ project relationships

Open ~/.telos as an Obsidian vault for full visualization.

License

MIT

Available Tools

13 tools

project_archiveA

Archive a project (moves to archive/year/)

ParametersJSON Schema

Name	Required	Description
`key`	Yes	Project key to archive
`force`	No	Skip safety warnings
`reason`	No	Why this project is being archived

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes the move to 'archive/year/', which provides some behavioral context, but with no annotations, it fails to disclose potential side effects (e.g., reversibility, permission requirements) or the full impact of the operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise and front-loaded: two clear clauses with no wasted words. Every part of the description adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite low complexity (3 params, no output schema), the description is minimal. It explains the core action but omits details like the effect on related entities or the role of the 'force' parameter, leaving gaps in completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description adds no additional meaning to the parameters beyond what is already in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the action 'Archive a project' and specifies the effect 'moves to archive/year/', distinguishing it from siblings like project_create, project_update, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives (e.g., project_delete or task tools). Usage is implied but lacks context like prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

project_createC

Create a new project for organizing tasks

ParametersJSON Schema

Name	Required	Description
`key`	Yes	Unique project identifier
`clone`	No	If true, clone repo_url to base_path
`sources`	No	Initial references, documentation, or research sources for the project
`repo_url`	No	Git repository URL
`base_path`	No	Absolute path to project source code
`tech_stack`	No	Technologies used
`description`	No	Optional project description explaining the context of the project
`display_name`	Yes	Human-readable project name

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It only states 'create,' implying mutation, but lacks details on side effects, required permissions, or whether the operation is reversible. No mention of what happens with parameters like clone or repo_url.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words. It is front-loaded with the core action. While short, it is not incomplete enough to lower the score significantly for a simple creation tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description should explain return behavior (e.g., returns the created project or a success indicator). It also fails to summarize the overall workflow, such as how clone, repo_url, and base_path interact. The tool's complexity (8 params) demands more context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides descriptions for all 8 parameters (100% coverage), so the schema already documents them. The description adds no extra meaning beyond the schema; baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('create') and the resource ('project') with a brief context ('for organizing tasks'). It is distinct from sibling tools like project_archive or project_update, though it could be more specific about the project's purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. For example, there is no mention of when to use project_create instead of task_create or project_update. The agent must infer from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

project_getB

Get project information by key

ParametersJSON Schema

Name	Required	Description	Default
`key`	Yes	Project key to retrieve

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It only states 'Get project information' without disclosing any behavioral traits (e.g., read-only nature, error handling, rate limits). This is insufficient for a tool with no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no wasted words. It front-loads the purpose and is appropriately concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description is minimally adequate. However, it does not explain what 'project information' includes or how to handle missing keys, leaving some gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents the 'key' parameter well. The description adds no additional meaning beyond the schema's parameter description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the verb 'Get' and identifies the resource as 'project information' with the method 'by key'. While it distinguishes from siblings like project_list (which likely does not require a key), it does not explicitly state how it differs from project_list or other siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context (use when you have a project key), but it does not provide explicit guidance on when to use this tool versus alternatives such as project_list or project_get vs task_get.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

project_listC

List all projects with optional filtering

ParametersJSON Schema

Name	Required	Description
`sort`	No	Sort field
`limit`	No	Max results (default 100)
`offset`	No	Pagination offset
`search`	No	Search in key, name, or description
`status`	No	Filter by status
`tech_stack`	No	Filter by technologies (match ANY)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries full burden. It only mentions 'optional filtering' but fails to disclose pagination, default sorting, or behavior when filters match nothing. The schema provides parameter details, but the description adds no behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, front-loaded with the main action. However, it is too brief given the tool's complexity (6 parameters, no output schema). It earns its place but could include more detail without sacrificing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks sufficient context for an AI agent. With no output schema, 6 parameters, and no annotations, the description should explain return format, pagination, and filter behavior. It only provides a minimal overview.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the description adds no extra meaning beyond schema. The description does not elaborate on any parameter semantics; it simply references 'optional filtering' generically.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('List') and resource ('projects'), and mentions optional filtering. It distinguishes from sibling tools like project_get (single project) and task_list (tasks). However, it does not explicitly differentiate from project_get or other list tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives like project_get for a single project, nor does it specify prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

project_updateD

Update project

ParametersJSON Schema

Name	Required	Description
`key`	Yes	Project key to update
`sources`	No	Initial references, documentation, or research sources for the project
`repo_url`	No	Git repository URL
`base_path`	No	Absolute path to project source code
`tech_stack`	No	Technologies used
`description`	No	Optional project description explaining the context of the project
`display_name`	Yes	Human-readable project name

TDQS

D1.9/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of disclosing behavior. It fails to mention any behavioral traits such as whether the update is destructive, requires specific permissions, or what side effects may occur.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short (two words) but lacks necessary detail. It is under-specified rather than concise, failing to provide any value beyond the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 7 parameters, no output schema, no annotations, and sibling tools with overlapping purposes, the description is grossly inadequate. It provides no context about the tool's functionality, behavior, or usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides descriptions for all 7 parameters (100% coverage). The description adds no additional meaning beyond what the schema already conveys, 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.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Update project' is a tautology that merely restates the tool name 'project_update'. It does not specify what aspects of a project can be updated or differentiate from sibling tools like project_archive or project_create.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. There is no indication of prerequisites, context, or scenarios where this tool is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

task_createC

Create a new task for tracking work

ParametersJSON Schema

Name	Required	Description
`tags`	No	Task tags
`owner`	No	Who owns this task
`sources`	No	URLs, references, documentation used for this task (e.g. ['https://docs.example.com', 'Claude Code Plan Mode analysis'])
`subject`	Yes	Brief imperative title (e.g. 'Fix auth bug')
`metadata`	No	Arbitrary key-value pairs (e.g. { pr: '#42', priority: 'high' })
`blockedBy`	No	Task IDs that must complete first
`parent_id`	No	Parent ID, task parent ID whom task is related to
`project_id`	No	Project key this task belongs to
`description`	No	Detailed markdown description. When planning, document yourself regarding the task (e.g. search information online (use web_search tool if allowed), consult the codebase or ask further questions before delivering a plan). Preparing a plan can take several task update cycles until all the information is gathered. Structured description, details points when applicable: - Context: explain the why, and overall view how to solve the problem - Task details - Task location: where the task takes place (filepath or physical location, etc.) - Architecture: final structure of the expected output - Dependencies: explain what are required for delivery - Examples of the deliverable and expectations - Reasoning for the offered solution - Foreseen barriers and solution (from task context) - Implementation steps: real, commitable implementation steps, questions to ask the user for clarification and decision - Testing plan - Deployment plan - Sources and reference: explicitely list the sources used to design the plan, or say no sources have been used.

TDQS

C2.7/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It only says 'Create a new task for tracking work' without mentioning side effects, authentication requirements, idempotency, or what happens on duplicate subjects. This is severely insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence, which is too minimal. It does not earn its space by providing additional useful information; it merely restates the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 9 parameters (including nested objects) and no output schema or annotations, the description should cover return values, error cases, and relationships to other tools. It does none of these, leaving the agent underinformed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with detailed per-parameter descriptions. The tool description adds nothing beyond the generic purpose, but since the schema already documents parameters well, a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create') and the resource ('a new task'), and the sibling tools like task_list, task_update, task_delete, and task_create_bulk are distinct in purpose, so no confusion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool vs alternatives like task_create_bulk for bulk creation, or task_update for modification. No exclusions or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

task_create_bulkC

Create multiple tasks at once

ParametersJSON Schema

Name	Required	Description	Default
`tasks`	Yes	Array of task definitions
`project_id`	No	Project key for all tasks (optional)

TDQS

C2.6/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose any behavioral traits such as atomicity, partial failures, idempotency, or rate limits. For a bulk creation tool, this is a critical omission.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, vague sentence that lacks structure and detail. While concise, it does not earn its place by providing needed additional context for a bulk operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of the input array and no output schema, the description is severely lacking. It does not explain return values, error handling, or behavior when some tasks fail, making it inadequate for effective tool use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema documents all parameters. The description adds minimal value beyond the schema, providing only a high-level purpose. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create multiple tasks at once' clearly states the verb ('Create') and resource ('multiple tasks'), and distinguishes itself from the sibling tool 'task_create' which likely creates a single task.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives (e.g., repeating task_create). There is no mention of batch size limits, prerequisites, or when bulk creation is beneficial vs. detrimental.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

task_deleteA

Delete a task by ID (removes the folder)

ParametersJSON Schema

Name	Required	Description	Default
`taskId`	Yes	The task ID to delete

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It reveals the side effect of removing a folder, which is useful. However, it fails to disclose whether the deletion is permanent, reversible, or has cascading effects, leaving some behavioral uncertainty.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that conveys the core action and a key side effect with zero waste. It is highly efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter delete tool, the description is adequate but not complete. It omits details like permanence, error conditions, or return value (though no output schema exists). Given the absence of annotations, it could be more thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with a description for the sole parameter. The tool description adds no extra meaning beyond what the schema provides, meeting the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Delete') and the resource ('a task by ID'), and the parenthetical 'removes the folder' provides further specificity. This effectively distinguishes it from sibling tools like task_update or task_move.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description offers no guidance on when to use this tool versus alternatives (e.g., archiving) or any prerequisites. It only implies usage for deletion, leaving the agent without context for decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

task_getA

Get full details of a task by ID

ParametersJSON Schema

Name	Required	Description	Default
`taskId`	Yes	The task ID to retrieve

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It merely says 'Get full details' without disclosing behavioral traits such as whether the response includes nested fields, performance characteristics, or if it is idempotent. The description lacks depth for a single-task retrieval tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded with the core action. No unnecessary words or information, making it highly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is nearly complete. It states the input and purpose, but could specify what 'full details' entails (e.g., all fields) for better completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (taskId is described as 'The task ID to retrieve'). The description only echoes 'by ID', adding no additional meaning. With high schema coverage, the baseline is 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get', the resource 'full details of a task', and the method 'by ID'. It effectively distinguishes this tool from sibling tools like task_list (which likely returns multiple tasks) and task_update (which modifies).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when you need full details of a single task by ID, but it does not explicitly state when to use this tool versus alternatives like task_list or task_tree. No when-not or alternative guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

task_listA

List all tasks (summary view: id, subject, status, owner, blockedBy)

ParametersJSON Schema

Name	Required	Description
`owner`	No	Filter by owner
`status`	No	Filter by status
`project_id`	No	Filter by project

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Minimal disclosure: only mentions 'summary view'. No annotations provided, so description carries full burden; lacks details on pagination, sorting, result limits, or whether it includes archived/deleted tasks.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single, front-loaded sentence with no waste; purpose and output fields are immediately clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple filtering tool with 3 optional params and no output schema, but lacks details on pagination, ordering, or default behavior, which are important for list operations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides (filter by owner, status, project_id).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the verb 'List' and resource 'tasks', specifies the summary view fields (id, subject, status, owner, blockedBy), distinguishing from sibling tools like task_get (single task) or task_tree (hierarchical).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage for obtaining a summary list of tasks, but does not explicitly state when to use this over alternatives like task_tree or task_get, nor provide conditions for when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

task_moveC

Move a task to a different project (or to global tasks)

ParametersJSON Schema

Name	Required	Description	Default
`taskId`	Yes	The task ID to move
`project_id`	No	Target project key (null for global tasks)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It indicates the behavioral effect (task changes project) but omits side effects like whether subtasks or permissions are preserved, or if moving to global tasks removes project association.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One short, efficient sentence with no redundant words. Front-loaded and earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Description is brief for a move operation. With no output schema and no annotations, it lacks details on return values, success indicators, or constraints (e.g., required permissions, irreversible actions). Sibling tools like task_update have similar brevity, but more context would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% parameter coverage with clear descriptions. Description adds no extra parameter info but contextualizes the project_id as 'global tasks'. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description states the verb 'move' and the resource 'task', specifying destination as 'different project or global tasks'. This clearly distinguishes it from sibling tools like task_create, task_update, task_delete, but could be more detailed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives (e.g., task_update for other changes). The description implies usage when changing a task's project, but does not mention when not to use it or provide comparisons to siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

task_treeB

Get task hierarchy tree with all descendants

ParametersJSON Schema

Name	Required	Description	Default
`rootId`	No	Root task ID (if omitted, returns all root tasks)

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must provide behavioral details. It only states retrieval of a hierarchy but omits important aspects like output structure, potential depth, or performance implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words, but could benefit from additional context to aid the agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool returning a hierarchical tree with many descendants, the description lacks details about the output format, depth limit, or examples. Given no output schema, more context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds no extra meaning beyond what is already in the schema for the single parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and resource ('task hierarchy tree with all descendants'), effectively distinguishing it from sibling tools like task_list or task_get.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as task_list or task_get. There is no mention of prerequisites or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

task_updateB

Update an existing task's status, dependencies, or details

ParametersJSON Schema

Name	Required	Description
`tags`	No	Task tags
`owner`	No	Who owns this task
`status`	No	New status (deleted removes the task)
`taskId`	Yes	The task ID to update
`sources`	No	URLs, references, documentation used for this task (e.g. ['https://docs.example.com', 'Claude Code Plan Mode analysis'])
`subject`	No	Brief imperative title (e.g. 'Fix auth bug')
`metadata`	No	Merge metadata keys into the task. Set a key to null to delete it.
`addBlocks`	No	Task IDs that this task blocks
`parent_id`	No	Parent ID, task parent ID whom task is related to
`project_id`	No	Project key this task belongs to
`description`	No	Detailed markdown description. When planning, document yourself regarding the task (e.g. search information online (use web_search tool if allowed), consult the codebase or ask further questions before delivering a plan). Preparing a plan can take several task update cycles until all the information is gathered. Structured description, details points when applicable: - Context: explain the why, and overall view how to solve the problem - Task details - Task location: where the task takes place (filepath or physical location, etc.) - Architecture: final structure of the expected output - Dependencies: explain what are required for delivery - Examples of the deliverable and expectations - Reasoning for the offered solution - Foreseen barriers and solution (from task context) - Implementation steps: real, commitable implementation steps, questions to ask the user for clarification and decision - Testing plan - Deployment plan - Sources and reference: explicitely list the sources used to design the plan, or say no sources have been used.
`addBlockedBy`	No	Task IDs to add as blockers

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility for disclosing behavior. It only mentions the update capability without noting any side effects, permissions, or rate limits. The schema's note about 'deleted' status is not repeated in the description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that is concise and free of unnecessary words. It efficiently communicates the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (12 parameters, one required, no output schema), the description is too brief. It does not explain what the tool returns or how it behaves under various conditions, leaving significant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema; it merely lists 'status, dependencies, or details' which is already evident from the parameter names and descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Update' and clearly states the resource 'existing task' along with the aspects that can be updated ('status, dependencies, or details'), making it distinct from sibling tools like task_create or task_delete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, when not to use it, or any prerequisites. The description only states what it does, not when to apply it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

13 tool updatesv0.2.0Jun 28, 2026
- First observedproject_archive
- First observedproject_create
- First observedproject_get
- First observedproject_list
- First observedproject_update
- First observedtask_create
- First observedtask_create_bulk
- First observedtask_delete
- First observedtask_get
- First observedtask_list
- First observedtask_move
- First observedtask_tree
- First observedtask_update

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.2/5.0

Scored 2026-06-28 02:25 across 13 tools

Disambiguation5/5

Each tool targets a distinct action on either projects or tasks, with no overlapping purposes. For example, project_create and task_create are clearly differentiated by resource type.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: project_<verb> and task_<verb>, making it easy to predict functionality from the name.

Tool Count4/5

With 13 tools, the count is appropriate for a project and task management domain. It covers core operations without being overwhelming, though slightly on the higher side.

Completeness4/5

The set covers CRUD for tasks fully (create, get, list, update, delete) and for projects (create, get, list, update, archive). Missing an explicit project delete, but archive serves as a soft delete. A project tree might be useful but is not essential.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

MasaroOAuth
ai.masaro
Task management for teams building with AI agents. Agents claim tasks and report progress.
Project Management Agent Orchestration
2
DartOAuth
com.dartai
AI-native project management for tasks, docs, collaboration, and agents.
Project Management Workplace & Productivity
1
Plate AOAuth
to.plate
Minimal project management for teams and AI agents.
Project Management App Automation
282
GetItDoneOAuth
com.nowgetitdone
AI-native task management: list, create, update and archive tasks with rich context for AI agents
Project Management Autonomous Agents
1

Related MCP Servers

Tasks.md MCP Server
Project Management Developer Tools File Systems
context-you-keep
F
license
Not graded
quality
Not graded
maintenance
Enables AI-native task management using plain markdown files to create, update, query, and organize Epics, Stories, Tasks, and Milestones without requiring a database.
Updated 10 months ago (2025-11-19 04:44 UTC)
-
Plate MCPofficial
Project Management App Automation Autonomous Agents
plate-to
F
license
Not graded
quality
B
maintenance
Lightweight project management for teams and AI agents.
Updated 2 months ago (2026-07-30 14:04 UTC)
-
roadmap-skill
Project Management Knowledge & Memory
shiquda
A
license
B
quality
F
maintenance
Enables AI agents and humans to collaboratively plan and manage tasks with a shared kanban and dependency graph, all stored locally.
Updated 6 months ago (2026-03-18 12:07 UTC)
31
41 npm
79
MIT
hubd
Communication Knowledge & Memory Project Management
bzdOS
A
license
B
quality
A
maintenance
A project tracker for teams of humans and AI agents that coordinates work through plain files (markdown and JSONL), providing an MCP server for agents and a CLI for humans.
Updated a day ago (2026-09-14 17:42 UTC)
39
1,552 npm
2
MIT

telos-mcp

What it does

Quick start

Stable install

Configuration

Client Setup

Claude Code

Claude Desktop

Tools

Task Management

Project Management

Status Workflow

Dependencies

Storage Format

Directory Structure

Task Format

Project Format

Obsidian Integration

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Plate MCPofficial