Commons
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| COMMONS_DB | No | SQLite path or postgresql://… | ~/.commons/commons.db |
| COMMONS_DB_KEY | No | SQLCipher encryption key (as a secret ref) | |
| COMMONS_EMBEDDER | No | fastembed for real embeddings | hash |
| COMMONS_BACKGROUND | No | In-process maintenance (full, 0) | light |
| COMMONS_ADMIN_AGENTS | No | Agents with global admin rights | |
| COMMONS_RATE_PER_MIN | No | Per-agent HTTP rate limit | 600 |
| COMMONS_REQUIRE_KEYS | No | HTTP requires keys (0 = local dev only) | 1 |
| COMMONS_CLAIM_MINUTES | No | Set the number of minutes for claiming the hub; 0 means setup-code only | |
| COMMONS_LEASE_SECONDS | No | Subtask lease length | 900 |
| COMMONS_DAILY_COST_CAP | No | USD/day cap for orchestrated work | |
| COMMONS_ESCALATE_AFTER | No | Seconds before stuck work escalates | 900 |
| COMMONS_DASHBOARD_TOKEN | No | Dashboard admin token; required only on public addresses | |
| COMMONS_WEBHOOK_ALLOWLIST | No | Private or non-https wake/webhook hosts you trust | |
| COMMONS_DASHBOARD_REQUIRE_TOKEN | No | 1 = 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
| 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 |
|---|---|
| rememberB | Store a memory (note, observation, fact). |
| 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 |
| resumeC | Pick up a session (or the latest one in a project): handoff packet, state, session items, recent context. |
| record_decisionC | Log a decision ( |
| 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
|
| 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 |
| 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; |
| 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
|
| 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
| Name | Description |
|---|---|
| checkin | Check in with Commons: what's waiting for you, and the user's preferences |
| start | Claim a task in Commons before starting it (no duplicate work) |
| handover | Hand everything you hold over to Commons |
| wrapup | Finish a session properly: board, claims, handoff, usage |
| whats_new | What changed in Commons and what you must adapt |
| sdlc | Run the whole six-stage workflow: spec, plan, build, test, review, ship |
| spec | DEFINE: turn an idea into a spec with acceptance criteria |
| plan | PLAN: PRD, contracts and the build graph for a spec |
| build | BUILD: implement a plan, then verify it |
| test | VERIFY: test something against its acceptance criteria |
| review | REVIEW: cross-family review with traceability |
| ship | SHIP: release, deploy and smoke-test, after you confirm |
| remember | Save something to Commons' shared memory |
| skill | Load a skill from the Commons pool and follow it (nothing to install) |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| playbook | The routine every agent follows |
| team | What every agent is doing right now |
TDQS
Scored across 35 tools
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.
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.
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.
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.