bokken
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ANTHROPIC_API_KEY | Yes | Your Anthropic API key for model access |
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 |
|---|---|
| create_session_toolB | Create a Design Thinking session. The brief needs problem_space, target_segments, success_criteria, risk_tolerance, and may declare inputs (repo path, metrics/discussion/document files). Input paths are resolved on the server and confined to the authorized input root(s): traversal, escaping symlinks, and outside absolute paths are refused. |
| run_sessionB | Advance the session to its next halt (gate, input, stop, or completion). Completed runs are finalized automatically: Dossier, then handoff specs. |
| step_sessionB | Advance the session by at most one stage. |
| stop_sessionA | Stop the run (journaled human-initiated stop); the session stays resumable. |
| get_statusC | Where the session is and what blocks progress. |
| list_sessions_toolA | List sessions in the workspace. |
| resolve_gateB | Approve or reject the pending gate (rejection requires a reason). |
| request_loopbackC | Loop back to an earlier stage (test->define, test->empathize, define->empathize). |
| submit_inputC | Answer the session's pending Founder-mode question, then run_session again. The answer is attributed to this client's handshake identity, so the engine
that consumes it journals agent-supplied ( |
| query_journalB | Read ledger events with the same filters and canonical form as the CLI. |
| generate_handoffA | Generate OpenSpec MVP specifications for the validated concept, ready to be ingested by a coding harness (refused for killed concepts). |
| generate_dossierC | Generate the Session Dossier and return the export paths. |
| export_reportB | Export the run report (PPTX deck + self-contained HTML) and return the paths. |
| cost_reportC | Cost report from the journaled model calls (list-price estimate, cache hit rate). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| sessions_resource |
TDQS
Scored across 14 tools
Most tools target distinct actions and resources, but run_session and step_session both advance a session and could be confusable depending on intent. get_status and query_journal also overlap somewhat as read-only status/history surfaces, though their descriptions clarify the difference.
The set mostly follows a verb_noun pattern (run_session, stop_session, resolve_gate, generate_handoff), but cost_report is a noun-style command and list_sessions_tool/create_session_tool carry a _tool suffix not present elsewhere. These are minor deviations rather than a systemic naming problem.
14 tools is well-scoped for a Design Thinking session management server. Each tool maps to a meaningful lifecycle action or output, and there is no obvious redundancy or bloat.
The surface covers session creation, status, advancement, stopping, gates, loopbacks, journaling, reporting, and final handoff generation. Minor gaps exist, such as no explicit session update/delete or single-session detail tool, but the core workflows have no dead ends.