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
workflow_detectA

Detect the product-delivery state of a project.

Call this FIRST when entering a project. Returns the current state and what action to take next:

  • "not_setup": No product-delivery config. Call workflow_setup to add it.

  • "setup_no_workflow": Config exists but no workflow started. Call workflow_init.

  • "active_workflow": Workflow in progress. Call workflow_status to see where it is.

  • "legacy_migration": Has BUILD_PLAN.md or ROADMAP.md from old skills. Call workflow_init(from_migration=True).

Args: project_dir: Project directory to check. Defaults to working directory.

workflow_projectsA

List all known projects managed by this server.

Shows every project that has been detected, initialized, or set up, along with its current phase and last-seen timestamp.

Args: refresh: If True, re-check each project's live state from disk. If False, return cached registry data (faster).

workflow_project_removeA

Remove a project from the registry.

Does not delete any files — just removes the project from the cross-project tracking list.

Args: project_dir: Project directory to remove.

workflow_initA

Initialize a new delivery workflow in the project directory.

Args: project_type: "greenfield" or "evolution". Leave empty to determine during intake. Can be defaulted via PRODUCT_DELIVERY_PROJECT_TYPE in .env. from_migration: Detect existing BUILD_PLAN.md or ROADMAP.md and migrate. project_dir: Project directory. Defaults to working directory.

workflow_statusB

Get the current workflow state, work items, and recent events.

Args: project_dir: Project directory. Defaults to working directory.

workflow_nextA

Show allowed transitions from the current state with guard status.

Returns which states can be reached and whether each guard passes, so the agent can decide what to do next.

Args: project_dir: Project directory. Defaults to working directory.

workflow_transitionA

Attempt a state transition. Guards are checked automatically.

Args: target: Target state (e.g. "discover", "frame", "plan", "deliver"). evidence: Evidence keys to attach to this transition. force: Force past failed guards (logged as forced). reason: Human-readable reason for the transition. project_dir: Project directory. Defaults to working directory.

workflow_item_addA

Add a work item to the delivery plan.

Only valid in plan or deliver phase. The item starts in "ready" state.

Args: name: Work item name/description. acceptance_criteria: AC-NNN IDs this item satisfies. risks: RISK-NNN IDs associated with this item. project_dir: Project directory. Defaults to working directory.

workflow_item_listA

List all work items, optionally filtered by state.

Args: state_filter: Only show items in this state (e.g. "ready", "implementing"). project_dir: Project directory. Defaults to working directory.

workflow_item_transitionB

Transition a work item to a new state.

Valid transitions: ready->implementing, implementing->verifying, verifying->reviewing, verifying->rework, reviewing->accepted, reviewing->rework, rework->implementing. Any item can be cancelled.

Args: item_id: Work item ID (WI-NNN). target: Target state. reason: Reason for the transition. project_dir: Project directory. Defaults to working directory.

workflow_item_waiveA

Waive a work item that is in reviewing state.

Requires explicit approver and reason. The item moves to "waived" terminal state and counts toward the completion guard.

Args: item_id: Work item ID (WI-NNN). approver: Who approved the waiver. reason: Why the item is being waived. project_dir: Project directory. Defaults to working directory.

workflow_checkA

Run guard checks for all available transitions from the current state.

Returns which transitions are ready (all guards pass) and which are blocked, with per-guard status.

Args: project_dir: Project directory. Defaults to working directory.

workflow_blockB

Block the workflow. Records the current phase as the resume target.

Args: reason: Why the workflow is blocked. owner: Who is responsible for resolving the blocker. project_dir: Project directory. Defaults to working directory.

workflow_resumeC

Resume a blocked workflow back to its pre-blocked phase.

Args: reason: Why the blocker is resolved. project_dir: Project directory. Defaults to working directory.

workflow_waive_guardA

Waive a transition guard so the transition can proceed.

The waiver is recorded with the approver and reason. The guard will show as "waived" instead of "fail" on subsequent checks.

Args: guard: Guard name to waive (from workflow_check results). approver: Who approved the waiver. reason: Why the guard is being waived (risk accepted). project_dir: Project directory. Defaults to working directory.

workflow_closeB

Close the workflow (normally from stabilize phase).

Args: reason: Reason for closing. force: Close from a non-stabilize phase (logged as forced). project_dir: Project directory. Defaults to working directory.

workflow_renderB

Render a human-readable markdown summary of the workflow status.

Args: project_dir: Project directory. Defaults to working directory.

workflow_configA

Show the active configuration from .env and environment variables.

Returns all PRODUCT_DELIVERY_* settings and where they came from.

Args: project_dir: Project directory. Defaults to working directory.

workflow_setupA

Set up product-delivery in a project.

Creates or updates: .claude/settings.json, .cursor/mcp.json, AGENTS.md (workflow rule), .env.sample, .env, and .gitignore. Merges into existing files without clobbering other settings. Idempotent — safe to run multiple times.

Call with dry_run=True first to preview changes, then with dry_run=False to apply them. Present the preview to the user before applying.

Args: dry_run: If True, preview what would change without writing. If False, apply the changes. project_dir: Project directory. Defaults to working directory.

Prompts

Interactive templates invoked by user choice

NameDescription
product_deliveryLoad the product-delivery conversational skill instructions. This prompt provides the agent with the full conversational skill: how to run discovery, when to push back, pacing rules, evidence types, and interaction style. Load it into context when starting or resuming a product delivery workflow.

Resources

Contextual data attached and managed by the client

NameDescription
resource_stateCurrent workflow state (state.json contents).
resource_eventsWorkflow event log (events.jsonl contents).
resource_template_briefProject brief template.
resource_template_planDelivery plan template (greenfield sequenced steps / evolution priority buckets).
resource_template_evidenceEvidence tracking template.
resource_ref_lifecycleFull state machine specification and transition table.
resource_ref_guardsGuard catalog for every transition.
resource_ref_evidenceEvidence types and linking rules.
resource_ref_compatCapability matrix across AI coding harnesses.
resource_ref_migrationMigration guide from BUILD_PLAN.md / ROADMAP.md.

TDQS

A3.5/5.0

Scored across 19 tools

Disambiguation3/5

Most tools map to distinct resources or actions, but workflow_check and workflow_next are nearly identical—both report available transitions and guard status. workflow_status and workflow_render also overlap in purpose, differing mainly in output format, which could cause an agent to select the wrong one.

Naming Consistency4/5

All tools share a consistent workflow_ prefix, and subdomains are marked with item_ and project_ segments. However, the pattern is not uniformly verb-first: workflow_projects, workflow_status, and workflow_config are noun-style, while workflow_item_add and workflow_project_remove place the verb at the end.

Tool Count3/5

19 tools is on the heavy side for a single server, though the breadth of workflow management—setup, state transitions, work items, guards, and project registry—partially justifies it. A few tools like workflow_check and workflow_next could be consolidated, which would tighten the surface.

Completeness4/5

The server covers the full delivery lifecycle: setup, detection, initialization, status, state transitions, blocking/resuming, closing, work item management, guard waiving, and configuration. Minor gaps exist, such as no way to edit or delete a work item, but these can be worked around without major agent failures.

Maintenance

ActivityMaintained
ResponsivenessNo issues