Skip to main content
Glama
tejpalvirk

Project MCP Server

by tejpalvirk

プロジェクトMCPサーバー

プロジェクトナレッジグラフを管理するためのツールを提供するMCPサーバー実装。プロジェクト、タスク、マイルストーン、リソース、チームメンバーを構造的に表現できます。このサーバーは、プロジェクトマネージャーが進捗状況を追跡し、リスクを管理し、リソースを割り当て、情報に基づいた意思決定を行うのに役立ちます。

特徴

  • 永続的なプロジェクトコンテキスト: 複数のセッションにわたってプロジェクトエンティティと関係の構造化された知識グラフを維持します。

  • セッション管理: 固有のIDを使用してプロジェクト管理セッションを追跡し、時間の経過に伴う進捗を記録します。

  • プロジェクトステータスの追跡: プロジェクトの健全性、リスク、問題のステータスをリアルタイムで監視します

  • タスクの依存関係: タスク間の依存関係を視覚化して管理し、ボトルネックを特定します。

  • マイルストーンの進捗: 主要なプロジェクトマイルストーンの進捗を追跡します

  • リソース割り当て: プロジェクトやタスク間でリソースがどのように配分されているかを監視します

  • リスク評価: プロジェクトのリスクを特定、監視、軽減する

  • 意思決定ログ: プロジェクトの重要な決定とその背景を記録する

  • チームメンバー管理: チームメンバーの割り当てと作業負荷を追跡します

  • プロジェクトタイムライン分析: クリティカルパスを含むプロジェクトタイムラインを分析

Related MCP server: Student MCP Server

エンティティ

Project MCP サーバーは次のエンティティ タイプを認識します。

  • プロジェクト: 関連するすべてのエンティティのメインコンテナ

  • タスク: 完了する必要がある個々の作業項目

  • マイルストーン: プロジェクトにおける主要なチェックポイントまたは成果物

  • リソース: プロジェクトに必要な材料、ツール、または資産

  • チームメンバー: プロジェクトに関わる人々

  • 注記: 文書、アイデア、または観察

  • 文書:正式なプロジェクト文書

  • 問題: 問題または障害

  • リスク: 将来起こりうる問題

  • 決定: プロジェクト中に行われた重要な選択

  • 依存性: 外部要件または前提条件

  • コンポーネント: プロジェクトの一部またはモジュール

  • ステークホルダー:プロジェクトの影響を受ける人、またはプロジェクトに関心のある人

  • 変更: プロジェクトの範囲または要件の変更

  • ステータス: エンティティのステータス値 (非アクティブ、アクティブ、完了)

  • 優先度: 優先度の値(高、低)

人間関係

エンティティは、次の関係タイプを通じて接続できます。

  • part_of : エンティティが別のエンティティのコンポーネント/サブセットであることを示します

  • depends_on : エンティティ間の依存関係を表示します

  • assignment_to : タスクをチームメンバーにリンクする

  • created_by : エンティティを作成した人を追跡します

  • changed_by : エンティティを変更した人の記録

  • related_to : エンティティ間の一般的な接続を表示します

  • ブロック: あるエンティティが別のエンティティをブロックしていることを示します

  • 管理: 管理関係を表示します

  • contributes_to : エンティティへの貢献を表示します

  • ドキュメント: ドキュメントをエンティティにリンクします

  • scheduled_for : エンティティを日付または期間に接続します

  • 責任者: 所有権/責任を割り当てる

  • reports_to : 報告関係を示す

  • categorized_as : エンティティをカテゴリまたはタイプにリンクします

  • required_for : 完了に必要な要件を表示します

  • discover_in : 問題を検出コンテキストにリンクします

  • 解決済み: 問題を解決した内容を表示します

  • influenced_by : 影響関係を表示する

  • stakeholder_of : ステークホルダーをプロジェクト/コンポーネントにリンクします

  • prioritized_as : 優先度レベルを示す

  • has_status : エンティティを現在のステータス(非アクティブ、アクティブ、完了)にリンクします。

  • has_priority : エンティティを優先度レベル(高、低)にリンクします。

  • 先行: あるタスクが他のタスクよりも先に実行されることを示します

利用可能なツール

Project MCP サーバーは、プロジェクト ナレッジと対話するための次のツールを提供します。

開始セッション

新しいプロジェクト管理セッションを開始し、一意のセッションIDを生成して、現在のプロジェクト、タスク、マイルストーン、リスク、最近のセッションを表示します。has_status リレーションを介してステータス情報、has_priority リレーションを介して優先度レベルを表示し、順序依存関係に基づいて次に作業する準備が整ったタスクを特定します。

ロードコンテキスト

特定のエンティティ(プロジェクト、タスクなど)の詳細なコンテキストを読み込み、エンティティの種類に基づいて関連情報を表示します。ステータス情報(非アクティブ、アクティブ、完了)、優先度(高、低)、およびタスク間の関係が含まれます。

終了セッション

構造化された多段階のプロセスを通じてプロジェクト管理セッションの結果を記録します。

  1. 概要: セッションの概要、期間、プロジェクトの焦点を記録します

  2. 成果: セッションの主要な成果を文書化する

  3. taskUpdates : 既存のタスクの更新を追跡します

  4. newTasks : セッション中に作成された新しいタスクを記録します

  5. statusUpdates : エンティティのステータス値の変更を記録します

  6. projectStatus : プロジェクト全体のステータス、優先度の割り当て、および順序関係を更新します

  7. アセンブリ: すべてのセッションデータの最終アセンブリ

ビルドコンテキスト

ナレッジ グラフに新しいエンティティ、リレーション、または観察を作成します。

  • エンティティ: 新しいプロジェクト関連のエンティティ (プロジェクト、タスク、マイルストーン、ステータス、優先度など) を追加します。

  • リレーション:エンティティ間の関係を作成する(has_status、has_priority、precedesを含む)

  • 観察: 既存のエンティティに観察を追加する

削除コンテキスト

ナレッジ グラフからエンティティ、リレーション、または観察を削除します。

  • エンティティ: プロジェクトエンティティを削除する

  • 関係: エンティティ間の関係(ステータス、優先度、順序関係を含む)を削除します。

  • 観測: エンティティから特定の観測を削除する

高度なコンテキスト

ナレッジ グラフから情報を取得します。

  • グラフ: ナレッジグラフ全体を取得する

  • 検索: クエリ条件に基づいてノードを検索する

  • nodes : 名前で特定のノードを取得する

  • 関連: 関連するエンティティを検索する

  • ステータス: 特定のステータス値 (非アクティブ、アクティブ、完了) を持つエンティティを検索します。

  • 優先度: 特定の優先度値(高、低)を持つエンティティを検索します

  • シーケンス: タスクの順序関係を識別する

ドメイン固有の機能

