two-minds-one-lock
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TRACER_LOCK_LENGTH | No | Lock code length (default likely 4). | |
| TRACER_LOCK_ALPHABET | No | Alphabet of glyphs used in the lock. | |
| TRACER_LOCK_MAX_ATTEMPTS | No | Maximum number of attempts before lockout. |
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
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| observe_systemA | Read the lock before acting: the glyph alphabet, the code length, your remaining attempt budget, the diagnostics legend, and your probe history. Call this first -- it costs nothing. |
| probeA | Reconnaissance. Test a candidate code -- a string of glyphs from the alphabet, exactly code_length long. Returns ALIGNED (correct glyph in the correct slot) and DISPLACED (correct glyph in the wrong slot) counts. Costs one attempt. A probe NEVER opens the lock; it only gathers information. Probe to deduce the secret. |
| submit_solutionA | Commit to a final answer. Opens the lock if 'answer' is exactly the secret code; otherwise costs one attempt and returns only a rejection -- no diagnostics. Submitting before you have deduced the code wastes the budget. Probe first; submit once confident. |
| get_statusA | Lightweight check: attempts remaining, whether you are locked out, whether the lock is open, and how many probes/submits you have spent. |
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 4 tools
observe_system and get_status overlap heavily: both report attempts remaining and probe history. While observe_system is more comprehensive, the redundancy could cause an agent to pick the wrong one. probe and submit_solution are clearly distinct.
Most tools follow a verb_noun pattern (observe_system, submit_solution, get_status), but probe is a bare verb without an explicit object. The style is consistent with snake_case lowercase.
Four tools is a well-scoped set for a simple lock-deduction game, covering reconnaissance, probing, solution submission, and status checking.
The tool surface covers the full gameplay loop: observe the system, probe candidates, submit the solution, and check status. No obvious missing operations.