bokken

by maglionejm

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation4/5
Most tools target distinct actions, but run_session and step_session both advance the session and could easily be confused by an agent. The other tools are clearly separated by their resource or artifact.
Naming Consistency4/5
Names mostly follow a clear snake_case verb_noun pattern, but create_session_tool and list_sessions_tool awkwardly include the _tool suffix while their peers do not. This is a minor deviation rather than a systematic inconsistency.
Tool Count5/5
Twelve tools is well-scoped for a session management server. Each tool covers a meaningful part of the lifecycle without redundancy or bloat.
Completeness4/5
The server covers session creation, advancement, stopping, status, gates, loopback, input submission, and artifact generation. Minor gaps exist around explicit session deletion or an obvious resume action, but core workflows are well covered.
Average 3.2/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 12 commits in the last 12 weeks
- Last stable release on August 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states the backward move and allowed stage pairs, without explaining side effects on the current session, whether prior work is preserved, or how the loopback request is resolved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with the action front-loaded and a dense transition list. It is concise and free of filler, though it is terse enough that it under-serves the required parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing tool with no annotations and no output schema, this description is incomplete. It identifies allowed transitions but leaves required parameters unexplained, effects unspecified, and sibling-tool relationships unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mildly hints at valid values for to_stage through the examples. It provides no meaning for the required name and reason parameters, leaving an agent unable to construct a correct call confidently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Loop back to an earlier stage') and enumerates allowed transitions (test->define, test->empathize, define->empathize), which clarifies what the tool does. It does not explicitly distinguish itself from siblings like step_session or resolve_gate, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus siblings such as step_session or submit_input. The transition list implies it is for backward movement, but there are no exclusions, triggers, or alternative-routing instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only reveals that a dossier is generated and paths are returned. It does not disclose side effects, whether it mutates session state, idempotency, required permissions, or what 'export paths' refer to.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that leads with the action and immediately states the return value. There is no filler or redundant restatement of structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool this might be close, but with no output schema, no annotations, and no naming context for the parameter, the description leaves too much for the agent to infer: what a Session Dossier is, what the name refers to, and what happens to the session.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The lone parameter 'name' is listed in the schema but the description adds no meaning to it; there is 0% schema coverage. It is not clear whether 'name' is the dossier name, session name, or export prefix, making the parameter under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete action ('Generate'), a specific resource ('the Session Dossier'), and the expected result ('return the export paths'). It does not, however, explicitly differentiate this from the sibling generate_handoff, which an agent might confuse it with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to call generate_dossier versus run_session, generate_handoff, or other siblings. The description gives no context, prerequisites, or exclusions, so an agent must infer usage from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only observation ('where the session is') and adds that the tool surfaces blocking issues. But it doesn't explicitly state side-effect freedom, required permissions, or behavior when the named session doesn't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded, and avoids filler. It could be slightly more complete as a full sentence with an explicit verb, but as written it is economical and not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, a single undocumented required parameter, and only a ten-word description, the agent has too little to reliably invoke the tool. The description conveys the concept of status/blockers but not the calling contract. The sibling list provides surrounding context, but the description itself remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, 'name', with no description and 0% schema deck cover. The tool description never directly explains what 'name' should be, though the word 'session' implies it is a session identifier. Valid sources for the name and format are left unstated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says what get_status reports: the session's current position and what blockers are present. It is clear enough to distinguish from action-oriented siblings like run_session and step_session. However, it doesn't differentiate from list_sessions_tool, which may also surface session state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to call this tool versus list_sessions_tool, resolve_gate, or step_session. There are no stated prerequisites, such as the session needing to exist or be running. Usage is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It does communicate that the operation is a read and that output follows a 'canonical form', which is useful. However, it does not explain pagination, ordering, error behavior, filtering semantics, or whether since_seq/limit behave as expected. The CLI reference is opaque without additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every phrase—'Read', 'ledger events', 'same filters', 'canonical form'—contributes meaning. This is appropriately terse for the dimension, though the terseness hurts completeness elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters, an output schema, and no annotations, yet the description provides almost no parameter semantics, no usage context, and no behavioral detail beyond 'read' and 'CLI-compatible'. An agent would struggle to know what 'name' refers to or how filters are combined. The presence of an output schema does not compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for six undocumented parameters. It only says 'same filters' but does not define what filter values are expected for name, type, actor, stage, limit, or since_seq. The reference to the CLI hints at semantics but does not give the agent enough information to construct a correct call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource: 'Read ledger events'. It distinguishes this from sibling session-control tools like run_session or get_status by focusing on ledger events rather than session lifecycle. However, it does not explicitly explain what a 'ledger event' is or how this differs from list_sessions_tool, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'with the same filters and canonical form as the CLI' implies a familiar command-line workflow and suggests this tool is the read/query counterpart to session actions. But there is no explicit when-to-use guidance, no exclusions, and no mention of when a sibling like get_status would be a better fit. Usage is implied rather than articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden and does add meaningful behavior: the session advances until a halt type and completed runs are finalized automatically in a specific order. It does not mention errors, asynchrony, or state-mutation side effects, but the core behavioral contract is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action and outcome, with no filler. The halt list and finalization sequence are compact but high-value details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description must explain parameter meaning, return behavior, and halt handling, but it explains none of those. The finalization note is useful, yet an agent still lacks enough to know what to expect after an 'input' halt or what the call returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'name' property with only a title, and schema description coverage is 0%. The description never mentions 'name' or what it identifies, so the agent receives no semantic help for the only parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Advance') and resource ('the session') and defines the target outcome via halt types. It conveys the tool's role among sibling session tools, though it does not explicitly distinguish it from step_session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose run_session versus step_session, stop_session, resolve_gate, or submit_input. The behavior is described, but there are no conditions, exclusions, or alternative routing cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does reveal the 'at most one stage' constraint, but it does not mention side effects, failure behavior, reversibility, or whether the operation is idempotent. For a state-mutating action, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. The core verb and constraint are front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one undocumented required parameter, no output schema, no annotations, and a large sibling toolset, the description is too thin. It lacks the meaning of 'name' and says nothing about return values or errors, making it difficult for an agent to call correctly in all situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the meaning of the required 'name' parameter. The agent must guess that 'name' identifies the session, which is not explicitly stated anywhere. The description adds no value over the raw schema for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('advance'), identifies the resource ('session'), and adds a precise qualifier ('by at most one stage') that distinguishes it from siblings like run_session or resolve_gate. An agent can confidently tell what action this tool performs and how it differs from related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (whenever a session should progress by one stage), but it does not explicitly state when to choose it over alternatives such as run_session or submit_input, nor does it mention any exclusions or prerequisites. The usage context is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that rejecting requires a reason, which is a useful non-schema constraint, and the approve/reject wording makes it clear this changes state. However, it does not describe side effects, irreversibility, or what happens to the session after resolution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes: the action, the target, and the critical rejection-reason rule.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too thin. It leaves the meaning of the required 'name' parameter ambiguous and does not explain what happens after the gate is resolved, which an agent would need to safely invoke the tool in a session workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that rejection requires a reason, but it does not explain what 'name' refers to or how it should be supplied. 'resolution' is understandable from the enum, yet two of the three parameters remain under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Approve or reject') and the resource ('the pending gate'), and the resolution enum makes the two possible outcomes explicit. It is distinguishable from the sibling tools, none of which mention gates, though the term 'gate' is left somewhat domain-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Use when a gate is pending is implied by 'the pending gate', but the description does not explicitly explain when this tool should be chosen over alternatives or when it should not be used. There is no mention of prerequisites or workflow position.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It does reveal that the tool submits an answer and then causes run_session to execute again, which is useful. However, it does not clarify whether the subsequent run_session is automatic or an instruction to the agent, nor does it disclose side effects on session state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the primary purpose and includes the key follow-up action. There is no filler or redundant content, and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three required parameters, no output schema, no annotations, and a non-obvious 'Founder-mode' concept, the description is too thin. It omits parameter semantics, expected response behavior, and any guidance on selecting this tool over session-management siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate, but it only implicitly clarifies the 'answer' parameter by saying to answer the question. The 'name' and 'question_id' parameters remain unexplained, and the description adds no detail about formats, roles, or how they relate to the session.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb "Answer" and names the resource: the session's pending Founder-mode question. It also mentions the follow-up action "run_session again," which clarifies the overall operation. It does not explicitly contrast itself with siblings, so it narrowly misses a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase "pending Founder-mode question" implies the tool is used when the session is waiting for input, but the description provides no explicit when-to-use or when-not-to-use guidance and does not name alternatives. The usage context is implied rather than stated, making it minimally adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral transparency. It states that a session is created and describes what the brief must contain, but it does not disclose side effects, persistence, return values, idempotency, or any state transition consequences. For a mutation-style tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The primary action is front-loaded, and the second sentence efficiently lists the only parameter details that need elaboration. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given seven parameters, a nested brief object, no annotations, and no output schema, this description is too thin to fully prepare an agent. It explains the brief but omits what the tool returns after creation, what optional parameters mean, and when to choose this tool over siblings. The brief guidance helps, but the overall calling context remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It adds genuinely useful meaning for the brief object by naming required fields like problem_space, target_segments, success_criteria, and risk_tolerance. However, it leaves mode, seed, panel_size, gate_policy, and total_token_budget unexplained beyond their default values and types, so compensation is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: 'Create a Design Thinking session.' This clearly differentiates the tool from siblings like run_session, step_session, stop_session, and list_sessions_tool, since it is the create operation in the session lifecycle. No ambiguity remains about the tool's primary purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys when to use this tool: when a new Design Thinking session needs to be created, before running or stepping it. It also provides required brief fields, giving practical setup guidance. However, it never explicitly states alternatives or exclusions, such as 'use run_session instead when a session already exists.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It communicates a read-only listing action, but does not disclose return format, pagination, session-state filtering, or whether it covers all sessions in the workspace. This is minimally adequate for a simple list operation but thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. The scope modifier 'in the workspace' adds useful context and is front-loaded effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing operation, the description is nearly complete. The lack of an output schema and any mention of returned session fields or defaults leaves a minor gap, and the existence of get_status creates mild ambiguity about which tool answers which session-related need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. There is no parameter information to add beyond what the empty input schema already shows, and the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource ('List sessions') and adds a workspace scope. The verb 'list' distinguishes it from action-oriented siblings like run_session, create_session_tool, step_session, and stop_session, though it does not explicitly point to any alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus get_status or the other session-related siblings. There are no exclusions, conditions, or alternative suggestions, leaving the agent to rely on naming inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior itself. It does reveal a conditional refusal and the output's intended ingestion format, but it does not say whether the tool returns the spec, writes files, or errors on refusal, so an agent is left guessing about side effects and response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence contains the purpose, output consumer, and refusal behavior without filler. The parenthetical is compact, though the sentence could be split for easier scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no annotations or output schema, the description covers the core contract but leaves the parameter mapping implicit and does not describe what a successful/refused call returns. Sibling differentiation is present through the artifact type but not named.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'name', has no schema description, and the description only indirectly ties it to 'the validated concept'. This gives a reasonable inference that name identifies the concept, but it does not explicitly define the expected value format or scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Generate') and a specific resource ('OpenSpec MVP specifications'), and adds a concrete consumer ('coding harness') plus an exclusion condition ('refused for killed concepts'). This is enough to distinguish it from siblings like generate_dossier, which produces a dossier rather than handoff specs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states the tool applies to 'validated concept' work and will refuse 'killed concepts', giving an explicit when-to-use and when-not-to-use. It does not name an alternative tool for killed concepts, but it still provides actionable selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does a good job: it discloses that the stop is journaled, human-initiated, and non-destructive since the session stays resumable. It omits possible error states or idempotency, but the core behavioral profile is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence with no filler. Key qualifiers ('journaled', 'human-initiated', 'stays resumable') are packed in without redundancy, and the core action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter stop operation, the key behavioral promise is present, but there is no output or error information and no parameter clarification. It is minimally adequate but leaves room for the agent to guess details about name resolution and return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate, but it does not explain 'name' or 'reason' beyond their schema titles. An agent must infer that 'name' identifies the session and 'reason' is an optional journaled explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific action ('Stop the run'), identifies the target resource ('session'), and adds precise scoping: journaled, human-initiated, and resumable. This clearly distinguishes it from siblings like run_session and step_session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: use for a deliberate human-initiated stop where the session must remain resumable. It does not explicitly name alternatives or when-not conditions, but the intended usage is inferable and distinct from run/step semantics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![bokken MCP server](https://glama.ai/mcp/servers/maglionejm/bokken/badges/card.svg)](https://glama.ai/mcp/servers/maglionejm/bokken)

Score Badge

Copy to your README.md:

[![bokken MCP server](https://glama.ai/mcp/servers/maglionejm/bokken/badges/score.svg)](https://glama.ai/mcp/servers/maglionejm/bokken)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/maglionejm/bokken'

If you have feedback or need assistance with the MCP directory API, please join our Discord server