Skip to main content
Glama
tejpalvirk

Developer MCP Server

by tejpalvirk

endsession

Documents development sessions by recording achievements, tracking task progress, updating project status, and creating new tasks in a structured six-stage workflow for the knowledge graph.

Instructions

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:

  1. Summary Stage: Records basic session information

  2. Achievements Stage: Documents specific accomplishments

  3. Task Updates Stage: Records status and priority changes to existing tasks

  4. New Tasks Stage: Defines new tasks created during the session

  5. Project Status Stage: Updates the overall project status

  6. 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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
analysisNoText analysis or observations for the current stage
isRevisionNoWhether this is revising a previous stage
nextStageNeededYesWhether additional stages are needed after this one (false for final stage)
revisesStageNoIf revising, which stage number is being revised
sessionIdYesThe unique session identifier obtained from startsession
stageYesCurrent stage of analysis: 'summary', 'achievements', 'taskUpdates', 'newTasks', 'projectStatus', or 'assembly'
stageDataNoStage-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
stageNumberYesThe sequence number of the current stage (starts at 1)
totalStagesYesTotal number of stages in the workflow (typically 6 for standard workflow)
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes 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.

Conciseness3/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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

The description clearly states the tool's purpose as a 'multi-stage tool for documenting 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.

Usage Guidelines5/5

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.

Install Server

Other Tools

Related Tools

Latest Blog Posts

MCP directory API

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

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

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