Skip to main content
Glama

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
}

Tools

Functions exposed to the LLM to take actions

NameDescription
derive_route_shardA

Derive the ROUTE_SHARD / intent shard for an authority: SHA-256 of the exact authority string, first 16 bytes, lowercase hex. Deterministic, offline, action-independent (SPEC sec. 3). No lookup, no registry, no network call.

parse_envelopeA

Structural decode of one AE-128 attestation envelope (128 bytes, hex). No organ key needed. Fails closed on every layout rule of the companion draft sec. 2/sec. 4 -- malformed input is never normalised into a partial result.

verify_envelopeA

Full AE-128 verification (companion draft sec. 4): constant-time HMAC-SHA256 over the whole 128-byte frame with the attestation field zeroed, plus the optional lease check. organ_key is the organ's shared test/deployment key (this server is stateless and stores nothing). REJECT is a result, not an error: a flipped byte anywhere breaks the MAC.

published_vectorA

Return AE128-VECTOR-1, the published conformance vector (companion draft sec. 6): the example authority, the documented test organ key, the lease, and the full 128-byte frame as hex. Feed these into verify_envelope and you must get [PASS] -- byte for byte, offline.

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 4 tools

Disambiguation4/5

The four tools have largely distinct purposes: derive_route_shard computes a shard, parse_envelope does structural decoding, verify_envelope does cryptographic verification, and published_vector returns a test fixture. parse_envelope and verify_envelope both operate on the same 128-byte envelope, which could momentarily confuse an agent, but the descriptions clearly separate 'structural, no key' from 'HMAC verification with organ_key'.

Naming Consistency4/5

Three tools follow a clean verb_noun snake_case pattern (derive_route_shard, parse_envelope, verify_envelope) with consistent imperative verbs. The fourth, published_vector, is a noun phrase rather than a verb_phrase, a minor deviation from the otherwise predictable convention.

Tool Count4/5

Four tools is a tight, well-scoped surface for a narrow cryptographic verification domain (derive, parse, verify, plus a self-test vector). It leans slightly thin, but each tool clearly earns its place with no redundancy.

Completeness4/5

The surface covers the full verify-a-lifecycle: deriving the intent shard, decoding the envelope, verifying it, and a published conformance vector for offline self-testing. The main gap is the absence of an encode/build or key-generation counterpart, though that may be intentionally out of scope for a stateless verifier.

Maintenance

ActivityMaintained
ResponsivenessNo issues