Skip to main content
Glama
Sign In
context-harness

context-harness

by dimqsh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

checkpoint

Retrieve the current task state (criteria, latest reports, budget) so coding agents can resume interrupted work.

Instructions

Current task state for resuming: criteria, latest reports, budget.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "checkpoint"
  }
}

Input Schema

NameRequiredDescriptionDefault
taskNo
projectNoAbsolute project root (once per session is enough)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. The name 'checkpoint' is ambiguous about read vs. write, and the description says nothing about side effects, persistence, permissions, or whether calling it mutates state. It does not resolve the ambiguity.

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?

A single short, front-loaded fragment with no wasted words, but it is under-specified rather than genuinely concise, leaving core questions (verb, side effects, scoping) unanswered.

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

Completeness2/5

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

With no annotations, no output schema, and only partial parameter coverage, the description should do more work. It hints at returned fields but omits the operation type, scoping behavior, and any behavioral constraints, leaving the definition inadequate for a 2-param resumable-state tool.

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

Parameters2/5

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

Two parameters at 50% schema coverage: 'project' is documented in-schema but 'task' is not. The description never mentions either input, instead listing returned content (criteria, reports, budget), so it adds no meaning about how task/project scope the result.

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

Purpose3/5

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

The description names the resource (current task state) and enumerates its contents (criteria, latest reports, budget), so an agent can infer it returns resumable state. However, there is no clear verb (get? write? update?) and nothing distinguishes it from siblings like 'report' or 'remember', which could also surface state.

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

Usage Guidelines2/5

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

The only usage signal is the phrase 'for resuming', which hints at a scenario but never states when to prefer this over 'report', 'search', or 'remember'. No exclusions, prerequisites, or alternatives are given.

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