Project MCP サーバーには、プロジェクト管理用の特殊なドメイン機能が含まれています。

  • getProjectOverview : タスク、マイルストーン、チーム メンバー、問題などを含むプロジェクトの包括的なビュー。

  • getTaskDependencies : タスクの依存関係を分析して、ブロックされたタスクとクリティカルパスを特定します

  • getTeamMemberAssignments : 特定のチームメンバーのすべての割り当てを表示する

  • getMilestoneProgress : プロジェクトのマイルストーンの進捗状況を追跡する

  • getProjectTimeline : プロジェクトのタイムラインと重要な日付を分析する

  • getResourceAllocation : プロジェクト全体でリソースがどのように割り当てられているかを調べる

  • getProjectRisks : プロジェクトリスクの特定と評価

  • findRelatedProjects : 異なるプロジェクト間のつながりを発見する

  • getDecisionLog : 意思決定の履歴とコンテキストを追跡する

  • getProjectHealth : 指標と推奨事項を使用してプロジェクト全体の健全性を評価する

  • getStatusOverview : 特定のステータス(非アクティブ、アクティブ、完了)のすべてのエンティティを表示します。

  • getPriorityItems : 優先度の高いタスクとアクティビティを特定する

  • getTaskSequence : 先行関係に基づいてタスクの順序を視覚化する

プロンプトの例

セッションの開始

Let's start a new project management session to review the Mobile App Development project.

プロジェクトコンテキストの読み込み

Load the context for the Mobile App Development project so I can see its current status.

レコーディングセッションの結果

I've just finished a project review meeting for Mobile App Development. We completed the UI design milestone, identified 2 new risks related to the backend API, and assigned 3 new tasks to the development team. The UI tasks are now marked as complete, and we've set the API development tasks as high priority. The project is still on track but we need to monitor the API risks closely.

プロジェクト知識の管理

Create a new task called "Implement User Authentication" that's part of the Mobile App Development project, assigned to Sarah, with high priority and due in two weeks. Set its status to active and make it precede the "User Profile" task.
Update the status of the "Database Migration" task to "completed" and add an observation that it was finished ahead of schedule.

使用法

この MCP サーバーにより、プロジェクト マネージャーは次のことが可能になります。

  • コンテキストの継続性を維持: 複数の計画セッションにわたってプロジェクトの詳細を追跡します

  • 新しいチームメンバーのオンボード: 新しいチームメンバーにプロジェクトの状況を迅速に把握してもらう

  • セッション結果の記録: 会議や作業セッションの結果を文書化します

  • 依存関係の追跡: 重要な依存関係とボトルネックを特定して管理します

  • リスクの監視: プロジェクトのリスクを追跡し、軽減戦略を実施する

  • リソースの割り当て: プロジェクトとタスク間でのリソースの割り当てを最適化します

  • 情報に基づいた意思決定:包括的なプロジェクトデータに基づいて意思決定を行う

  • 進捗状況の追跡: プロジェクトのライフサイクル全体を通じてエンティティのステータスを監視します

  • 仕事の優先順位付け: 優先度の高いタスクを特定して集中する

  • タスクの順序付け: プロジェクトタスクの論理的な順序を計画し、視覚化します

構成

Claude Desktopでの使用

これをclaude_desktop_config.jsonに追加します:

GitHubからインストールしてnpxで実行する

{
  "mcpServers": {
    "project": {
      "command": "npx",
      "args": [
        "-y",
        "github:tejpalvirk/project"
      ]
    }
  }
}

グローバルにインストールして直接実行

まず、パッケージをグローバルにインストールします。

npm install -g github:tejpalvirk/project

次に、Claude Desktop を構成します。

{
  "mcpServers": {
    "project": {
      "command": "contextmanager-project"
    }
  }
}

ドッカー

{
  "mcpServers": {
    "project": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "mcp/project"
      ]
    }
  }
}

建物

ソースから

# Clone the repository
git clone https://github.com/tejpalvirk/contextmanager.git
cd contextmanager

# Install dependencies
npm install

# Build the server
npm run build

# Run the server
cd project
node project_index.js

ドッカー:

docker build -t mcp/project -f project/Dockerfile .

ライセンス

このMCPサーバーはMITライセンスに基づいてライセンスされています。つまり、MITライセンスの条件に従って、ソフトウェアを自由に使用、改変、配布することができます。詳細については、プロジェクトリポジトリのLICENSEファイルをご覧ください。

環境変数

Project MCP サーバーは、データの保存場所をカスタマイズするために次の環境変数をサポートしています。

  • MEMORY_FILE_PATH : ナレッジグラフデータが保存されるパス

    • 絶対パスまたは相対パスを指定できます(相対パスは現在の作業ディレクトリを使用します)

    • デフォルト: ./project/memory.json

  • SESSIONS_FILE_PATH : セッションデータが保存されるパス

    • 絶対パスまたは相対パスを指定できます(相対パスは現在の作業ディレクトリを使用します)

    • デフォルト: ./project/sessions.json

使用例:

# Store data in the current directory
MEMORY_FILE_PATH="./pm-memory.json" SESSIONS_FILE_PATH="./pm-sessions.json" npx github:tejpalvirk/contextmanager-project

# Store data in a specific location (absolute path)
MEMORY_FILE_PATH="/path/to/data/project-memory.json" npx github:tejpalvirk/contextmanager-project

# Store data in user's home directory
MEMORY_FILE_PATH="$HOME/contextmanager/project-memory.json" npx github:tejpalvirk/contextmanager-project

Available Tools

6 tools
advancedcontextA

A sophisticated query tool for exploring, analyzing, and retrieving complex information from the project management knowledge graph.

When to use this tool:

  • Retrieving a comprehensive view of your entire project management structure

  • Searching for specific project entities across your initiatives

  • Getting detailed information about particular projects or project elements

  • Exploring task dependencies and their critical paths

  • Analyzing team member assignments and workload

  • Tracking milestone progress and completion status

  • Examining project timelines and schedules

  • Assessing resource allocation across projects

  • Identifying and monitoring project risks

  • Finding connections between related projects

  • Reviewing decision logs and project governance

  • Evaluating overall project health and status

  • Filtering entities by status values (inactive, active, complete)

  • Finding high-priority tasks and activities

  • Analyzing sequential relationships between tasks

Key features:

  • Offers specialized operations for querying different aspects of project management data

  • Retrieves complete or filtered views of the project knowledge graph

  • Provides flexible search capabilities across all project entities

  • Supports detailed exploration of specific entities by name

  • Generates comprehensive project overviews with related elements

  • Maps task dependencies to identify critical paths

  • Tracks team member assignments and responsibilities

  • Monitors milestone progress with completion metrics

  • Creates project timelines with key dates and dependencies

  • Manages resource allocation across project activities

  • Identifies and prioritizes project risks

  • Finds relationships between projects for portfolio management

  • Records and retrieves decision logs for governance

  • Assesses project health with key performance indicators

  • Filters entities by status via has_status relations

  • Identifies high-priority items via has_priority relations

  • Analyzes task sequencing through precedes relations

