Project MCP Server
Supports containerized deployment of the Project MCP server through Docker, allowing for isolated and portable execution of the project management environment.
Enables installation directly from GitHub repositories, facilitating easy distribution and updates of the project management server.
Leverages npm for package management and installation, supporting both global installation and npx execution patterns for the project management server.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Project MCP Serverstart a new session for the Q4 marketing campaign project"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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:
summary: Records session summary, duration, and project focus
achievements: Documents key achievements from the session
taskUpdates: Tracks updates to existing tasks
newTasks: Records new tasks created during the session
statusUpdates: Records changes to entity status values
projectStatus: Updates overall project status, priority assignments, and sequential relationships
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/projectThen 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.jsDocker:
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-projectAvailable Tools
6 toolsadvancedcontextA
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:
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
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
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Parameters for the get operation, structure varies by type | |
| type | Yes | Type of get operation |
TDQS
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.
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.
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.
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.
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.
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:
type: The type of creation operation to perform
Accepts: "entities", "relations", or "observations"
Determines how the data parameter is interpreted
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
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Data for the creation operation, structure varies by type but must be an array | |
| type | Yes | Type of creation operation: 'entities', 'relations', or 'observations' |
TDQS
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.
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.
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.
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.
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.
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:
type: The type of deletion operation to perform
Accepts: "entities", "relations", or "observations"
Determines how the data parameter is interpreted
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
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Data for the deletion operation, structure varies by type but must be an array | |
| type | Yes | Type of deletion operation: 'entities', 'relations', or 'observations' |
TDQS
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.
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.
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.
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.
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.
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:
Summary Stage: Records basic session information
Achievements Stage: Documents decisions and accomplishments
Task Updates Stage: Records changes to existing tasks
New Tasks Stage: Documents newly created tasks
Status Updates Stage: Records changes to entity status values
Project Status Stage: Updates the overall project status
Assembly Stage: Consolidates all information and finalizes the session record
Parameters explained:
sessionId: Required - Unique identifier for the project session
Obtained from the startsession tool
Example: "proj_1234567890_abc123"
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
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
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
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"
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
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
isRevision: Optional - Whether this is revising a previous stage
Boolean value (true/false)
Default: false
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:
Records the session completion in persistent storage
Creates a summary of all documented information
Updates the project status in the knowledge graph
Links all achievements, task updates, and risk information
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
| Name | Required | Description | Default |
|---|---|---|---|
| analysis | No | Text analysis or observations for the current stage | |
| isRevision | No | Whether this is revising a previous stage | |
| nextStageNeeded | Yes | Whether additional stages are needed after this one (false for final stage) | |
| revisesStage | No | If revising, which stage number is being revised | |
| sessionId | Yes | The unique session identifier obtained from startsession | |
| stage | Yes | Current stage of analysis: 'summary', 'milestones', 'risks', 'tasks', 'teamUpdates', or 'assembly' | |
| stageData | No | Stage-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 | |
| stageNumber | Yes | The sequence number of the current stage (starts at 1) | |
| totalStages | Yes | Total number of stages in the workflow (typically 6 for standard workflow) |
TDQS
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.
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.
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.
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.
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.
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:
entityName: Required - The name of the entity to retrieve context for
Example: "Marketing Campaign Q4", "Design Homepage", "Website Launch"
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"
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
| Name | Required | Description | Default |
|---|---|---|---|
| entityName | Yes | ||
| entityType | No | ||
| sessionId | No |
TDQS
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.
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.
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.
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.
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.
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:
Start a project management session with startsession
Review the provided context to decide what to focus on
Use loadcontext to retrieve detailed information about specific projects
Conduct your project management work, adding new elements with buildcontext as needed
End the session when work is complete
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
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
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.
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.
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.
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.
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.
6 tool updates
v1.0.0- First observed
advancedcontext - First observed
buildcontext - First observed
deletecontext - First observed
endsession - First observed
loadcontext - First observed
startsession
TDQS
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.
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.
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.
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
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
Durable, shareable and governed project memory with smart triage and explicit project composition.
Project memory for coding agents: requirements, decisions, code graph and delivery telemetry.
1- TaskfolkOAuthai.taskfolk
Project management for teams and their AI agents.
Research portfolio management — organize projects and track research artifacts.
Related MCP Servers
- FlicenseAqualityDmaintenanceProvides tools for managing qualitative research knowledge graphs, enabling structured representation of research projects, participants, interviews, observations, codes, themes, and findings.610-
- FlicenseAqualityDmaintenanceProvides tools for managing student knowledge graphs, enabling structured representation of courses, assignments, exams, concepts, and study resources.61-
- AlicenseAqualityNot gradedmaintenanceProvides centralized knowledge management for projects, allowing users to store, search, and maintain project-specific knowledge that persists across sessions.27141-
- AlicenseAqualityDmaintenanceEnables creating, managing, analyzing, and visualizing knowledge graphs with support for multiple graph types (topology, timelines, changelogs, requirements, knowledge bases, ontologies) including node/edge management and resource association.15221MIT
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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