Baron
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
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
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| baron_issue_readA | Read work items. ops: |
| baron_issue_writeA | Change a work item’s content. ops: |
| baron_issue_moveA | Move a work item through the workflow, or flag it. ops: |
| baron_scm_readA | Read source-control state. ops: |
| baron_scm_writeA | Change source-control state. ops: |
| baron_recipe_listA | List the runnable recipes (built-ins + project recipes) with their declared inputs. Call this to discover what |
| baron_recipe_runA | Run a named recipe end-to-end as ONE deterministic, rule-enforced workflow (the engine — not you — enforces the step order). Supply all required inputs (from baron_recipe_list) in |
| baron_memory_appendB | Record something durable in Baron's own store (not a provider's). ops: |
| baron_memory_queryA | Read Baron's own store. ops: |
| baron_native_requestA | ESCAPE HATCH — a raw, authenticated, NON-PORTABLE provider REST call. Last resort for when no normalized tool (issue/scm/ci/notify) covers the need. You supply the provider-native method + path (+ query/body); Baron only attaches the base URL + auth and returns the (size-capped) response. Prefer the normalized tools — this is provider-specific and will not port to another provider. Only providers bound in the active policy are reachable. |
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 10 tools
Each tool is scoped to a distinct domain and action: memory query/append, issue read/write/move, SCM read/write, recipe list/run, and a raw native escape hatch. Potentially overlapping operations like issue update vs issue transition are explicitly separated by content-change versus workflow-role semantics.
All tools follow the same baron_<domain>_<action> snake_case pattern with clear domains and verbs. The naming is highly predictable, making it easy for an agent to infer where a capability lives.
Ten tools is well-scoped for a development-workflow assistant. Grouping related operations under issue, scm, memory, and recipe domains keeps the tool count manageable without sacrificing coverage.
The core issue lifecycle and PR lifecycle are well covered, and recipes provide end-to-end workflow execution. Minor gaps remain: there are references to normalized CI/notify tools that are not exposed, no way to delete/close issues or resolve memory followups, and recipe authoring is not supported.