Parameters explained:

  1. type: The type of query operation to perform

  • Accepts one of the specialized operations: "graph", "search", "nodes", "project", "dependencies", "assignments", "milestones", "timeline", "resources", "risks", "related", "decisions", "health", "status", "priority", "sequence"

  • Determines how the params parameter is interpreted

  1. params: Operation-specific parameters (structure varies by type):

  • For "graph": No parameters needed (retrieves the full project knowledge graph)

  • For "search": Object containing:

    • query: Search string to find entities (supports entity type filters)

  • For "nodes": Object containing:

    • names: Array of entity names to retrieve

  • For "project": Object containing:

    • projectName: Name of the project to retrieve details for

  • For "dependencies": Object containing:

    • taskName: Name of the task to analyze dependencies for

    • depth: (Optional) How many levels of dependencies to retrieve (default: 2)

  • For "assignments": Object containing:

    • teamMemberName: Name of the team member to retrieve assignments for

  • For "milestones": Object containing:

    • projectName: Project name to retrieve milestones for

    • milestoneName: (Optional) Specific milestone to retrieve details for

  • For "timeline": Object containing:

    • projectName: Project name to generate timeline for

  • For "resources": Object containing:

    • projectName: Project name to analyze resource allocation for

    • resourceName: (Optional) Specific resource to analyze allocation for

  • For "risks": Object containing:

    • projectName: Project name to retrieve risks for

  • For "related": Object containing:

    • projectName: Project name to find related projects for

    • depth: (Optional) Depth of project relationships to explore (default: 1)

  • For "decisions": Object containing:

    • projectName: Project name to retrieve decision log for

  • For "health": Object containing:

    • projectName: Project name to assess health for

  • For "status": Object containing:

    • statusValue: The status value to filter by (e.g., "inactive", "active", "complete")

  • For "priority": Object containing:

    • priorityValue: The priority value to filter by (e.g., "high", "low")

  • For "sequence": Object containing:

    • taskName: Name of the task to analyze sequential relationships for

Operation details:

  • graph: Returns the complete project knowledge graph with all entities and relationships

  • search: Performs text-based search across entity names and observations

  • nodes: Retrieves detailed information about specific entities by name

  • project: Returns comprehensive project information including tasks, milestones, and team members

  • dependencies: Maps task dependencies to identify critical paths and bottlenecks

  • assignments: Lists all assignments for a specific team member with workload information

  • milestones: Tracks milestone progress with completion status and metrics

  • timeline: Generates a project timeline with key dates, dependencies, and current status

  • resources: Analyzes resource allocation across project activities

  • risks: Identifies and prioritizes project risks with mitigation strategies

  • related: Finds connections between projects for portfolio management

  • decisions: Retrieves decision log for project governance and audit

  • health: Assesses project health with key performance indicators and metrics

  • status: Retrieves all entities with a specific status value (inactive, active, complete)

  • priority: Retrieves all entities with a specific priority value (high, low)

  • sequence: Identifies sequential relationships for tasks, showing preceding and following tasks

Status and Priority Information:

  • Status queries return entities organized by their current state in the project lifecycle

  • Priority queries help identify critical project tasks and elements

  • Status values include: inactive, active, complete

  • Priority values include: high, low

  • Status and priority are assigned through has_status and has_priority relations

Sequential Task Information:

  • Sequence queries identify tasks that come before or after in a project workflow

  • Sequential relationships help visualize the project workflow and dependencies

  • The sequence operation shows both incoming and outgoing precedes relations

  • Task sequences are critical for project planning and critical path identification

Return information:

  • success: Boolean indicating whether the operation succeeded

  • Additional fields depend on the operation type:

    • graph: Complete knowledge graph

    • results: For search operations

    • nodes: For specific entity retrieval

    • project/dependencies/assignments/etc.: For specialized views

    • status/priority: Lists of entities with specified status/priority values

    • sequence: Preceding and following tasks in project workflows

You should:

  • Start with broad queries ("graph", "search") to explore your project portfolio

  • Use specific entity queries ("nodes", "project") for detailed information

  • Map task dependencies to identify critical paths and bottlenecks

  • Track team member assignments to manage workload and availability

  • Monitor milestone progress to ensure project timeline adherence

  • Generate project timelines for planning and tracking purposes

  • Analyze resource allocation to optimize utilization

  • Identify and prioritize project risks for proactive management

  • Find relationships between projects for portfolio-level insights

  • Review decision logs for governance and accountability

  • Assess project health regularly with the health operation

  • Use status queries to filter entities by their current state

  • Use priority queries to focus on high-priority items

  • Use sequence queries to understand task workflows and dependencies

  • Combine multiple operations to build comprehensive project dashboards

ParametersJSON Schema
NameRequiredDescriptionDefault
paramsYesParameters for the get operation, structure varies by type
typeYesType of get operation

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden and does well by detailing behavioral traits: it explains the tool's query-focused nature, lists 16 specialized operations with their purposes, describes return structures ('success' field plus operation-specific outputs), and covers status/priority/sequence handling. It doesn't mention rate limits or auth needs, but provides substantial operational context.

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 excessively long (600+ words) with repetitive sections. While well-structured with headings, it repeats information across 'Key features', 'Operation details', and usage guidance. Many sentences don't earn their place (e.g., re-listing operation purposes multiple times). It's informative but not concise.

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

Completeness5/5

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

Given the tool's complexity (16 operation types, varied parameters) and no annotations or output schema, the description provides exceptional completeness. It covers purpose, extensive usage guidelines, detailed parameter semantics, behavioral context, return information, and operational strategies. For a sophisticated tool with rich functionality, this description leaves no significant gaps.

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

Parameters5/5

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

