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": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
pingB

Check whether the MCP server is responsive.

protocol_ping_livenessC

Send an MCP protocol ping during this in-flight call and apply a bounded liveness policy.

delayA

Delay a successful MCP response to test client timeout behavior.

hangB

Never respond unless the MCP request is cancelled.

disconnectA

Close the MCP transport before this request can receive a response.

malformed_messageC

Return one deterministic response that violates a selected JSON-RPC rule.

duplicate_responseB

Return the same JSON-RPC response twice for this request.

response_after_cancellationA

Send a response after this call is cancelled (stdio only).

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3.2/5.0

Scored across 8 tools

Disambiguation4/5

Most tools target distinct failure modes (delay, hang, disconnect, malformed_message, duplicate_response, response_after_cancellation). Only ping and protocol_ping_liveness overlap somewhat as both concern liveness, but their descriptions differentiate normal responsiveness from protocol-level in-flight liveness.

Naming Consistency3/5

All names are lowercase snake_case, but the set mixes bare verbs (ping, delay, hang, disconnect) with descriptive noun/adjective phrases (protocol_ping_liveness, malformed_message, duplicate_response, response_after_cancellation). This is readable but not a single predictable pattern.

Tool Count5/5

Eight tools is well-scoped for a failure-injection lab. Each tool represents a distinct failure scenario or liveness check, so none feel redundant or out of place.

Completeness4/5

The set covers common failure modes: timeout/delay, hang, disconnect, malformed protocol messages, duplicate responses, and post-cancellation responses. Minor gaps remain, such as a valid JSON-RPC error response tool or out-of-order response injection, but core failure-lab needs are met.

Maintenance

ActivityActive
ResponsivenessWithin a week