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
}

Tools

Functions exposed to the LLM to take actions

NameDescription
cache_evaluateA

Decide whether a stored response may be reused without revalidating. Applies the RFC 9111 age and freshness arithmetic (Date, Age, Cache-Control, Expires, Last-Modified) and returns action serve|revalidate|miss, the age and freshness lifetime in whole seconds, and the rule IDs with their clause references. now is an argument: the cache never reads a clock.

conditional_evaluateA

Judge one request's preconditions and report the status they decide. Evaluates If-Match, If-Unmodified-Since, If-None-Match and If-Modified-Since in the RFC 9110 section 13.2.2 precedence order, stopping at the first applicable one, and returns status 200|304|412, which rule decided it, and the rule IDs with their clause references.

cors_evaluateA

Judge one HTTP response against the Fetch Standard CORS check. Returns decision allow|block, the violated rule IDs with their clause references, the headers that are missing, and what to send instead. No network: url is parsed for scheme/host/port only.

cors_simulate_fetchB

Walk a redirect chain hop by hop and judge each hop with the CORS check. Reports the ordered redirect events (origin_set_to_null, credentials_dropped), the visible response headers, and the effective Access-Control-Max-Age.

vary_matchB

Decide whether a stored response can be reused for an incoming request, per RFC 9111 section 4.1. Compares the fields named by the stored Vary value under that field's normalisation policy and returns match hit|miss, the fields that differ, the normalised Vary members, and the rule IDs with their clause references.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.7/5.0

Scored across 5 tools

Disambiguation4/5

Most tools target clearly distinct HTTP semantics concerns (cache freshness, Vary matching, conditional preconditions, CORS). The two CORS tools (cors_evaluate for a single response, cors_simulate_fetch for a redirect chain) and the two cache-related tools (cache_evaluate for freshness, vary_match for field matching) are related but their scopes are differentiated in the descriptions.

Naming Consistency4/5

All names use snake_case with a domain_prefixed convention (cors_*, cache_*, conditional_*, vary_match). Mostly consistent, though cors_simulate_fetch breaks the domain_action pattern slightly with an extra verb.

Tool Count5/5

Five focused tools are well-scoped for a narrow HTTP semantics/RFC-conformance evaluator, with no redundant or filler entries. Each tool earns its place.

Completeness4/5

The set covers the core RFC 9111 cache reuse path (freshness + Vary), RFC 9110 preconditions, and CORS including redirects, which is solid coverage. Minor gaps exist (e.g., no explicit cache storage/no-store decision or combined end-to-end request evaluation), but agents can work around them.

Maintenance

ActivityMaintained
ResponsivenessNo issues