소프트웨어 개발 팀을 위해 특별히 설계된 강력한 컨텍스트 관리 시스템입니다. Developer MCP Server는 코딩 세션 전반에 걸쳐 지속적인 컨텍스트를 유지하여 프로젝트의 구조, 종속성 및 진행 상황을 항상 파악할 수 있도록 해줍니다.
지속적인 개발 컨텍스트 : 구성 요소, 문제 및 작업 내용에 대한 완전한 컨텍스트를 제공하여 마지막 세션에서 중단한 부분부터 정확하게 작업을 이어갈 수 있습니다.
세션 관리 : 새로운 개발 세션을 시작하고 완료되면 성과, 작업 업데이트, 프로젝트 상태 변경 사항을 기록하여 개발 활동에 대한 지속적인 기록을 생성합니다.
종속성 추적 : 포괄적인 종속성 모델을 통해 구성 요소, 기능 및 기술이 서로 어떻게 관련되어 있는지 파악합니다.
프로젝트 상태 통찰력 : 구성 요소, 기능, 문제 및 이정표 상태를 포함하여 프로젝트 진행 상황을 즉시 파악할 수 있습니다.
구성 요소 컨텍스트 검색 : 모든 구성 요소의 목적, 구현 세부 정보, 종속성 및 관련 문제를 한눈에 파악합니다.
결정 내역 : 아키텍처 및 구현 결정이 언제, 누구에 의해 내려졌는지 추적하세요. 더 이상 무언가가 특정 방식으로 만들어진 이유를 추측할 필요가 없습니다.
이정표 진행 추적 : 프로젝트 이정표에 대한 진행 상황을 모니터링하고 타임라인을 벗어나기 전에 잠재적인 병목 현상을 파악합니다.
관련 엔터티 검색 : 모든 구성 요소, 기능 또는 작업에 대한 모든 관련 엔터티를 빠르게 찾아 전체 컨텍스트를 파악합니다.
Related MCP server: Context Management System
개발자 MCP 서버는 소프트웨어 개발 컨텍스트에서 다음 유형의 엔터티를 인식합니다.
프로젝트 : 전반적인 소프트웨어 프로젝트 또는 제품
구성 요소 : 프로젝트 내의 모듈, 서비스, 패키지 또는 논리적 단위
특징 : 개발 중인 특정 기능
문제 : 해결해야 할 버그, 문제점 또는 결함
작업 : 개발에 필요한 작업 항목 또는 활동
개발자 : 프로젝트를 진행하는 팀원
기술 : 프로그래밍 언어, 프레임워크, 라이브러리 또는 도구
결정 : 중요한 기술적 또는 건축적 결정
이정표 : 주요 프로젝트 마감일 또는 단계
환경 : 개발, 스테이징 또는 프로덕션 환경
문서 : 프로젝트 문서 리소스
요구 사항 : 프로젝트 요구 사항 또는 사양
개발자 MCP 서버는 실제 소프트웨어 개발 역학을 반영하여 다음과 같은 엔터티 간의 관계를 모델링합니다.
depends_on : 엔티티 A가 기능하려면 엔티티 B가 필요합니다.
구현 : 구성 요소가 기능을 구현합니다.
assigned_to : 작업이 개발자에게 할당됨
blocked_by : 작업이 문제로 인해 차단되었습니다.
사용 : 구성 요소는 기술을 사용합니다
part_of : 컴포넌트가 프로젝트의 일부입니다.
포함 : 프로젝트에 구성 요소가 포함되어 있습니다.
works_on : 개발자가 프로젝트/구성요소 작업을 수행합니다.
related_to : 엔터티 간의 일반적인 관계
영향 : 문제가 구성 요소에 영향을 미칩니다.
해결 : 작업이 문제를 해결합니다.
created_by : 개발자가 엔터티를 생성했습니다.
documented_in : 구성 요소가 문서에 문서화되었습니다.
decided_in : 회의에서 결정이 내려졌습니다.
필수_기준 : 기능은 요구 사항에 의해 필요합니다.
has_status : 엔티티에 특정 상태가 있습니다.
depends_on_milestone : 작업은 마일스톤 달성 여부에 따라 달라집니다.
선행 : 작업이 다른 작업보다 선행함(시퀀싱)
리뷰 : 개발자가 구성 요소를 리뷰합니다.
tested_in : 구성 요소가 환경에서 테스트되었습니다.
개발자 MCP 서버는 다음과 같은 도구를 제공합니다.
startsession : 새로운 개발 세션을 시작하고 최근 세션, 진행 중인 프로젝트, 우선순위가 높은 작업, 다가올 이정표에 대한 정보를 제공합니다.
loadcontext : 엔터티(프로젝트, 구성 요소, 기능, 작업 등)에 대한 자세한 컨텍스트를 로드하고 현재 세션의 일부로 이 컨텍스트 로드를 추적합니다.
endsession : 여러 단계(요약, 성과, 작업 업데이트, 새 작업, 프로젝트 상태)를 거쳐 개발 세션에 대한 구조화된 분석을 수행하고 이 정보를 지속적인 지식 그래프에 기록합니다.
buildcontext : 지식 그래프에 새로운 엔터티, 관계 또는 관찰을 생성합니다.
deletecontext : 지식 그래프에서 엔터티, 관계 또는 관찰을 제거합니다.
advancedcontext : 다양한 쿼리 유형(그래프, 검색, 노드, 관련, 결정, 마일스톤)을 사용하여 지식 그래프에서 정보를 검색합니다.
다음은 개발자 MCP 서버와 함께 사용할 수 있는 몇 가지 프롬프트 예입니다.
지엑스피1
"Show me the current status of the AuthService project."
"Load the context for the UserProfile component."
"What are the open issues affecting the Payment feature?"
"Show me details about the upcoming Q2 Release milestone.""End my development session. I've been working on AuthService for 3 hours and completed user authentication flow implementation."
"Record my achievements for today: implemented password reset feature and fixed login redirect bug."
"Update the status of these tasks: Login Form is complete, User Registration is in progress."
"Create new tasks for the next sprint: Implement MFA, Add social login options.""Create a new feature called 'BillingSystem' in the ProjectX project."
"Create a relationship showing that PaymentComponent implements BillingSystem feature."
"Show me all components that depend on the DatabaseService."
"What decisions have been made about the authentication approach for ProjectX?"개발자 MCP 서버는 다음과 같은 시나리오에서 탁월한 성능을 발휘합니다.
"Let me see the component I was working on yesterday and all its dependencies."서버는 가장 최근에 액세스한 구성 요소와 해당 종속성, 문제 및 관련 작업을 검색하므로 컨텍스트를 재구성하는 데 시간을 들이지 않고도 작업을 즉시 재개할 수 있습니다.
"Give me an overview of Project X's architecture and component structure."새로운 개발자는 프로젝트 구조, 주요 구성 요소 및 그 관계를 빠르게 이해할 수 있으며, 새로운 코드베이스에서 생산성을 발휘하는 데 필요한 시간을 크게 줄일 수 있습니다.
"End my development session and record what I accomplished."이 서버는 귀하의 성과, 작업 업데이트, 프로젝트 상태 변경 사항을 문서화하는 체계적인 프로세스를 안내하며, 이러한 맥락을 향후 세션과 팀원을 위해 보존합니다.
"Why was GraphQL chosen over REST for the API layer?"서버는 관련 회의, 참여한 개발자, 의사 결정이 내려진 맥락과 함께 의사 결정 엔터티를 검색하여 그렇지 않으면 손실될 수 있는 조직 지식을 보존합니다.
"What would be affected if we modify the authentication service?"개발자는 변경을 하기 전에 특정 구성 요소에 의존하는 모든 구성 요소, 기능 및 작업을 이해하여 예상치 못한 손상 위험을 줄일 수 있습니다.
"What's our progress toward the Q2 release milestone?"프로젝트 리더는 이정표와 관련된 모든 작업 및 기능의 상태를 즉시 확인하여 타임라인을 위협하기 전에 위험 항목을 식별할 수 있습니다.
claude_desktop_config.json 에 다음을 추가하세요:
{
"mcpServers": {
"developer": {
"command": "npx",
"args": [
"-y",
"github:tejpalvirk/developer"
]
}
}
}먼저, 패키지를 전역적으로 설치합니다.
npm install -g github:tejpalvirk/contextmanager/developer그런 다음 Claude Desktop을 구성합니다.
{
"mcpServers": {
"developer": {
"command": "contextmanager-developer"
}
}
}{
"mcpServers": {
"developer": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"mcp/developer"
]
}
}
}# 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 developer
node developer_index.jsdocker build -t mcp/developer -f developer/Dockerfile .이 MCP 서버는 MIT 라이선스에 따라 라이선스가 부여됩니다. 즉, MIT 라이선스의 조건에 따라 소프트웨어를 자유롭게 사용, 수정 및 배포할 수 있습니다. 자세한 내용은 프로젝트 저장소의 LICENSE 파일을 참조하세요.
A sophisticated tool for advanced querying and analysis of the software development knowledge graph. This tool provides specialized operations to extract meaningful insights and contextual information from the graph structure. It enables deep exploration of projects, components, relationships, decisions, and progress tracking.
When to use this tool:
Retrieving the complete development knowledge graph
Searching for specific entities using keyword or partial matching
Fetching details on a precise set of development entities
Exploring all relationships for a specific entity
Examining the decision history for a software project
Tracking progress toward project milestones
Investigating dependencies between components
Analyzing the evolution of a software project
Understanding the context surrounding development entities
Exploring task sequencing and dependencies
Identifying entities by status or priority
Key features:
Six specialized query operation types
Full graph retrieval with entities and relations
Keyword-based search across entities and their properties
Direct entity lookup by exact name
Relationship exploration with filtering options
Project decision history with chronological ordering
Milestone progress tracking with task status breakdown
Status and priority information retrieval
Parameters explained:
type: The query operation type to perform, which must be one of:
"graph" - Retrieve the entire knowledge graph (all entities and relations)
"search" - Find entities by keyword/partial match in name, type, or observations
"nodes" - Get specific entities by exact name
"related" - Get all entities related to a specific entity
"decisions" - Get the decision history for a project
"milestone" - Get progress tracking for a specific milestone
params: Operation-specific parameters structure:
For "graph": No parameters needed
For "search": { query: "search text" }
For "nodes": { names: ["EntityName1", "EntityName2", ...] }
For "related": { entityName: "EntityName", relationTypes: ["type1", "type2", ...] }
For "decisions": { projectName: "ProjectName" }
For "milestone": { milestoneName: "MilestoneName" }
Operation details:
"graph" returns the complete knowledge graph structure
"search" performs partial matching on entity names, types, and observations
"nodes" retrieves specific entities by exact name matching
"related" finds all incoming and outgoing relationships for an entity
"decisions" retrieves and chronologically sorts project decisions
"milestone" calculates progress percentage and task breakdowns with status information
Notes:
Valid status values: "inactive", "active", or "complete"
Valid priority values: "low" or "high"
Status is represented via the has_status relation type, and priority via has_priority
Return structures:
All operations return { success: true/false, ... } with operation-specific data
Error responses include detailed error messages
"related" returns both incoming and outgoing relationships
"milestone" includes progress percentage and task categorization by status
Sequencing information appears in directed relationship graphs
You should:
Select the most appropriate query type for your information need
Provide the required parameters for your chosen operation type
Start with broader queries and refine to more specific ones
Use "search" for exploratory investigation when entity names are unknown
Use "related" to explore the neighborhood of a known entity
Use "decisions" to understand the rationale behind project changes
Use "milestone" to evaluate project progress and identify blockers
Analyze task sequencing to understand dependencies and critical paths
Filter entities by status to focus on active, inactive, or completed items
Consider entity priorities when planning work or resolving issues
Combine query results to build comprehensive understanding
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Parameters for the operation, structure varies by type | |
| type | Yes | Type of get operation: 'graph', 'search', 'nodes', 'related', 'decisions', or 'milestone' |
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 six specialized query operations, explains return structures including error handling, specifies valid status and priority values, and describes how sequencing information appears. It covers behavioral aspects like partial matching, chronological ordering, and progress calculation that aren't inferable from the schema alone.
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 (When to use, Key features, Parameters explained, etc.), but it's excessively long with repetitive information. Sentences like 'It enables deep exploration of projects, components, relationships, decisions, and progress tracking' could be more concise, and some details in the 'You should' section overlap with earlier guidance, reducing efficiency.
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 (6 operation types with varying parameters) and lack of annotations or output schema, the description provides complete context. It covers all operations, parameter structures, return formats, valid values, and usage strategies. The detailed explanations compensate for the missing structured data, making the tool fully understandable for an AI agent.
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 explains each 'type' enum value with specific use cases and details the 'params' structure for each operation type, including examples like { query: 'search text' } and { names: ['EntityName1', ...] }. This provides crucial semantic context that the schema's generic descriptions don't cover.
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 'advanced querying and analysis of the software development knowledge graph' with specific verbs like 'extract meaningful insights,' 'deep exploration,' and 'tracking progress.' It distinguishes itself from siblings like 'buildcontext' and 'deletecontext' by focusing on query operations rather than creation or deletion.
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 11 specific scenarios (e.g., 'Retrieving the complete development knowledge graph,' 'Exploring all relationships for a specific entity'). It also includes a 'You should' section with 11 actionable recommendations for selecting query types and refining searches, offering 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.
A powerful tool for building and enriching the software development knowledge graph through creation operations. This tool allows developers to add new entities, create relationships between entities, or add observations to existing entities. Each operation type serves a specific purpose in constructing a comprehensive development context model.
When to use this tool:
Creating new project components like features, tasks, and milestones
Establishing relationships between development entities (e.g., component implements feature)
Documenting observations about existing entities (statuses, descriptions, etc.)
Building a graph of connected software development artifacts
Recording new information discovered during development
Tracking project structure, dependencies, and status
Documenting developer roles and assignments
Setting entity status and priority values
Defining task sequencing and dependencies
Key features:
Three distinct operation types (entities, relations, observations)
Type validation against software development domain standards
Automatic rejection of invalid entity or relation types
Safe addition of new observations to existing entities
JSON-formatted response with operation results
Clear error messages when operations fail
Handles both single and batch operations
Parameters explained:
type: The operation type to perform, which must be one of:
"entities" - Create new software development entities
"relations" - Create relationships between existing entities
"observations" - Add observations to existing entities
data: Operation-specific data structure:
For "entities": Array of objects with { name, entityType, observations[] }
For "relations": Array of objects with { from, to, relationType }
For "observations": Array of objects with { entityName, contents[] }
Entity Types:
project - Overall software project
component - Module, service, or package within a project
feature - Specific functionality being developed
issue - Bug or problem to be fixed
task - Work item or activity needed for development
developer - Team member working on the project
technology - Language, framework, or tool used
decision - Important technical or architectural decision
milestone - Key project deadline or phase
environment - Development, staging, production environments
documentation - Project documentation
requirement - Project requirement or specification
status - Entity status (inactive, active, or complete)
priority - Entity priority (low or high)
Relation Types include:
depends_on - Dependency relationship
implements - Component implements a feature
blocked_by - Task is blocked by an issue
uses - Component uses a technology
part_of - Component is part of a project
contains - Project contains a component
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)
related_to - General relationship
affects - Issue affects a component
resolves - Task resolves an issue
documented_in - Component is documented in documentation
decided_in - Decision was made in a meeting
required_by - Feature is required by a requirement
depends_on_milestone - Task depends on reaching a milestone
tested_in - Component is tested in an environment
You should:
Specify the operation type based on what you need to create (entities, relations, or observations)
Structure your data according to the operation type's requirements
Use valid entity types and relation types from the software development domain
Ensure entities exist before creating relations between them
Provide meaningful names and descriptions for new entities
Use observations to add metadata about entities
Create complete structures rather than adding entities/relations piecemeal
For task sequencing, use the 'precedes' relation to define which tasks must be completed before others
Set status values using the has_status relation (valid values: inactive, active, complete)
Set priority values using the has_priority relation (valid values: low, high)
| 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' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does so effectively. It discloses key behavioral traits: 'Three distinct operation types,' 'Type validation against software development domain standards,' 'Automatic rejection of invalid entity or relation types,' 'Safe addition of new observations,' 'JSON-formatted response,' 'Clear error messages,' and 'Handles both single and batch operations.' It covers most aspects well but could mention performance characteristics like rate limits or latency.
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 appropriately structured with clear sections (purpose, when to use, key features, parameters explained, entity types, relation types, guidelines), but it is lengthy with multiple lists and detailed examples. While informative, some content could be more condensed without losing value, making it less front-loaded than ideal.
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 (multiple operation types, extensive domain-specific types) and lack of annotations or output schema, the description is highly complete. It covers purpose, usage, behavior, parameters with examples, valid types, and detailed guidelines, providing all necessary context for an AI agent to use the tool effectively without structured fields.
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 meaning beyond the input schema's 100% coverage. It explains the 'type' parameter's three values with detailed semantics ('entities' for creating new entities, 'relations' for relationships, 'observations' for adding metadata) and provides extensive context for the 'data' parameter with examples of valid structures, entity types (14 listed), and relation types (17 listed). This greatly enhances understanding of how to structure inputs.
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: 'building and enriching the software development knowledge graph through creation operations' and specifies it 'allows developers to add new entities, create relationships between entities, or add observations to existing entities.' It distinguishes from siblings like 'deletecontext' and 'loadcontext' by focusing on creation operations.
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 8 specific use cases (e.g., 'Creating new project components,' 'Establishing relationships between development entities'), plus a 'You should' section with 10 detailed guidelines (e.g., 'Specify the operation type,' 'Ensure entities exist before creating relations'). This provides comprehensive guidance on when and how to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A versatile tool for removing elements from the software development knowledge graph. This tool allows precise deletion of entities, relationships between entities, or specific observations from existing entities. It helps maintain an accurate and current representation of the development context as projects evolve.
When to use this tool:
Removing deprecated or completed project components
Deleting obsolete relationships between development entities
Pruning outdated observations that no longer apply
Correcting errors in the knowledge graph
Cleaning up testing or prototype entities
Maintaining graph accuracy as project scope changes
Removing sensitive or confidential information
Archiving completed projects or components
Removing task sequencing relationships
Updating status or priority relationships
Key features:
Three distinct deletion operation types (entities, relations, observations)
Cascading deletion for entities (automatically removes related relations)
Precise deletion of specific observations without removing entire entities
Targeted relation removal with exact matching on from/to/type
Batch operations for efficient cleanup
JSON-formatted response with operation results
Secure validation before deletion
Parameters explained:
type: The deletion operation type to perform, which must be one of:
"entities" - Remove development entities and their relations
"relations" - Remove specific relationships between entities
"observations" - Remove specific observations from entities
data: Operation-specific data structure:
For "entities": Array of entity names to delete
For "relations": Array of objects with { from, to, relationType }
For "observations": Array of objects with { entityName, observations[] }
Deletion behavior by type:
"entities": Completely removes the specified entities and any relations where they appear
"relations": Removes only the exact relations specified, matching on all three attributes
"observations": Removes specific observations from entities while preserving the entities themselves
Safety considerations:
Entity deletion cascades to relations, so be careful when deleting key entities
There is no "undo" operation, so confirm deletions carefully
Partial graph information can lead to inconsistent views
Relations require entities on both ends to exist
Instead of deleting status or priority entities, prefer updating them using appropriate tools
Deleting task sequencing relations may disrupt project planning and dependencies
You should:
Identify the specific elements that need to be removed
Choose the appropriate deletion type (entities, relations, or observations)
Structure your data according to the deletion type's requirements
Start with the most specific deletions (observations) before broader ones
Verify the entities or relations exist before attempting deletion
To update status or priority, create new has_status or has_priority relations rather than deleting old ones
When removing task sequencing, consider how it affects other tasks and milestones
Check the operation result to confirm successful deletion
Consider documenting major deletions as observations on related entities
When removing an entire project, first delete its components for cleaner removal
| 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' |
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 cascading deletion effects, lack of undo, partial graph implications, relation prerequisites, and specific deletion behaviors for each operation type. The safety considerations section provides critical operational context 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?
While well-structured with clear sections, the description is verbose with 10-item lists in multiple sections. Some redundancy exists (e.g., operation types explained multiple times). The core functionality could be communicated more efficiently while maintaining the valuable safety and usage 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?
For a destructive tool with no annotations and no output schema, the description provides exceptional completeness. It covers purpose, usage scenarios, parameter semantics, behavioral traits, safety considerations, and operational procedures. The absence of output schema is compensated by mentioning 'JSON-formatted response with operation results.'
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 through a dedicated 'Parameters explained' section that clarifies the meaning of 'type' options and provides detailed data structure examples for each operation. It transforms the abstract schema into concrete usage patterns with specific examples for entities, relations, and observations.
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: 'removing elements from the software development knowledge graph' with three specific operation types (entities, relations, observations). It distinguishes itself from siblings like 'buildcontext' and 'loadcontext' by focusing on deletion rather than creation or retrieval.
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 guidance with a dedicated 'When to use this tool' section listing 10 specific scenarios, plus safety considerations and a numbered list of 10 actionable steps. It explicitly advises against using this tool for status/priority updates, directing users to 'appropriate tools' instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A multi-stage tool for documenting development sessions, recording achievements, tracking task progress, and updating project status in the knowledge graph.
When to use this tool: Only use this tool when the user explicity requests it or provides explicit approval.
Key features:
Provides a structured, multi-stage workflow for session documentation
Records session achievements in the knowledge graph
Updates task statuses using the has_status relation (inactive, active, complete)
Updates task priorities using the has_priority relation (low, high)
Updates task sequencing relationships using the precedes relation
Creates links between completed tasks and projects
Updates project status metadata
Creates new tasks for future development
Supports revision of previous stages when needed
Offers a comprehensive assembly stage that consolidates all session information
Organizes development activity into a coherent project history
The endsession tool uses a sequential, multi-stage approach with 6 typical stages:
Summary Stage: Records basic session information
Achievements Stage: Documents specific accomplishments
Task Updates Stage: Records status and priority changes to existing tasks
New Tasks Stage: Defines new tasks created during the session
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 development session
Obtained from the startsession tool
Example: "dev_1234567890_abc123"
stage: Required - Current stage of the endsession workflow
Accepts: "summary", "achievements", "taskUpdates", "newTasks", "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 6 stages
Used to track progress through the session documentation workflow
totalStages: Required - Total number of stages planned for this workflow
Typically 6 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 authentication system"
stageData: Optional - Stage-specific structured data
summary: { summary: "Session summary text", duration: "2 hours", focus: "ProjectName" }
achievements: { achievements: ["Implemented feature X", "Fixed bug Y", "Refactored component Z"] }
taskUpdates: { taskUpdates: [{ name: "Task1", status: "complete" }, { name: "Task2", status: "active", priority: "high" }] }
newTasks: { newTasks: [{ name: "NewTask1", description: "Implement feature A", priority: "high", precedesTask: "Task2" }] }
projectStatus: { projectName: "ProjectName", status: "active", observation: "Making good progress" }
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
Return information:
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
endSessionArgs: (Only in assembly stage) Consolidated arguments for the session
sessionRecorded: (Final stage only) Whether the session was recorded
summaryMessage: (Final stage only) Formatted summary of all recorded information
error: (Only on failure) Error message describing the issue
You should:
Complete all stages in order for comprehensive session documentation
Provide specific details in each stage for accurate knowledge graph updates
Be precise about task names to ensure they match existing tasks in the knowledge graph
Use valid status values (inactive, active, complete) when updating task status
Use valid priority values (low, high) when specifying task priorities
Specify task sequencing with the precedesTask field to establish task dependencies
Use clear, descriptive names for any new tasks
Include relevant observations for project status updates
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
| 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', 'achievements', 'taskUpdates', 'newTasks', 'projectStatus', or 'assembly' | |
| stageData | No | Stage-specific data structure - format depends on the stage type: - For 'summary' stage: { summary: "Session summary text", duration: "2 hours", focus: "ProjectName" } - For 'achievements' stage: { achievements: ["Implemented feature X", "Fixed bug Y", "Refactored component Z"] } - For 'taskUpdates' stage: { taskUpdates: [{ name: "Task1", status: "completed" }, { name: "Task2", status: "in_progress" }] } - For 'newTasks' stage: { newTasks: [{ name: "NewTask1", description: "Implement feature A", priority: "high" }] } - For 'projectStatus' stage: { projectName: "ProjectName", projectStatus: "in_progress", projectObservation: "Making good progress" } - 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) |
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 the multi-stage workflow, revision capabilities, and output structure (e.g., 'success,' 'stageCompleted,' 'summaryMessage'). However, it lacks details on error handling beyond mentioning an 'error' field, and doesn't specify performance characteristics like rate limits or idempotency.
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 front-loaded with a clear purpose and usage guidelines, but becomes overly verbose with detailed lists of features, stages, and parameter explanations that could be condensed. Sentences like 'Organizes development activity into a coherent project history' add minimal value. While structured, it could be more concise 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 complexity (9 parameters, multi-stage workflow, no annotations, no output schema), the description is largely complete. It covers purpose, usage, parameters, and outputs in detail. However, it lacks explicit error scenarios or edge-case handling (e.g., invalid 'stageData' formats), which would enhance robustness for an AI agent.
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%, so the baseline is 3. The description adds significant value by explaining parameter interactions (e.g., 'isRevision' and 'revisesStage' relationship), providing concrete examples for 'stageData' formats, and clarifying usage contexts like 'sessionId' from 'startsession.' This goes beyond the schema's technical definitions to aid practical application.
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 development sessions' with specific verbs like 'recording achievements, tracking task progress, and updating project status in the knowledge graph.' It distinguishes from siblings like 'startsession' by focusing on session conclusion rather than initiation, and from context tools by its session-specific workflow.
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 explicitly states 'Only use this tool when the user explicitly requests it or provides explicit approval' under 'When to use this tool.' It also provides implicit guidance by detailing the 6-stage workflow and recommending completion 'in order for comprehensive session documentation,' helping differentiate it from simpler or single-purpose tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A powerful tool for retrieving rich, contextual information about specific software development entities, providing formatted details based on entity type.
When to use this tool:
Retrieving detailed information about a specific project, component, feature, or other development entity
Exploring relationships between software development entities
Examining project status, components, features, tasks, and issues
Understanding the structure and elements of a software component
Reviewing milestone progress and completion metrics
Examining task details, dependencies, and task sequencing
Exploring feature implementations and technical requirements
Analyzing the project knowledge graph to understand entity relationships
Preparing for work on a specific entity by establishing context
Key features:
Provides contextually rich, formatted information about software development entities
Adapts output format based on entity type (project, component, feature, task, etc.)
Presents both direct entity information and related elements
Organizes information in a clear, hierarchical structure
Automatically identifies entity relationships and presents them systematically
Parameters explained:
entityName: Required - The name of the entity to retrieve context for
Example: "AuthService", "UserProfile", "LoginFeature"
entityType: Optional - The type of entity being retrieved
Default: "project"
Accepted values: "project", "component", "task", "issue", "milestone", "decision", "feature", "technology", "documentation", "dependency", "developer"
Helps the system format the output appropriately
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 status, components, active features, active tasks, active issues, upcoming milestones, team members, recent decisions, and task sequencing information
Component: Displays parent projects, implemented features, technologies used, active issues, documentation, and dependencies
Feature: Shows status, priority, description, requirements, implementing components, and related tasks
Task: Displays project, status, priority, description, related issues, blocking items, preceding tasks, and following tasks
Milestone: Shows status, progress percentage, and tasks grouped by completion status (complete, active, inactive)
Other Entity Types: Shows observations and both incoming and outgoing relationships within the knowledge graph
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
Explore components to understand technical architecture
Examine features to see functional requirements and implementations
Review tasks to understand specific work items and their status
Analyze task sequencing to understand dependencies and workflow
Use status information to focus on active or incomplete work
Consider priority information when planning next steps
Use milestone context to track progress toward completion
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 |
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 explaining key behavioral traits: it's a read-only retrieval tool ('only retrieves existing information'), provides formatted/hierarchical output, adapts based on entity type, and presents relationships. It doesn't mention rate limits, authentication needs, or error conditions, but covers core behavior thoroughly.
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, but overly verbose at ~450 words. Many sentences in the 'You should' section are repetitive (e.g., multiple 'Explore...' items) and could be consolidated. While front-loaded with purpose, it could be more concise without losing value.
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?
For a 3-parameter tool with no annotations and no output schema, the description provides excellent context: clear purpose, detailed usage guidelines, parameter explanations, and behavioral traits. It lacks explicit output format details (though hints at 'formatted' and 'hierarchical'), but given the comprehensive parameter coverage and sibling differentiation, it's nearly complete.
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 explains all 3 parameters: entityName (required, with examples), entityType (optional, default value, accepted values list), and sessionId (optional, purpose, typical source). This adds substantial meaning beyond the bare 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: 'retrieving rich, contextual information about specific software development entities' with 'formatted details based on entity type.' It distinguishes from siblings like buildcontext (adds new entities) and deletecontext (removes entities), making the read-only retrieval purpose explicit.
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 guidance with a dedicated 'When to use this tool' section listing 9 specific scenarios, plus a 'You should' section with 13 actionable recommendations. It explicitly contrasts with buildcontext ('only retrieves existing information') and mentions startsession for session tracking, offering clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A powerful session initialization tool for software development contextual work. This tool starts a new development session and provides a comprehensive overview of the current development landscape. It retrieves recent sessions, active projects, high-priority tasks, and upcoming milestones to help focus the work effectively.
When to use this tool:
Beginning a new development work session
Establishing context before diving into specific development work
Key features:
Generates a unique session identifier for tracking activity
Retrieves and displays recent development sessions
Shows active software development projects (based on has_status relations)
Highlights high-priority tasks (based on has_priority relations)
Lists upcoming project milestones with progress tracking
Displays task dependencies and sequencing information
Parameters explained:
No parameters required - the tool automatically retrieves all relevant context
Return information:
Session ID: A unique identifier for this development session (format: dev_timestamp_randomstring)
Recent Development Sessions: Up to 3 most recent sessions with:
Date
Project focus
Session summary (truncated to 100 characters)
Active Projects: List of active software projects with their status
High-Priority Tasks: Tasks with high priority status (via has_priority relation) including:
Task name
Current status (via has_status relation)
Task sequencing information (preceding and following tasks)
Upcoming Milestones: Milestones with active status including:
Milestone name
Progress percentage based on completed tasks
You should:
Use the generated session ID with the loadcontext tool to load specific entities
End the session with endsession when work is complete
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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: generating a unique session ID, retrieving recent sessions, active projects, high-priority tasks, and upcoming milestones. It also mentions tracking activity and progress, though it lacks details on rate limits, error handling, or authentication needs, which keeps it from a perfect score.
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 this tool,' 'Key features,' 'Parameters explained,' and 'Return information,' making it front-loaded and easy to scan. However, it is slightly verbose with detailed lists in the return section, which could be condensed 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 complexity of the tool (session initialization with multiple data retrievals), no annotations, and no output schema, the description does a good job of covering purpose, usage, features, parameters, and return values. It explains what the tool does and how to use it with siblings, though it could benefit from more behavioral details like error cases or performance expectations.
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 schema has 0 parameters with 100% coverage, so the baseline is 4. The description explicitly states 'No parameters required - the tool automatically retrieves all relevant context,' which adds clarity beyond the schema by confirming the automatic nature of the retrieval, though it doesn't need to explain parameters.
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 'starts a new development session' and 'provides a comprehensive overview of the current development landscape,' which is a specific verb+resource combination. It distinguishes itself from siblings like 'loadcontext' (loads specific entities) and 'endsession' (ends sessions), making the differentiation explicit.
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 explicitly states when to use this tool ('Beginning a new development work session' and 'Establishing context before diving into specific development work') and provides clear guidance on alternatives, such as using 'loadcontext' with the session ID and 'endsession' when work is complete. This covers both usage context and exclusions effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0advancedcontextbuildcontextdeletecontextendsessionloadcontextstartsessionScored across 6 tools
Each tool has a clearly distinct purpose with no overlap: advancedcontext queries, buildcontext creates, deletecontext deletes, endsession documents sessions, loadcontext retrieves single entities, and startsession initializes sessions. The descriptions reinforce distinct roles, making misselection unlikely.
All tool names follow a consistent verb_noun pattern (e.g., advancedcontext, buildcontext, deletecontext, endsession, loadcontext, startsession). The naming is uniform and predictable, enhancing usability and clarity.
With 6 tools, the set is well-scoped for managing a software development knowledge graph. Each tool serves a specific, necessary function (query, create, delete, session management, retrieve, initialize), and no tool feels redundant or missing for the domain.
The toolset provides complete CRUD/lifecycle coverage for the domain: advancedcontext for querying, buildcontext for creation, deletecontext for deletion, loadcontext for retrieval, and startsession/endsession for session management. There are no obvious gaps, enabling agents to handle all core workflows effectively.
Intelligent context infrastructure for AI teams: knowledge graph, sessions, tasks, documents.
Shared project context for AI agents and teams: docs, tasks, and messages that stay current.
Save and retrieve your chosen context, manage shared workspaces, and track project time.
Codebase graphs, caller impact analysis, and recorded project context for AI coding agents.