The description adds significant value beyond the 100% schema coverage. While the schema only defines 'type' (with enum) and 'params' as a generic object, the description extensively explains both parameters: it lists all 16 possible 'type' values (exceeding the schema's 13), provides detailed 'params' structures for each operation type (e.g., 'For "search": Object containing: query'), and includes default values and optional parameters not in the schema.

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 tool's purpose as 'exploring, analyzing, and retrieving complex information from the project management knowledge graph' with specific verbs and resource. However, it doesn't explicitly differentiate from sibling tools like 'buildcontext' or 'loadcontext' beyond its 'sophisticated query' focus, which prevents a perfect score.

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

Usage Guidelines5/5

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

The description provides extensive, explicit guidance with dedicated 'When to use this tool' and 'You should' sections, listing 15+ specific scenarios (e.g., 'Retrieving a comprehensive view', 'Searching for specific project entities') and operational strategies (e.g., 'Start with broad queries', 'Combine multiple operations'). This offers clear context for when to use this tool.

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

buildcontextA

A versatile tool for constructing and enhancing your project management knowledge graph by adding new project elements, relationships, and observations.

When to use this tool:

  • Creating new project entities (projects, tasks, milestones, team members, etc.)

  • Establishing relationships between project elements (e.g., connecting tasks to projects, assigning team members)

  • Adding observations, properties, or metadata to existing project entities

  • Building the project management structure incrementally as your project evolves

  • Organizing and structuring project data within your management framework

  • Documenting project status, risks, and decisions

  • Tracking project dependencies and assignments

  • Creating comprehensive project timelines with connected elements

  • Setting status values for project entities

  • Assigning priorities to tasks and other entities

  • Defining task sequencing and dependencies

Key features:

  • Creates three distinct types of knowledge graph elements: entities, relations, and observations

  • Supports various project management entity types (projects, tasks, milestones, team members, etc.)

  • Validates entity and relation types against predefined standards for the project domain

  • Handles batch creation of multiple entities or relations in a single operation

  • Returns confirmation with details of created elements

  • Ensures proper data typing and structure for the project management knowledge graph

  • Enables comprehensive documentation of project structure and progress

  • Supports status and priority assignment through entity-relation model

  • Enables sequential task relationships through precedes relation

Parameters explained:

  1. type: The type of creation operation to perform

  • Accepts: "entities", "relations", or "observations"

  • Determines how the data parameter is interpreted

  1. data: The content to add to the knowledge graph (structure varies by type):

  • For "entities": An array of objects, each containing:

    • name: Unique identifier for the entity

    • entityType: One of the valid entity types for project management

    • observations: Array of strings containing properties or metadata about the entity

    • embedding: (Optional) Vector embedding for enhanced semantic search

  • For "relations": An array of objects, each containing:

    • from: Name of the source entity

    • to: Name of the target entity

    • relationType: The type of relationship between entities (e.g., "depends_on", "assigned_to", "has_status")

    • observations: (Optional) Array of strings with metadata about the relationship

  • For "observations": Either a single object or an array of objects:

    • Single object format:

      • entityName: Name of the entity to add observations to

      • observations: Array of strings with new observations to add

    • Array format:

      • Each object containing:

        • entityName: Name of the entity to add observations to

        • contents: Array of strings with new observations to add

Valid entity types:

  • project: Overall project container

  • task: Individual action items or work packages

  • milestone: Key project checkpoints

  • teamMember: Project team participants

  • risk: Potential project threats or issues

  • decision: Documented project decisions

  • resource: Project assets or materials

  • issue: Problems requiring resolution

  • dependency: Inter-element relationships

  • meeting: Project-related gatherings

  • document: Project files and documentation

  • stakeholder: Parties with interest in the project

  • status: Entity status (inactive, active, complete)

  • priority: Entity priority (low, high)

Valid relation types:

  • part_of: Entity belongs to another entity

  • depends_on: Task dependency relationship

  • assigned_to: Assignment relationship between tasks and team members

  • responsible_for: Ownership of project elements

  • created_by: Authorship relationship

  • leads_to: Sequential relationship

  • blocks: Impediment relationship

  • reports_to: Organizational hierarchy

  • collaborates_with: Collaborative relationship

  • decides_on: Decision-making relationship

  • impacts: Effect relationship

  • has_status: Links entity to its status (inactive, active, complete)

  • has_priority: Links entity to its priority (low, high)

  • precedes: Task precedes another task (for sequencing)

Status Values:

  • inactive: Work on the entity has not begun or is paused

  • active: Work is actively underway

  • complete: Work has been finished

Priority Values:

  • low: Lower priority item

  • high: Higher priority item

Return information:

  • JSON response indicating success or failure

  • For successful operations:

    • Success flag set to true

    • Details of created elements in the "created" field (for entities/relations) or info message for observations

  • For failed operations:

    • Success flag set to false

    • Error message describing the issue

Error handling:

  • Returns descriptive error messages for invalid inputs

  • Gracefully handles type mismatches and formatting errors

  • Rejects operations with invalid types

You should:

  • Use consistent naming conventions for entities to facilitate relationships and retrieval

  • Begin by creating projects before more specific project elements

  • Add detailed observations to entities to enhance context and searchability

  • Create relationships to build a comprehensive network of interconnected project data

  • Document project status and progress through has_status relations

  • Assign priorities to tasks using has_priority relations

  • Use the precedes relation to establish task sequences and dependencies

  • Assign specific team members to tasks using relations

  • Track project risks with detailed observations

  • Document decisions with context and rationale

  • Update entity observations regularly to reflect current project information

  • Check the operation result to confirm successful creation

ParametersJSON Schema
NameRequiredDescriptionDefault
dataYesData for the creation operation, structure varies by type but must be an array
typeYesType of creation operation: 'entities', 'relations', or 'observations'

TDQS

A4.6/5.0
Behavior4/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 behavioral disclosure. It effectively describes key behaviors: it creates three types of elements (entities, relations, observations), validates against standards, handles batch creation, returns confirmation details, ensures data typing, and includes error handling with descriptive messages. It covers creation operations comprehensively but could mention rate limits or authentication needs.

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

Conciseness3/5

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

The description is well-structured with sections like 'When to use', 'Key features', and 'Parameters explained', but it is overly verbose with repetitive lists (e.g., 14 entity types, 14 relation types). Some sentences could be condensed (e.g., the 'You should' section has redundant advice), reducing efficiency. It's front-loaded with purpose but includes unnecessary elaboration.

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

Completeness5/5

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

Given the tool's complexity (2 parameters, no output schema, no annotations), the description is highly complete. It covers purpose, usage, behaviors, parameters, valid types, return information, error handling, and best practices. It provides all necessary context for an AI agent to select and invoke the tool correctly, despite the lack of structured annotations or output schema.

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

Parameters5/5

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

Schema description coverage is 100%, but the description adds significant value beyond the schema. It explains the 'type' parameter with its three enum values and details the 'data' parameter's structure for each type, including nested objects, optional fields, valid entity/relation types, and status/priority values. This compensates for the schema's lack of nested object details and enriches parameter understanding.

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 tool's purpose as 'constructing and enhancing your project management knowledge graph by adding new project elements, relationships, and observations.' It specifies the verb ('constructing and enhancing'), resource ('project management knowledge graph'), and distinguishes from siblings like 'deletecontext' (deletion) and 'loadcontext' (loading).

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

Usage Guidelines5/5

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

The description includes an explicit 'When to use this tool' section with 12 bullet points covering scenarios like creating entities, establishing relationships, and adding metadata. It provides clear context for when to use this tool versus alternatives (e.g., for creation vs. deletion with 'deletecontext'), though it doesn't name specific sibling tools, it implies usage distinctions.

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

deletecontextA

A precise tool for removing elements from the project management knowledge graph, enabling project managers to maintain data accuracy and refine their project structure as needs evolve.

When to use this tool:

  • Removing completed or canceled projects or tasks

  • Deleting erroneous relationships between project elements

  • Clearing outdated observations from project entities

  • Restructuring your project organization as the project evolves

  • Removing team members who are no longer part of the project

  • Correcting relationships between tasks, milestones, and resources

  • Cleaning up the knowledge graph during project phase transitions

  • Eliminating deprecated risks or issues that are no longer relevant

  • Removing preliminary project elements that have been superseded

  • Reorganizing your project structure by removing and recreating elements

  • Updating status assignments when task or project states change

  • Modifying priority levels as project needs shift

  • Restructuring sequential relationships between tasks and activities

Key features:

  • Provides targeted deletion capabilities for three distinct types of knowledge graph elements: entities, relations, and observations

  • Maintains knowledge graph integrity during deletion operations

  • Supports batch deletion of multiple items in a single operation

  • Returns clear confirmation of deletion results

  • Preserves the overall structure of the project knowledge graph while removing specific elements

  • Performs validation to ensure deletion requests are properly formatted

  • Handles status and priority relation management

  • Supports modification of task sequencing relationships

Parameters explained:

  1. type: The type of deletion operation to perform

  • Accepts: "entities", "relations", or "observations"

  • Determines how the data parameter is interpreted

  1. data: The elements to remove from the knowledge graph (structure varies by type):

  • For "entities": Array of entity names to delete

    • Example: ["Task_A", "Milestone_1"]

  • For "relations": Array of relation objects, each containing:

    • from: Name of the source entity

    • to: Name of the target entity

    • relationType: Type of relationship to remove (e.g., "part_of", "has_status", "has_priority", "precedes")

    • Example: [{ "from": "Task_A", "to": "Milestone_1", "relationType": "part_of" }]

  • For "observations": Array of objects, each containing:

    • entityName: Name of the entity to remove observations from

    • observations: Array of specific observations to remove

    • Example: [{ "entityName": "Project_X", "observations": ["duration:3 months", "budget:10000"] }]

Deletion behavior by type:

  • Entities: Removes the specified entities and all their associated relations from the knowledge graph

  • Relations: Removes only the specified relationships, leaving the connected entities intact

  • Observations: Removes specific observations from entities while preserving the entities themselves

Status and Priority Management:

  • When deleting status or priority entities, be aware that all has_status or has_priority relations using these entities will be removed

  • For changing an entity's status, delete the existing has_status relation before creating a new one

  • For changing priority, delete the existing has_priority relation before creating a new one

  • Status values (inactive, active, complete) are managed through relations, not direct properties

  • Priority values (low, high) are managed through relations, not direct properties

Sequential Task Management:

  • Removing precedes relations will affect task sequencing and dependencies

  • When reorganizing project tasks, update all affected precedes relations

  • Consider the impact on project timelines when modifying sequential relationships

Safety considerations:

  • Entity deletion is permanent and will also remove all relationships involving those entities

  • Consider exporting or backing up your project knowledge graph before performing large-scale deletions

  • For sensitive operations, consider removing specific observations rather than entire entities

  • When removing key project elements, consider the impact on your overall project structure

  • Status changes should be carefully managed to maintain accurate project tracking

  • Changes to task sequences may affect dependent project activities

Return information:

  • JSON response indicating success or failure

  • For successful operations:

    • Success flag set to true

    • Confirmation message with count of deleted items

      • For entities: "Deleted X entities"

      • For relations: "Deleted X relations"

      • For observations: "Deleted observations from X entities"

  • For failed operations:

    • Success flag set to false

    • Error message describing the issue

You should:

  • Be specific in your deletion requests to avoid unintended data loss

  • Use relations deletion when you want to disconnect entities without removing them

  • For observations, provide the exact observations to ensure only the intended content is removed

  • When restructuring your project, consider how deletions will affect related elements

  • Use deletecontext in conjunction with buildcontext to refine and evolve your project structure

  • Regularly review your knowledge graph for elements that may need to be removed or updated

  • Consider the cascading effects of entity deletion on your overall project structure

  • Delete completed tasks and milestones systematically when closing project phases

  • Remove resolved risks and issues to keep your project status current

  • When updating entity status, delete the old has_status relation before creating a new one

  • When updating entity priority, delete the old has_priority relation before creating a new one

  • Maintain logical consistency when modifying sequential task relationships

ParametersJSON Schema
NameRequiredDescriptionDefault
dataYesData for the deletion operation, structure varies by type but must be an array
typeYesType of deletion operation: 'entities', 'relations', or 'observations'

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and excels in disclosing behavioral traits. It details deletion behaviors by type (e.g., 'Entities: Removes the specified entities and all their associated relations'), safety considerations (e.g., 'Entity deletion is permanent'), cascading effects, and specific management rules for status, priority, and sequential tasks. This goes far beyond basic functionality.

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

Conciseness3/5

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

The description is well-structured with clear sections (Purpose, When to use, Key features, Parameters, etc.), but it is excessively long with repetitive advice (e.g., multiple reminders about status/priority relation management). While informative, it could be more concise by eliminating redundancy and focusing on essential guidance.

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

Completeness5/5

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

Given the tool's complexity (destructive operations with cascading effects), no annotations, and no output schema, the description provides comprehensive context. It covers purpose, usage, parameters, behavioral details, safety considerations, and even return information, making it complete enough for safe and effective use despite the lack of structured metadata.

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

Parameters5/5

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

Despite 100% schema description coverage, the description adds substantial value beyond the schema. It provides detailed semantics for the 'type' parameter with examples for each enum value, explains how 'data' structure varies by type with concrete examples, and clarifies interpretation rules (e.g., 'Determines how the data parameter is interpreted'). This significantly enhances understanding beyond the schema's basic descriptions.

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 tool's purpose as 'removing elements from the project management knowledge graph' with specific mention of 'entities, relations, and observations.' It distinguishes from sibling 'buildcontext' by being for deletion rather than creation. However, it doesn't explicitly differentiate from other siblings like 'advancedcontext' or 'loadcontext' beyond the deletion focus.

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

Usage Guidelines5/5

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

The description provides extensive, explicit guidance on when to use this tool through a dedicated 'When to use this tool' section with 13 specific scenarios (e.g., 'Removing completed or canceled projects or tasks,' 'Deleting erroneous relationships'). It also mentions using it 'in conjunction with buildcontext' for refinement, giving clear alternatives and context.

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

endsessionA

A multi-stage tool for documenting project management sessions, recording achievements, tracking task updates, and creating a structured record of project evolution.

When to use this tool:

  • Concluding a project planning or review session

  • Documenting decisions made during team meetings

  • Recording updates to tasks and their status

  • Tracking new tasks created during work sessions

  • Documenting changes to project risk assessments

  • Updating overall project status information

  • Creating a structured record of project activities

  • Establishing a formal conclusion to a focused work period

  • Building a historical record of project development

  • Preserving context for future team members or sessions

  • Updating entity status values and tracking progress

  • Modifying task priorities as project needs evolve

  • Establishing or modifying sequential relationships between tasks

Key features:

  • Provides a structured, multi-stage workflow for project session documentation

  • Records project decisions and achievements in the knowledge graph

  • Captures task status updates and progress information

  • Tracks creation of new tasks with descriptions and priorities

  • Documents risk updates with impact and probability assessments

  • Updates project status information

  • Maintains session continuity with unique session IDs

  • Supports revision of previous stages when needed

  • Offers a comprehensive assembly stage that consolidates all session information

  • Manages status progression of project entities via has_status relations

  • Tracks priority assignments for tasks via has_priority relations

  • Documents sequential task relationships via precedes relations

The endsession tool uses a sequential, multi-stage approach with 7 typical stages:

  1. Summary Stage: Records basic session information

  2. Achievements Stage: Documents decisions and accomplishments

  3. Task Updates Stage: Records changes to existing tasks

  4. New Tasks Stage: Documents newly created tasks

  5. Status Updates Stage: Records changes to entity status values

  6. Project Status Stage: Updates the overall project status

  7. Assembly Stage: Consolidates all information and finalizes the session record

Parameters explained:

  1. sessionId: Required - Unique identifier for the project session

  • Obtained from the startsession tool

  • Example: "proj_1234567890_abc123"

  1. stage: Required - Current stage of the endsession workflow

  • Accepts: "summary", "achievements", "taskUpdates", "newTasks", "statusUpdates", "projectStatus", or "assembly"

  • Each stage has specific data requirements and processing logic

  1. stageNumber: Required - The sequence number of the current stage

  • Starts at 1 and typically progresses through the stages

  • Used to track progress through the session documentation workflow

  1. totalStages: Required - Total number of stages planned for this workflow

  • Typically 7 for the complete workflow

  • Provides context for the progress within the overall process

  1. analysis: Optional - Text analysis or observations for the current stage

  • Descriptive text explaining the work done in this stage

  • Example: "Analyzed progress on the marketing campaign project"

  1. stageData: Optional - Stage-specific structured data

  • Structure varies by stage type:

    • summary: { summary: "Session summary text", duration: "3 hours", project: "ProjectName" }

    • achievements: { achievements: ["Decision 1", "Accomplishment 2"] }

    • taskUpdates: { updates: [{ name: "Task1", status: "active", progress: "50%" }] }

    • newTasks: { tasks: [{ name: "New Task", description: "Details", priority: "high", precedes: "Task3" }] }

    • statusUpdates: { statusUpdates: [{ entityName: "Task1", newStatus: "complete", note: "Finished implementation" }, { entityName: "Risk1", newStatus: "inactive", note: "Risk mitigated" }] }

    • projectStatus: { projectStatus: "active", projectObservation: "Good progress", priorityUpdates: [{ entityName: "Task2", priority: "high", note: "Critical for launch" }], sequenceUpdates: [{ before: "Task1", after: "Task4", note: "Rearranged sequence to optimize workflow" }] }

    • assembly: No stageData needed - automatically assembled from previous stages

  1. nextStageNeeded: Required - Whether additional stages are needed after this one

  • Boolean value (true/false)

  • Set to false on the final stage to complete the session

  1. isRevision: Optional - Whether this is revising a previous stage

  • Boolean value (true/false)

  • Default: false

  1. revisesStage: Optional - If revising, which stage number is being revised

  • Required when isRevision is true

  • Indicates which previous stage is being updated

Status and Priority Management:

  • The statusUpdates stage allows for batch updates to entity status values

  • Valid status values include: inactive, active, complete

  • Priority assignments (high, low) can be modified in the projectStatus stage

  • Status changes are implemented through has_status relations

  • Priority changes are implemented through has_priority relations

  • Status and priority changes are tracked to maintain project progress history

Sequential Task Management:

  • The projectStatus stage allows for defining or modifying sequential relationships

  • The precedes relation is used to establish logical ordering between tasks

  • New tasks can specify which tasks they precede or follow

  • Sequential updates help maintain a coherent project workflow

  • Task sequences can be visualized through the loadcontext tool

When the endsession workflow completes (assembly stage with nextStageNeeded: false), the tool performs these actions:

  1. Records the session completion in persistent storage

  2. Creates a summary of all documented information

  3. Updates the project status in the knowledge graph

  4. Links all achievements, task updates, and risk information

  5. Updates status, priority, and sequential relationships for relevant entities

Return information:

  • JSON response with the following structure when stages are in progress:

    • success: Boolean indicating whether the operation succeeded

    • stageCompleted: The stage that was just completed

    • nextStageNeeded: Whether more stages are required

    • stageResult: The processed result of the current stage

  • Formatted markdown text summary when the session is completed, including:

    • Session date and project name

    • Decisions documented

    • Task updates

    • Status changes

    • Priority modifications

    • Task sequencing changes

    • Project status

    • New tasks added

    • Risk updates

    • Session summary

You should:

  • Complete all stages in order for comprehensive session documentation

  • Provide specific details in each stage for accurate project documentation

  • Specify task updates with clear status information using valid values (inactive, active, complete)

  • Include priority levels (high, low) when adding new tasks or updating priorities

  • Document all key decisions made during the session as achievements

  • Update entity status using has_status relations with valid status values

  • Define task sequences using precedes relations to establish workflow

  • If making a revision, specify which stage is being revised

  • Only mark nextStageNeeded as false on the final assembly stage

  • Review the final summary message to confirm all session details were recorded properly

  • Use the unique session ID consistently across all stages

ParametersJSON Schema
NameRequiredDescriptionDefault
analysisNoText analysis or observations for the current stage
isRevisionNoWhether this is revising a previous stage
nextStageNeededYesWhether additional stages are needed after this one (false for final stage)
revisesStageNoIf revising, which stage number is being revised
sessionIdYesThe unique session identifier obtained from startsession
stageYesCurrent stage of analysis: 'summary', 'milestones', 'risks', 'tasks', 'teamUpdates', or 'assembly'
stageDataNoStage-specific data structure - format depends on the stage type: - For 'summary' stage: { summary: "Session summary text", duration: "4 hours", project: "Project Name" } - For 'milestones' stage: { milestones: [{ name: "Milestone1", status: "completed", notes: "Notes about completion" }] } - For 'risks' stage: { risks: [{ name: "Risk1", severity: "high", mitigation: "Plan to address this risk" }] } - For 'tasks' stage: { tasks: [{ name: "Task1", status: "in_progress", assignee: "Team Member", notes: "Status update" }] } - For 'teamUpdates' stage: { teamUpdates: [{ member: "Team Member", status: "Completed assigned tasks", blockers: "None" }] } - For 'assembly' stage: no stageData needed - automatic assembly of previous stages
stageNumberYesThe sequence number of the current stage (starts at 1)
totalStagesYesTotal number of stages in the workflow (typically 6 for standard workflow)

TDQS

A4.6/5.0
Behavior4/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 behavioral disclosure and does so comprehensively. It details the multi-stage workflow (7 typical stages), explains what happens upon completion (e.g., 'Records the session completion in persistent storage,' 'Updates the project status in the knowledge graph'), and covers operational aspects like revision handling, stage progression, and return formats. It does not mention potential errors, rate limits, or authentication needs, but given the depth provided, it exceeds the baseline for no-annotation tools.

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

Conciseness3/5

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

The description is well-structured with clear sections (purpose, usage guidelines, key features, stages, parameters, management details, completion actions, return info, instructions), but it is excessively long and repetitive. For example, the 'When to use this tool' list has 13 items with some redundancy (e.g., 'Documenting decisions' and 'Recording achievements'), and details like 'Status and Priority Management' could be more succinct. While informative, it could be trimmed without losing essential information.

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

Completeness5/5

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

Given the tool's high complexity (9 parameters, multi-stage workflow, no annotations, no output schema), the description is exceptionally complete. It covers purpose, usage, behavior, parameters, workflow stages, management details, completion actions, return formats, and agent instructions. The absence of an output schema is mitigated by detailed explanations of JSON and markdown responses. This provides all necessary context for an agent to use the tool effectively.

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

Parameters5/5

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

Despite 100% schema description coverage, the description adds significant value beyond the schema. It provides a dedicated 'Parameters explained' section with detailed semantics for all 9 parameters, including examples, stage-specific data structures for 'stageData' (e.g., formats for 'achievements,' 'taskUpdates'), and practical usage notes (e.g., 'Obtained from the startsession tool,' 'Typically 7 for the complete workflow'). This compensates for any schema ambiguities and enhances agent understanding.

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 tool's purpose as a 'multi-stage tool for documenting project management sessions' with specific verbs like 'recording achievements, tracking task updates, and creating a structured record.' It distinguishes itself from sibling tools like 'startsession' by focusing on concluding sessions rather than initiating them, and from context tools by handling session documentation rather than context management.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use this tool with a dedicated 'When to use this tool' section listing 13 specific scenarios (e.g., 'Concluding a project planning or review session,' 'Documenting decisions made during team meetings'). It also implicitly distinguishes from alternatives by referencing 'startsession' for obtaining session IDs and 'loadcontext' for visualizing task sequences, though it could more directly contrast with sibling tools like 'advancedcontext' or 'buildcontext.'

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

loadcontextA

A powerful tool for retrieving detailed contextual information about project entities, providing rich insights tailored to each entity type in the project management domain.

When to use this tool:

  • Retrieving comprehensive information about projects, tasks, milestones, and team members

  • Exploring task dependencies and critical path information

  • Examining milestone progress and completion status

  • Reviewing team member assignments and workload

  • Analyzing resource allocation and availability

  • Inspecting project risks and issues

  • Preparing for project status updates and planning meetings

  • Examining project timelines and progress metrics

  • Getting a holistic view of project status and health

  • Understanding relationships between project entities

  • Viewing entity status information (inactive, active, complete)

  • Checking priority levels for tasks and activities

  • Understanding sequential relationships between tasks

Key features:

  • Provides richly formatted, context-aware information about project management entities

  • Adapts output format based on entity type (project, task, milestone, teamMember, resource)

  • Presents both direct entity information and related elements

  • Shows project metrics, task completion rates, and milestone progress

  • Tracks entity views within the current project session

  • Formats information in a structured, readable markdown format

  • Highlights relationships between tasks, milestones, and team members

  • Presents critical path information for task dependencies

  • Shows resource utilization metrics and availability

  • Displays status information via has_status relations

  • Shows priority levels via has_priority relations

  • Presents sequential relationships through precedes relations

Parameters explained:

  1. entityName: Required - The name of the entity to retrieve context for

  • Example: "Marketing Campaign Q4", "Design Homepage", "Website Launch"

  1. entityType: Optional - The type of entity being retrieved

  • Default: "project"

  • Helps the system format the output appropriately

  • Common types include: "project", "task", "milestone", "teamMember", "resource", "status", "priority"

  1. sessionId: Optional - The current session identifier

  • Typically provided by startsession

  • Used for tracking entity views within the session

Each entity type returns specialized context information:

  • Project: Shows project status (via has_status), description, timeline, budget, goal, tasks, milestones, issues, team members, risks, and task completion rate

  • Task: Displays project affiliation, status (inactive, active, complete), priority (low, high), due date, assignee, description, critical path status, task dependencies, and task sequencing (preceding and following tasks)

  • Milestone: Shows project affiliation, status (via has_status), date, completion criteria, description, progress percentage, days remaining, required tasks, and blocking tasks

  • Team Member: Displays role, skills, availability, workload, assigned tasks, projects, upcoming deadlines, and overdue tasks

  • Resource: Shows type, project affiliation, availability, capacity, cost, usage percentage, assigned tasks, and team members using the resource

  • Status: Shows all entities assigned this status value, organized by entity type

  • Priority: Shows all entities assigned this priority value, organized by entity type

  • Other Entity Types: Shows basic entity information, observations, incoming relations, and outgoing relations

Status and Priority Information:

  • All entity displays include status information when available via has_status relations

  • Tasks and other prioritized elements show priority assignments via has_priority relations

  • Valid status values include: inactive, active, complete

  • Valid priority values include: high, low

Sequential Task Relationships:

  • Task displays show preceding and following tasks through precedes relations

  • Sequential relationships are visualized to show workflow between tasks

  • Tasks display their position in the overall project workflow

  • Critical path information highlights essential task sequences

Return information:

  • Formatted markdown text with hierarchical structure

  • Sections adapted to the specific entity type

  • Related entities shown with their relationships

  • Progress metrics and completion statistics where applicable

  • Status and priority information prominently displayed

  • Sequential relationships clearly indicated

  • Error messages if the entity doesn't exist or can't be retrieved

You should:

  • Specify the exact entity name for accurate retrieval

  • Provide the entity type when possible for optimally formatted results

  • Start with project entities to get a high-level overview

  • Examine task context to understand dependencies and critical path

  • Review milestone context to assess progress towards key deliverables

  • Use team member context to evaluate workload and assignments

  • Explore resource context to understand allocation and availability

  • Check status entities to see all project elements at the same stage

  • Review priority entities to identify critical project tasks

  • Explore sequential relationships to understand task workflows

  • After retrieving context, follow up on specific entities of interest

  • Use in conjunction with startsession to maintain session tracking

  • Remember that this tool only retrieves existing information; use buildcontext to add new entities

ParametersJSON Schema
NameRequiredDescriptionDefault
entityNameYes
entityTypeNo
sessionIdNo

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden and delivers comprehensive behavioral disclosure. It explains output format ('formatted markdown text with hierarchical structure'), session tracking behavior, error handling ('Error messages if the entity doesn't exist'), and detailed return information for each entity type. The only minor gap is lack of explicit rate limit or performance characteristics.

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

Conciseness3/5

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

While well-structured with clear sections, the description is excessively long (over 700 words) with repetitive information. Multiple sections cover similar ground (entity type details appear in both 'Key features' and 'Each entity type returns' sections). The core purpose could be communicated more efficiently without sacrificing clarity.

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

Completeness5/5

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

Given 3 parameters with 0% schema coverage, no annotations, and no output schema, the description provides exceptional completeness. It covers all parameters thoroughly, explains behavioral characteristics, details output format and content for each entity type, provides usage scenarios, and contrasts with sibling tools. Nothing essential appears missing for this retrieval tool.

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

Parameters5/5

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

With 0% schema description coverage, the description fully compensates with a detailed 'Parameters explained' section. It provides clear explanations for all 3 parameters including purpose, examples, defaults, and practical usage guidance. The entityType parameter explanation includes a comprehensive list of valid values and their implications for output formatting.

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 tool's purpose as 'retrieving detailed contextual information about project entities' with specific entity types (projects, tasks, milestones, team members, resources). It distinguishes from sibling tools by explicitly contrasting with 'buildcontext' (for adding new entities) and 'deletecontext' (for removal), establishing clear functional boundaries.

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

Usage Guidelines5/5

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

The description provides extensive explicit guidance with a dedicated 'When to use this tool' section listing 13 specific scenarios, plus a 'You should' section with 14 actionable recommendations. It clearly distinguishes when to use this tool ('only retrieves existing information') versus alternatives like 'buildcontext' (for adding new entities) and mentions integration with 'startsession' for session tracking.

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

startsessionA

A comprehensive tool for initializing a new project management session, providing structured information about ongoing projects, tasks, deadlines, and overall project health.

When to use this tool:

  • Beginning a new project management session

  • Getting oriented to your current project portfolio status

  • Planning which projects or tasks to focus on in the current work session

  • Reviewing recent project activity and progress

  • Checking upcoming deadlines for tasks and milestones

  • Assessing the health of active projects

  • Identifying high-priority tasks requiring attention

  • Reviewing project risks that need mitigation

  • Establishing context before diving into specific project work

  • Creating a structured record of your project management activity

  • Tracking the status of various project entities

  • Managing sequential task dependencies

Key features:

  • Generates a unique session identifier for tracking project management activities

  • Retrieves and displays your most recent project management sessions

  • Shows active projects you're currently managing with status information

  • Highlights high-priority tasks requiring attention

  • Lists upcoming milestones with progress metrics

  • Provides project health summaries with status indicators

  • Identifies top project risks requiring mitigation

  • Formats information in a structured, easy-to-read format

  • Integrates with the loadcontext tool for deeper exploration

  • Maintains continuity between project management sessions

  • Displays status information through has_status relations

  • Shows priority assignments through has_priority relations

  • Presents task sequencing through precedes relations

Parameters explained: No parameters required - the tool automatically retrieves all relevant context.

Return information:

  • Session ID: A unique identifier for this project management session

  • Recent Project Management Sessions: Up to 3 most recent sessions with:

    • Date

    • Project focus

    • Session summary (truncated for readability)

  • Active Projects: List of current projects with:

    • Project name

    • Current status (via has_status relation)

    • Deadline information

  • High-Priority Tasks: Up to 10 highest priority tasks with:

    • Task name

    • Associated project

    • Status (inactive, active, complete)

    • Priority (high via has_priority relation)

    • Assignee

  • Upcoming Milestones: Up to 8 nearest milestones with:

    • Milestone name

    • Associated project

    • Due date

    • Completion percentage

    • Status (via has_status relation)

  • Project Health Summary: Status of active projects with:

    • Project name

    • Health status indicator

    • Health score

    • Issue count

    • Risk count

  • Top Project Risks: Up to 5 highest severity risks with:

    • Risk name

    • Associated project

    • Severity level

    • Impact assessment

  • Next Sequence Tasks: Up to 5 tasks ready to be worked on next based on sequential dependencies:

    • Task name

    • Associated project

    • Status (via has_status relation)

    • Prerequisites completion status

Status and Priority Information:

  • Project and task status is retrieved through has_status relations

  • Valid status values include: inactive, active, complete

  • Task priority is retrieved through has_priority relations

  • Valid priority values include: high, low

  • This information helps you prioritize your project management activities

Sequential Task Management:

  • Tasks are presented in their logical sequence based on precedes relations

  • Prerequisite tasks must be completed before dependent tasks can begin

  • The sequential view helps identify the next logical actions in project workflows

  • Critical path tasks are highlighted to show dependencies affecting project timelines

Session Workflow:

  1. Start a project management session with startsession

  2. Review the provided context to decide what to focus on

  3. Use loadcontext to retrieve detailed information about specific projects

  4. Conduct your project management work, adding new elements with buildcontext as needed

  5. End the session when work is complete

  6. Record progress, decisions, and next steps

You should:

  • Begin each focused project management period with startsession

  • Review recent sessions to maintain continuity in your work

  • Prioritize work based on high-priority tasks and upcoming milestones

  • Address projects with poor health indicators

  • Mitigate high-severity risks promptly

  • Focus on tasks that are next in sequence based on precedes relations

  • Complete prerequisite tasks to unblock dependent tasks

  • Check entity status to identify active work items

  • Use the session ID when using other tools to maintain session tracking

  • Establish a regular cadence of project management sessions

  • Use the structured overview to make deliberate choices about where to focus your effort

  • Consider creating or updating project entities after reviewing the current state

  • Follow up on projects with approaching deadlines

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.4/5.0
Behavior4/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 behavioral disclosure. It effectively describes behavioral traits such as generating a unique session ID, retrieving recent sessions (up to 3), listing active projects, highlighting high-priority tasks (up to 10), and formatting information in a structured way. However, it lacks details on potential errors, performance characteristics, or rate limits, which slightly limits transparency.

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 excessively long and verbose, with redundant sections (e.g., repeating status/priority information and workflow advice). While it is front-loaded with purpose and usage, many sentences (like detailed lists of return fields and extensive workflow instructions) do not earn their place, making it overly detailed and less concise than ideal for a tool description.

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

Completeness5/5

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

Given the tool's complexity (project management session initialization) and the absence of annotations and output schema, the description provides comprehensive context. It details return information, status/priority handling, sequential task management, session workflow, and usage recommendations, making it complete enough for an agent to understand and invoke the tool effectively without structured output data.

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

Parameters4/5

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

The input schema has 0 parameters with 100% coverage, so the baseline is 4. The description adds value by explicitly stating 'No parameters required - the tool automatically retrieves all relevant context,' which clarifies the parameterless nature and the tool's automatic context retrieval behavior, going beyond what the schema alone provides.

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 tool's purpose as 'initializing a new project management session' and 'providing structured information about ongoing projects, tasks, deadlines, and overall project health.' It distinguishes itself from siblings like 'loadcontext' (for deeper exploration) and 'buildcontext' (for adding new elements), making the verb+resource+scope specific and differentiated.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use this tool, including a dedicated 'When to use this tool' section with 12 specific scenarios (e.g., 'Beginning a new project management session,' 'Getting oriented to your current project portfolio status'). It also contrasts with alternatives by mentioning integration with 'loadcontext' for deeper exploration and outlines a session workflow that positions 'startsession' as the initial step, clearly differentiating it from sibling tools.

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. Dates show when Glama detected each change.

  1. 6 tool updatesv1.0.0
    • First observedadvancedcontext
    • First observedbuildcontext
    • First observeddeletecontext
    • First observedendsession
    • First observedloadcontext
    • First observedstartsession

TDQS

A4.5/5.0
Disambiguation5/5

Each tool has a distinct, non-overlapping purpose: advancedcontext for querying, buildcontext for creating, deletecontext for deleting, endsession for session documentation, loadcontext for retrieving entity details, and startsession for session initialization. The descriptions clearly differentiate their functions, eliminating ambiguity.

Naming Consistency4/5

Most tools follow a consistent pattern with a verb or action prefix (advanced, build, delete, end, load, start) followed by 'context' or 'session', making them predictable. However, 'advancedcontext' deviates slightly by using an adjective instead of a verb, and 'loadcontext' uses 'load' while others use more specific verbs like 'build' or 'delete', but overall the naming is readable and coherent.

Tool Count5/5

With 6 tools, the server is well-scoped for project management, covering essential operations like querying, creating, deleting, session handling, and entity retrieval. Each tool serves a clear purpose without redundancy, making the count appropriate for the domain.

Completeness5/5

The tool set provides comprehensive coverage for project management: advancedcontext handles complex queries, buildcontext enables CRUD-like creation, deletecontext allows removal, endsession documents sessions, loadcontext retrieves details, and startsession initializes sessions. There are no obvious gaps; the tools support full lifecycle management, status/priority handling, and sequential dependencies.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tejpalvirk/project'

If you have feedback or need assistance with the MCP directory API, please join our Discord server