Skip to main content
Glama
holeyfield33-art

Aletheia Token Guard (ATG)

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
check_usageA

Pre-work / mid-work usage check.

Preferred path: pass the raw provider response headers dict and the platform name; ATG will parse rate-limit fields. Alternatively pass remaining_tokens / remaining_requests explicitly (host-extracted).

platform should name the actual provider ("openai" or "anthropic") when headers is supplied — an omitted/unrecognized platform merges both parsers instead of guessing OpenAI, so real Anthropic headers are never silently misread as "no limit data" (which would report a false proceed on an exhausted budget).

If neither headers nor remaining_* are provided, returns a neutral proceed signal so agents do not block.

save_checkpointA

Save a durable checkpoint for work_id.

meta is a free-form bag — useful for Horos receipt_hash or Mneme memory keys. JSON fields are capped (~512 KB); store large blobs externally.

load_checkpointB

Load the latest in-progress checkpoint for work_id.

list_checkpointsB

List incomplete work items (limit clamped to 1–500).

mark_doneA

Mark all in-progress checkpoints for work_id as done.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clear, singular responsibility: usage checking, checkpoint persistence, resume, listing, and completion. Even the related save/load/list checkpoint tools are easy to distinguish by their action and return value.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun convention: check_usage, save_checkpoint, load_checkpoint, list_checkpoints, mark_done. The pattern makes behavior predictable and easy to infer.

Tool Count5/5

Five tools is well-scoped for a focused guard/checkpoint server. Each tool addresses a distinct step in the pre-work, mid-work, resume, and completion lifecycle without unnecessary overlap.

Completeness4/5

The core workflow is covered: usage check, checkpoint save/load, incomplete work listing, and completion marking. A minor gap is the lack of an explicit checkpoint delete/abort operation for abandoned work, but this does not create a dead end for the primary use case.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive