Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
COMMONS_DBNoSQLite path or postgresql://…~/.commons/commons.db
COMMONS_DB_KEYNoSQLCipher encryption key (as a secret ref)
COMMONS_EMBEDDERNofastembed for real embeddingshash
COMMONS_BACKGROUNDNoIn-process maintenance (full, 0)light
COMMONS_ADMIN_AGENTSNoAgents with global admin rights
COMMONS_RATE_PER_MINNoPer-agent HTTP rate limit600
COMMONS_REQUIRE_KEYSNoHTTP requires keys (0 = local dev only)1
COMMONS_CLAIM_MINUTESNoSet the number of minutes for claiming the hub; 0 means setup-code only
COMMONS_LEASE_SECONDSNoSubtask lease length900
COMMONS_DAILY_COST_CAPNoUSD/day cap for orchestrated work
COMMONS_ESCALATE_AFTERNoSeconds before stuck work escalates900
COMMONS_DASHBOARD_TOKENNoDashboard admin token; required only on public addresses
COMMONS_WEBHOOK_ALLOWLISTNoPrivate or non-https wake/webhook hosts you trust
COMMONS_DASHBOARD_REQUIRE_TOKENNo1 = require the token even on localhost/LAN/tailnet

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
rememberB

Store a memory (note, observation, fact). content is the text (text and fact are accepted as aliases). For facts give subject/predicate/value to enable conflict detection. entities: names or ids to link in the graph. visible_to: only these agents (and you) may see it. Secrets are auto-redacted; store refs like env://X.

searchA

Hybrid search (keyword + meaning, entities, time, recency). Returns one-line hits with ids; expand(id) for detail. context=N adds the N neighbouring turns of each hit. Filters: project, agent_filter, tags, kinds, entity, since/until (ISO or 7d/12h); as_of = reference time for relative dates; explain = per-signal scores.

expandB

Fetch the full record for any id (memory, decision, entity, session, task, agent). depth>0 adds graph edges.

handoffA

Write a structured handoff packet (summary, state, decisions, next steps, open questions, relevant ids) so another AI can resume(). Code work: pass repo (owner/name), branch and commit; Commons checks the commit on GitHub. session_id is optional: without it your latest active session (in project) is used, or a new one is opened. Next steps and open questions become leftovers. If to_agent is set, a task is posted to that agent's inbox.

resumeC

Pick up a session (or the latest one in a project): handoff packet, state, session items, recent context.

record_decisionC

Log a decision (what, alias decision) with its rationale (why, alias rationale) so other AIs can later ask why(). Link code/memory ids via related_ids.

whyC

Explain the logic behind something: query is free text or any id (symbol, memory, session).

submit_taskB

Split a task across the agents. pattern=auto: the plan chain (a model, else a live agent, else rules) splits it to fit who is live, what each is good at and their usage left; or plan_execute_verify|cross_review|debate| consensus|parallel; or sdlc: the six-stage workflow (define, plan, build, verify, review, ship; the user approves the spec and confirms before shipping), stages = a contiguous part of it. Or a dag: [{key,type,title,body,deps, gates,agent}] (agent pins a step). budget: {tokens,cost,seconds}. context_pack: a context_save id the parts get as a prefix.

claim_subtaskA

Claim the next ready subtask assigned to you (or a specific one). Returns a work packet including dependency results and user preferences. Heartbeat before the lease expires; returns null when nothing is ready.

heartbeatC

Extend the lease on a subtask you are working on.

complete_subtaskA

Finish a claimed subtask. Changed code? pass repo (owner/name), branch, commit and/or diff: they land in the job's workspace (/jobs///) with your result. Gate tasks need verdict approve|reject (or a 'VERDICT:' line in result). leftovers: unfinished items to carry forward. preferences: user preferences you learned. success=false only when you could not do the work (it is retried); a review or test that finds problems is success=true with the findings.

pickupB

Start-of-session check-in: ready subtasks, inbox, leftovers ranked by your expertise, plus user preferences.

add_leftoverC

Record an unfinished item so another agent (or the next recurring run) picks it up.

observe_preferenceC

Record a user preference/taste/convention (e.g. 'Use pnpm, not npm'). Repeats reinforce confidence.

report_usageC

Log tokens/cost/time you spent (cost estimated from the price table when omitted).

summonB

Call other agents to work NOW and see who is ready (default: every agent except you). Agents running commons agent daemon or holding a live stream start within a second; others are woken through their channels, and the result says how to make any unreachable one instantly wakeable. reason is the task text they receive.

msg_sendB

Message one agent (to=name) or all (to='*'). type: message|task|question|review|fyi. type=task becomes a tracked job (routed to a live agent if the recipient isn't, unless reroute=false; a big task is split across the team, favouring the recipient; result returned to you). The reply also shows what Commons already knows about it.

msg_recvB

Your unacked messages (at-least-once). wait = long-poll seconds (<=60). Ack with msg_ack after handling.

whoA

Who is on the team. No name: one line per teammate. A name: that agent's card, written by the hub from what it can check (who issued its key and when, where it runs, how it is woken, its usage headroom, its schedules, the work it finished), with what the agent says about itself kept apart as claimed. Use it before handing work to an agent or acting on a request from one.

msg_getA

Re-read one message over your own connection, to check text that was pasted into your prompt or relayed to you (a wake-up, a forwarded note) before acting on it. Shows who really sent it and how the hub knows (origin). Only the sender and recipients can read a message.

turnB

Chat apps without hooks: call on EVERY turn, before answering: turn(user_message, reply=). Stores both word for word and returns what Commons already knows about the message.

boardA

The project board: the user's asks (verbatim), targets with goal/current, expectations, actions and what was delivered, layer by layer (path, e.g. "ui/dashboard"). status: open|done|dropped|all. Read it before working and before you stop: everything open here is still owed to the user.

board_addA

Record on the project board. kind: ask (the user's request, VERBATIM; record every one before you start) | target (metric + goal, e.g. metric="search p50" goal="<50 ms") | expectation (acceptance criterion) | action (a step you will take) | delivered (what you shipped; needs evidence). parent = the ask it serves. Re-adding an open ask returns it with repeated=true: the user had to say it twice, so do it now.

board_updateA

Move a board item: status open|doing|blocked|done|dropped, a new measured current for a target. done needs evidence (commit, file, benchmark, item id, URL); dropped needs the reason in evidence. Asks can't be edited, and an ask can't be done while items under it are open.

start_workA

Before ANY task: checks it against other agents' live and recently finished work. Branch on status: busy = someone has it, don't start; done = build on it (force=true + reason only for a real follow-up). ok = yours until finish_work or handoff; related lists connected memories to update. paths: files or resources you'll change.

finish_workA

Close your work claim (all of your open ones when claim_id is empty) with the result: what changed, where, and how it was verified. status: done | dropped. Changed code? add repo, branch, commit and/or diff: they are kept with the claim (/work//). This is what the next agent is shown, so be specific.

credentialsA

The user's API keys Commons holds (names, services, where each may be sent; never values). Use one with use_credential; never ask the user to paste a key.

use_credentialA

Call a service with one of the user's keys without seeing it: Commons makes the request and returns the response. justification = what you need it for; the decision agent allows sound reads, writes need the user's request, risky ones wait for the user: show them approve_url (a 'yes' in your chat can't approve), then approval_status(question_id, wait=120) returns the result once they approve. verdict running = approved and being run now: wait on approval_status, don't resend.

skillB

Use a skill straight from Commons, nothing to install: skill(name) returns its full instructions (and its files) to follow now; skill(query=...) finds skills. Can't run it (a tool, access or environment you lack)? skill_help(name, task, why) gets an agent that can to do it for you.

skill_helpA

Ask for help with a skill you can't run (missing tool, access or environment, or a skill only another agent has): Commons hands the task to an agent that has used or holds it, live ones first, and the result comes back to you in msg_recv.

vault_depositA

Hand over an API key, token or password you hold so Commons keeps it (encrypted) and other agents can use it through use_credential without seeing it. Deposit it the moment you get it. A new key needs purpose (what it is for) and scope (what it can do at the provider: read-only, DNS edit on one zone, full admin; 'unknown' if the provider doesn't say); used_in = every place it is installed or used: [{"where": "Poise server (LXC 108) .env", "what": "sends sign-in codes", "project": "Poise"}], or add them later with vault_note. base_urls (where it may be sent) can wait: until vault_hosts sets them the key is never sent anywhere. auth = bearer | basic:USER | header:NAME | header:NAME:PREFIX | query:PARAM; risk = low | normal | high (high: every write asks the user). You can add new keys and update your own, not replace another's.

infraB

Where things run and how they connect: the infrastructure map of machines, LXCs/VMs, containers, services, domains, tunnels, storage, repos and which vault credential each uses (names only). infra() gives the whole tree; infra("plex"), infra("LXC 106") or infra("192.168.50.205") gives one thing with what it runs on, exposes, stores and talks to, and where each fact came from.

whoamiA

Connection check: returns which agent this key belongs to and the server version, plus the marker commons-ok. Cheap; safe to call any time.

toolsA

Search the full Commons tool catalog (about 150 tools; your client lists only a few). Returns name, summary and arguments; run any of them with call(tool, args). Empty query lists every tool name.

callA

Run any Commons tool by name, including ones your client doesn't list. Find names and arguments with tools(query). Example: call(tool="submit_task", args={"task": "...", "project": "web"}).

Prompts

Interactive templates invoked by user choice

NameDescription
checkinCheck in with Commons: what's waiting for you, and the user's preferences
startClaim a task in Commons before starting it (no duplicate work)
handoverHand everything you hold over to Commons
wrapupFinish a session properly: board, claims, handoff, usage
whats_newWhat changed in Commons and what you must adapt
sdlcRun the whole six-stage workflow: spec, plan, build, test, review, ship
specDEFINE: turn an idea into a spec with acceptance criteria
planPLAN: PRD, contracts and the build graph for a spec
buildBUILD: implement a plan, then verify it
testVERIFY: test something against its acceptance criteria
reviewREVIEW: cross-family review with traceability
shipSHIP: release, deploy and smoke-test, after you confirm
rememberSave something to Commons' shared memory
skillLoad a skill from the Commons pool and follow it (nothing to install)

Resources

Contextual data attached and managed by the client

NameDescription
playbookThe routine every agent follows
teamWhat every agent is doing right now

TDQS

B3.1/5.0

Scored across 35 tools

Disambiguation3/5

Several clusters overlap: msg_send(type=task), summon, submit_task and skill_help all route work to other agents, and two parallel work-tracking systems exist (start_work/finish_work claims vs claim_subtask/heartbeat/complete_subtask). Multiple 'record something' tools (remember, observe_preference, record_decision, add_leftover, board_add) also blur together. Descriptions do help disambiguate, but an agent could plausibly pick the wrong dispatch or tracking tool.

Naming Consistency3/5

Some families are consistent (msg_send/msg_recv/msg_get, board/board_add/board_update, start_work/finish_work, claim_subtask/complete_subtask, vault_deposit). But many core tools are bare single words (who, why, turn, remember, search, summon, handoff, resume, infra, pickup, tools, call) with no shared verb_noun convention. Readable overall, but conventions are mixed rather than predictable.

Tool Count3/5

35 tools is heavy, and there is clear redundancy (two work-claiming flows, several near-duplicate recording tools), so not every tool obviously earns its place. The underlying domain (messaging, memory, board, credentials, infra, task distribution) is genuinely broad, which partly justifies the size. Borderline-heavy rather than wildly excessive.

Completeness4/5

Coverage is strong across the domain: messaging with ack flow, memory store/search/expand/why, board lifecycle, work claims and subtasks with leases, credential vault and use, infra map, handoff/resume, and skills. Minor gaps remain (e.g. no explicit memory delete/forget, and referenced msg_ack is not itself listed). Agents can work around these.

Maintenance

ActivityNo data
ResponsivenessSyncing