Skip to main content
Glama

board_end_session

End the current session with a progress summary and handoff notes, ensuring that completed work and pending tasks are visible to the next session for continuity.

Instructions

End the current session with a progress summary and handoff notes. This is the single most important call for cross-session continuity — without it, everything you did this session is invisible to the next one. Marks the session status='completed' and sets ended_at=now. The next board_create_session will surface this session's progress_summary, handoff_notes, and context_artifacts in its handoff response. Reference specific task IDs in handoff_notes (the next session reads this as prose, not a parsed list). Returns { session_id, status, message }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
session_idYesSession ID to end (the session_id returned from board_create_session at the start of this session)
progress_summaryYes1-3 sentences on what was accomplished this session. Shown verbatim at the start of the next session's handoff.
handoff_notesNoProse notes for the next session — reference task IDs for pending work ('task X is blocked on Y'), not vague descriptions. What the next agent needs to know to continue.
context_artifactsNoStructured context. Recognized keys: files_modified (paths touched), decisions_made (choices that set direction), blockers (what stopped progress), next_steps (what the next session should do). Additional keys allowed — passthrough.

Implementation Reference

  • The 'board_end_session' tool handler implementation. Defines the tool with schema (session_id required, progress_summary, handoff_notes, context_artifacts options), updates the session document to 'completed' status, logs to activity_log, and returns session_id/status/message.
    server.tool(
      "board_end_session",
      "End the current session with a progress summary and handoff notes. This is the single most important call for cross-session continuity — without it, everything you did this session is invisible to the next one. Marks the session status='completed' and sets ended_at=now. The next board_create_session will surface this session's progress_summary, handoff_notes, and context_artifacts in its handoff response. Reference specific task IDs in handoff_notes (the next session reads this as prose, not a parsed list). Returns { session_id, status, message }.",
      {
        session_id: z.string().describe("Session ID to end (the session_id returned from board_create_session at the start of this session)"),
        progress_summary: z
          .string()
          .describe("1-3 sentences on what was accomplished this session. Shown verbatim at the start of the next session's handoff."),
        handoff_notes: z
          .string()
          .optional()
          .describe("Prose notes for the next session — reference task IDs for pending work ('task X is blocked on Y'), not vague descriptions. What the next agent needs to know to continue."),
        context_artifacts: z
          .object({
            files_modified: z.array(z.string()).optional(),
            decisions_made: z.array(z.string()).optional(),
            blockers: z.array(z.string()).optional(),
            next_steps: z.array(z.string()).optional(),
          })
          .passthrough()
          .optional()
          .describe("Structured context. Recognized keys: files_modified (paths touched), decisions_made (choices that set direction), blockers (what stopped progress), next_steps (what the next session should do). Additional keys allowed — passthrough."),
      },
      async ({ session_id, progress_summary, handoff_notes, context_artifacts }) => {
        const sessionRef = db.collection("sessions").doc(session_id);
        const sessionSnap = await sessionRef.get();
    
        if (!sessionSnap.exists) {
          return {
            content: [
              {
                type: "text" as const,
                text: JSON.stringify({ error: `Session ${session_id} not found` }),
              },
            ],
          };
        }
    
        const now = Timestamp.now();
        await sessionRef.update({
          status: "completed",
          ended_at: now,
          progress_summary,
          handoff_notes: handoff_notes ?? null,
          context_artifacts: context_artifacts ?? {},
        });
    
        await db.collection("activity_log").add({
          task_id: null,
          session_id,
          agent_name: "system",
          action: "session_ended",
          details: progress_summary,
          metadata: {},
          created_at: now,
        });
    
        return {
          content: [
            {
              type: "text" as const,
              text: JSON.stringify(
                {
                  session_id,
                  status: "completed",
                  message: "Session ended successfully. Handoff notes saved.",
                },
                null,
                2
              ),
            },
          ],
        };
      }
    );
  • Input schema for board_end_session: session_id (string), progress_summary (string), handoff_notes (optional string), and context_artifacts (optional object with files_modified, decisions_made, blockers, next_steps arrays plus passthrough).
    {
      session_id: z.string().describe("Session ID to end (the session_id returned from board_create_session at the start of this session)"),
      progress_summary: z
        .string()
        .describe("1-3 sentences on what was accomplished this session. Shown verbatim at the start of the next session's handoff."),
      handoff_notes: z
        .string()
        .optional()
        .describe("Prose notes for the next session — reference task IDs for pending work ('task X is blocked on Y'), not vague descriptions. What the next agent needs to know to continue."),
      context_artifacts: z
        .object({
          files_modified: z.array(z.string()).optional(),
          decisions_made: z.array(z.string()).optional(),
          blockers: z.array(z.string()).optional(),
          next_steps: z.array(z.string()).optional(),
        })
        .passthrough()
        .optional()
        .describe("Structured context. Recognized keys: files_modified (paths touched), decisions_made (choices that set direction), blockers (what stopped progress), next_steps (what the next session should do). Additional keys allowed — passthrough."),
    },
  • The registration function 'registerSessionTools' is exported from sessions.ts and called in index.ts line 30 with the MCP server and Firestore db.
    export function registerSessionTools(server: McpServer, db: Firestore) {
Behavior4/5

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

With no annotations provided, the description fully explains behavioral traits: marks session as 'completed', sets ended_at=now, and how the next session surfaces this session's data. It also specifies the return format. It could mention if the session can be reactivated or if ending is irreversible, but is sufficiently transparent.

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

Conciseness4/5

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

The description is 5 sentences, each adding value. It is front-loaded with the most important point. Could be slightly more concise, but no extraneous information. Good structure.

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 no output schema, the description explains the return shape. It integrates well with sibling tools (board_create_session). It documents required parameters and complex nested objects. Lacks error conditions or edge cases (e.g., ending already ended session), but is largely complete.

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 coverage is 100%, so baseline is 3. The description adds value beyond schema: for handoff_notes it advises referencing task IDs and notes that the next session reads it as prose; for context_artifacts it explains recognized keys and that additional keys are passthrough. This helps the agent use parameters correctly.

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 ends the current session with a progress summary and handoff notes, and emphasizes its critical role in cross-session continuity. It distinguishes itself from siblings like board_create_session (which starts a session) and board_get_handoff (which retrieves handoff data).

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

Usage Guidelines4/5

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

The description explicitly says this call is essential for cross-session continuity and that without it, session work is invisible to the next one. It provides guidance on when to use it (at session end) and what to include (reference task IDs in handoff_notes). It does not explicitly state when not to use alternatives, but the context makes it clear.

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

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/HuntsDesk/ve-vibe-board'

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