Skip to main content
Glama

Start Session

kg_session_start

Start a working-memory session before creating nodes or edges, applying decay to existing usage scores and optionally creating the named project if it does not exist.

Instructions

Start a new working-memory session. Required before creating nodes or edges. Applies decay to the usage-based scores of existing nodes (node content is not changed), and can optionally create the named project (plus the default workspace records on first use) if it does not exist.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesNoSession notes
projectNoProject to scope the session to
create_projectYesCreate the project if it does not exist

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Discloses side effects not captured by annotations: decay applied to usage-based scores of existing nodes (while content is unchanged) and optional creation of the project plus default workspace records on first use. This is exactly the mutation context the false destructiveHint cannot convey.

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

Conciseness5/5

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

Two tight sentences, front-loaded with the primary action and precondition, then side effects. No wasted text.

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?

Covers preconditions, side effects, and project creation for a 3-param tool with annotations. Minor gap: with no output schema, it doesn't indicate what a started session returns (e.g., a session handle), which would help the agent use the result.

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, but the description adds meaning beyond the schema for create_project — explaining it creates the project and default workspace records on first use. Notes and project params rely on the schema.

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?

States a specific verb ('Start') and resource ('working-memory session'), plus the key precondition that it's required before creating nodes or edges. Distinct from siblings like kg_session_end and kg_session_info.

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?

'Required before creating nodes or edges' gives clear when-to-use context. It doesn't explicitly name alternatives like kg_session_end, but the precondition makes the selection obvious.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.