Skip to main content
Glama
BezaCore-Labs

never4ga-mcp

Official
by BezaCore-Labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

never4ga_checkpoint

Record what a session has done in runtime state without touching the vault, so progress, decisions, and actions are logged for wrap-up.

Instructions

Record what this session has done so far. Runtime state only: it never touches the vault, so an interruption cannot leave half a log behind.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteYesWhat happened, briefly.
workNoA work item that may need an update. Reported at wrap, never acted on: act with never4ga_work_update or never4ga_work_comment, passing this session_id so wrap sees it was done.
actionsNoA durable thing that happened.
contextNoA context document this session changed something in, by id or vault path, as '<ref>: what changed'. Update the document itself: wrap reports one whose content did not move.
memoriesNoSomething worth remembering.
decisionsNoSomething decided, to be reported at wrap.
session_idYesThe id context_startup returned.
walkthroughsNoA phase walkthrough this session wrote a step into, by id or vault path, as '<ref>: step N'. Write the step itself: wrap reports one whose content did not move.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / walkthroughs
      Added value: +{
+  "description": "A phase walkthrough this session wrote a step into, by id or vault path, as '<ref>: step N'. Write the step itself: wrap reports one whose content did not move.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  2. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and does disclose one genuinely non-obvious trait: it is runtime-only, never touches the vault, and cannot leave a partial log on interruption. That is valuable, but it says nothing about required session state, what the checkpoint reports back, or how recorded items flow into wrap.

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 short sentences with zero waste. The core action is front-loaded and the atomicity guarantee follows immediately as supporting context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an eight-parameter tool with no output schema, the description covers the key safety property but omits what happens after recording and how these entries surface at wrap. The rich per-parameter schema descriptions compensate substantially, keeping this at a minimum-viable level rather than inadequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and each of the eight parameters carries a detailed description in the schema itself, so the baseline of 3 applies. The prose adds no parameter-level syntax or meaning beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

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

States a specific verb and resource: recording what the session has done so far. It is clear this is an incremental checkpoint rather than a finalization, but it never names or contrasts against siblings like never4ga_wrap or never4ga_capture, so differentiation is left to inference from the name.

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

Usage Guidelines3/5

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

'What this session has done so far' implies a mid-session, incremental recording moment, but there is no explicit when-to-use or when-not guidance and no routing to never4ga_wrap for the final summary. Usage is implied rather than stated.

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

Deploy Server

Other Tools