http-semantics-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
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.
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.
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.
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.