Skip to main content
Glama
tejpalvirk

Project MCP Server

by tejpalvirk

Project MCP Server

An MCP server implementation that provides tools for managing project knowledge graphs, enabling structured representation of projects, tasks, milestones, resources, and team members. This server helps project managers track progress, manage risks, allocate resources, and make informed decisions.

Features

  • Persistent Project Context: Maintain a structured knowledge graph of project entities and relationships across multiple sessions

  • Session Management: Track project management sessions with unique IDs and record progress over time

  • Project Status Tracking: Monitor project health, risks, and issue status in real time

  • Task Dependencies: Visualize and manage dependencies between tasks to identify bottlenecks

  • Milestone Progress: Track progress towards key project milestones

  • Resource Allocation: Monitor how resources are distributed across projects and tasks

  • Risk Assessment: Identify, monitor, and mitigate project risks

  • Decision Logging: Record important project decisions and their context

  • Team Member Management: Track assignments and workloads for team members

  • Project Timeline Analysis: Analyze project timelines including critical paths

Related MCP server: Student MCP Server

Entities

The Project MCP Server recognizes the following entity types:

  • project: The main container for all related entities

  • task: Individual work items that need to be completed

  • milestone: Key checkpoints or deliverables in the project

  • resource: Materials, tools, or assets needed for the project

  • teamMember: People involved in the project

  • note: Documentation, ideas, or observations

  • document: Formal project documents

  • issue: Problems or blockers

  • risk: Potential future problems

  • decision: Important choices made during the project

  • dependency: External requirements or prerequisites

  • component: Parts or modules of the project

  • stakeholder: People affected by or interested in the project

  • change: Modifications to project scope or requirements

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

  • priority: Priority level values (high, low)

Relationships

Entities can be connected through the following relationship types:

  • part_of: Indicates an entity is a component/subset of another

  • depends_on: Shows dependencies between entities

  • assigned_to: Links tasks to team members

  • created_by: Tracks who created an entity

  • modified_by: Records who changed an entity

  • related_to: Shows general connections between entities

  • blocks: Indicates one entity is blocking another

  • manages: Shows management relationships

  • contributes_to: Shows contributions to entities

  • documents: Links documentation to entities

  • scheduled_for: Connects entities to dates or timeframes

  • responsible_for: Assigns ownership/responsibility

  • reports_to: Indicates reporting relationships

  • categorized_as: Links entities to categories or types

  • required_for: Shows requirements for completion

  • discovered_in: Links issues to their discovery context

  • resolved_by: Shows what resolved an issue

  • impacted_by: Shows impact relationships

  • stakeholder_of: Links stakeholders to projects/components

  • prioritized_as: Indicates priority levels

  • has_status: Links entities to their current status (inactive, active, complete)

  • has_priority: Links entities to their priority level (high, low)

  • precedes: Indicates that one task comes before another in a sequence

Available Tools

The Project MCP Server provides these tools for interacting with project knowledge:

startsession

Starts a new project management session, generating a unique session ID and displaying current projects, tasks, milestones, risks, and recent sessions. Shows status information via has_status relations, priority levels via has_priority relations, and identifies tasks ready to be worked on next based on sequential dependencies.

loadcontext

Loads detailed context for a specific entity (project, task, etc.), displaying relevant information based on entity type. Includes status information (inactive, active, complete), priority levels (high, low), and sequential task relationships.

endsession

Records the results of a project management session through a structured, multi-stage process:

  1. summary: Records session summary, duration, and project focus

  2. achievements: Documents key achievements from the session

  3. taskUpdates: Tracks updates to existing tasks

  4. newTasks: Records new tasks created during the session

  5. statusUpdates: Records changes to entity status values

  6. projectStatus: Updates overall project status, priority assignments, and sequential relationships

  7. assembly: Final assembly of all session data

buildcontext

Creates new entities, relations, or observations in the knowledge graph:

  • entities: Add new project-related entities (projects, tasks, milestones, status, priority, etc.)

  • relations: Create relationships between entities (including has_status, has_priority, precedes)

  • observations: Add observations to existing entities

deletecontext

Removes entities, relations, or observations from the knowledge graph:

  • entities: Remove project entities

  • relations: Remove relationships between entities (including status, priority, and sequential relations)

  • observations: Remove specific observations from entities

advancedcontext

Retrieves information from the knowledge graph:

  • graph: Get the entire knowledge graph

  • search: Search for nodes based on query criteria

  • nodes: Get specific nodes by name

  • related: Find related entities

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

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

  • sequence: Identify sequential relationships for tasks

Domain-Specific Functions

The Project MCP Server includes specialized domain functions for project management:

  • getProjectOverview: Comprehensive view of a project including tasks, milestones, team members, issues, etc.

  • getTaskDependencies: Analyze task dependencies to identify blocked tasks and critical paths

  • getTeamMemberAssignments: View all assignments for a specific team member

  • getMilestoneProgress: Track progress towards project milestones

  • getProjectTimeline: Analyze project timeline and key dates

  • getResourceAllocation: Examine how resources are allocated across the project

  • getProjectRisks: Identify and assess project risks

  • findRelatedProjects: Discover connections between different projects

  • getDecisionLog: Track decision history and context

  • getProjectHealth: Assess overall project health with metrics and recommendations

  • getStatusOverview: View all entities with a specific status (inactive, active, complete)

  • getPriorityItems: Identify high-priority tasks and activities

  • getTaskSequence: Visualize the sequence of tasks based on precedes relations

Example Prompts

Starting a Session

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

Loading Project Context

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

Recording Session Results

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.

Managing Project Knowledge

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.

Usage

This MCP server enables project managers to:

  • Maintain Context Continuity: Keep track of project details across multiple planning sessions

  • Onboard New Team Members: Quickly get new team members up to speed on project status

  • Record Session Results: Document the outcomes of meetings and work sessions

  • Track Dependencies: Identify and manage critical dependencies and bottlenecks

  • Monitor Risk: Keep track of project risks and implement mitigation strategies

  • Allocate Resources: Optimize resource allocation across projects and tasks

  • Make Informed Decisions: Base decisions on comprehensive project data

  • Track Progress: Monitor entity status throughout the project lifecycle

  • Prioritize Work: Identify and focus on high-priority tasks

  • Sequence Tasks: Plan and visualize the logical order of project tasks

Configuration

Usage with Claude Desktop

Add this to your claude_desktop_config.json:

Install from GitHub and run with npx

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

Install globally and run directly

First, install the package globally:

npm install -g github:tejpalvirk/project

Then configure Claude Desktop:

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

docker

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

Building

From Source

# 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:

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

License

This MCP server is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License. For more details, please see the LICENSE file in the project repository.

Environment Variables

The Project MCP Server supports the following environment variables to customize where data is stored:

  • MEMORY_FILE_PATH: Path where the knowledge graph data will be stored

    • Can be absolute or relative (relative paths use current working directory)

    • Default: ./project/memory.json

  • SESSIONS_FILE_PATH: Path where session data will be stored

    • Can be absolute or relative (relative paths use current working directory)

    • Default: ./project/sessions.json

Example usage:

# 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