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

Tools

Functions exposed to the LLM to take actions

NameDescription
begin_engagementC

Register scope, rate limits, and proof flags for one engagement.

draft_wavesA

Propose probe_alive then template_scan waves without executing them.

execute_waveC

Run one admitted wave behind the per-host token bucket.

query_cardsB

Return hunter-relevant cards. Informational and hardening are hidden by default.

second_lookC

Re-run a bounded template scan on a single card URL.

state_impactC

Record hunter impact_class and preconditions on a card.

draft_proofD

Describe an allowlisted proof without sending traffic.

execute_proofC

Run an allowlisted proof. Requires allow_safe_proof and operator_confirmed.

engagement_healthC

Report registered engagements, cooldowns, and pending waves.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

C2.9/5.0

Scored across 9 tools

Disambiguation5/5

Each tool targets a distinct resource and action: engagements, waves, proofs, and cards are cleanly separated. The two execute tools are disambiguated by proof vs wave, and the two draft tools by waves vs proof, so an agent should not confuse them.

Naming Consistency4/5

Most tools follow a clear verb_noun snake_case pattern like execute_proof, begin_engagement, draft_waves, and query_cards. engagement_health and second_look break the pattern by using noun phrases, but the overall convention remains readable and predictable.

Tool Count5/5

Nine tools is a well-scoped size for this domain, covering engagement setup, wave and proof execution, and card interaction without unnecessary redundancy or bloat.

Completeness3/5

The core loop is represented, but there is no explicit admission step for drafted waves before execute_wave, and engagements lack update/close lifecycle operations. These are notable workflow gaps that could stall end-to-end operations.

Maintenance

ActivityMaintained
ResponsivenessNo issues