Skip to main content
Glama
oaslananka
by oaslananka

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
MCP_PROFILENofull, remote-safe, chatgpt, or claudefull
INFRA_LENS_DBNoSQLite database path~/.infra-lens-mcp/metrics.db
MCP_HTTP_HOSTNoHTTP bind host. HOST remains a deprecated alias127.0.0.1
MCP_HTTP_PORTNoHTTP bind port. PORT remains a deprecated alias3000
MCP_HTTP_AUTH_MODENonone, bearer, or oauth-gateway; oauth is accepted as a compatibility aliasnone
MCP_SSH_KNOWN_HOSTSNoKnown hosts file~/.ssh/known_hosts
MCP_HTTP_BEARER_TOKENNoLocal/dev bearer fallback tokenunset
MCP_SSH_ALLOWED_HOSTSNoExact host/IP or IPv4 CIDR allowlist; required for remote-safe profiles and enforced in full profile when setunset
MCP_SSH_ALLOWED_PORTSNoOptional comma-separated SSH port allowlistunset
MCP_SSH_ALLOWED_USERSNoOptional comma-separated SSH username allowlistunset
MCP_HTTP_ALLOWED_HOSTSNoComma-separated allowed Host valuesunset
MCP_HTTP_ENDPOINT_PATHNoCanonical Streamable HTTP MCP endpoint path/mcp
MCP_HTTP_ALLOWED_ORIGINSNoComma-separated allowed Origin valuesunset
INFRA_LENS_RETENTION_DAYSNoSnapshot retention in days; 0 disables automatic pruning30
MCP_HTTP_BODY_LIMIT_BYTESNoMaximum JSON request body size1048576
MCP_HTTP_REQUEST_TIMEOUT_MSNoMaximum time to receive and handle an HTTP request before the socket is closed30000
MCP_SSH_STRICT_HOST_CHECKINGNoStrict host key verification toggletrue
MCP_HTTP_OAUTH_GATEWAY_HEADERNoHeader injected by a trusted OAuth gatewayx-infra-lens-gateway-auth
MCP_HTTP_OAUTH_GATEWAY_SECRETNoShared backend secret required for oauth-gateway modeunset
MCP_SSH_MAX_SESSIONS_PER_HOSTNoOptional active SSH session cap per host:port; 0 disables it0
MCP_HTTP_AUTHORIZATION_SERVERSNoOAuth authorization server metadata URLsunset
MCP_HTTP_RATE_LIMIT_PER_MINUTENoOptional per-client in-memory rate limit; 0 disables it0
MCP_HTTP_MAX_CONCURRENT_REQUESTSNoMaximum concurrent HTTP requests accepted by the Node process100
MCP_SSH_MAX_CONNECTION_ATTEMPTS_PER_MINUTENoOptional SSH connection-attempt cap per host:port per minute; 0 disables it0

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
}
logging
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
analyze_serverB

Collect metrics from a server and explain any anomalies in human language

snapshotB

Collect and save current server metrics without analysis

record_baselineA

Record current metrics as baseline during normal operation for more accurate anomaly detection later

compare_to_baselineB

Compare current server state to a recorded baseline and explain the differences

get_historyB

Get historical CPU, memory, or load values for a server

inspect_host_capabilitiesB

Check whether a Linux host supports infra-lens collection

plan_remediationA

Collect a current read-only snapshot and produce approval-required remediation guidance without executing changes

draft_incident_reportB

Create a review-first incident report and postmortem draft from persisted observations

compare_incident_windowsA

Compare adjacent time windows for one host or the same recent window across two hosts

analyze_server_snapshotC

Collect one immediate server snapshot, analyze it, and persist the completed observation without a sampling delay

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3.4/5.0

Scored across 10 tools

Disambiguation3/5

Several tools have overlapping purposes, especially analyze_server and analyze_server_snapshot which both collect and analyze metrics with subtle differences in timing and persistence. snapshot and analyze_server_snapshot also share collection behavior, while compare_to_baseline and compare_incident_windows both perform comparisons in different contexts. Descriptions provide some clarity, but boundaries are not always obvious.

Naming Consistency4/5

Most tool names follow a verb_noun pattern (analyze_server, record_baseline, compare_to_baseline, get_history, inspect_host_capabilities, plan_remediation, draft_incident_report, compare_incident_windows). However, 'snapshot' is a bare noun, and 'analyze_server_snapshot' diverges from the simpler 'analyze_server' pattern, introducing minor inconsistency.

Tool Count5/5

With 10 tools, the server covers monitoring, baselining, comparison, history, remediation, and incident reporting without feeling bloated. Each tool addresses a distinct aspect of the infrastructure analysis workflow, and the count is well within the ideal range.

Completeness4/5

The tool set covers the core lifecycle of server monitoring: collection, analysis, baseline recording/comparison, historical lookup, host capability checks, remediation planning, and incident reporting. Minor gaps exist, such as no explicit tools to list or delete saved baselines or snapshots, but these do not cripple the main workflows.

Maintenance

ActivitySlowing
ResponsivenessResponsive