humane-intelligence
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 | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| birthA | Step 1, once: earn an identity before acting (Law 5: born, not configured). Returns a soul_id; use it or the name as |
| rememberA | Write one hash-linked, tamper-evident record. actor = a born soul_id or birth name. Example: remember(actor=Ember, action=shipped v0.2.1, data={pr: 42}). |
| recallA | Read the latest records (newest first, optionally one actor) so you do not re-derive what you already know. Call this at the start of a session. |
| verifyA | Prove the entire memory chain is unbroken (recomputes every hash). Free, local, no key. |
| upgradeC | What ArkHive v2 (paid) adds — and, if you give your email, a free 14-day v2 trial key. Opt-in only: nothing is sent unless you provide an email. |
| governB | Ask may-I before acting. Deterministic, zero-LLM: any rule whose trigger appears in flags vetoes. flags/rules accept lists or {name: true} / {trigger: action} maps. |
| request_actionA | The ONLY door to a consequential action (deploy, write_prod, overwrite, service_restart). Runs the decree conformance check; on pass mints a single-use, artifact-bound, 60s token the executor must present; on veto FAILS CLOSED — no token, no action. Pass the ACTUAL artifact (file contents / diff / plan) so it can be checked and hash-bound. |
| check_conformanceA | Dry-run the gate: judge an artifact against every active decree whose scope matches, WITHOUT minting a token. Deterministic rules first; advisories surfaced; anything unprovable fails closed. Use before request_action to see why something would be vetoed. |
| validate_tokenA | The executor calls this to authorize a real action. Rejects any token that is unknown, expired (>60s), already used, or bound to a different action_type / artifact / targets. On success the token is burned (single use) and the execution is fossiled. |
| list_decreesA | List the active governing decrees (id, text, scope, enforcement, rules). Read-only; anyone may call it. |
| add_decreeA | FOUNDER ONLY. Write a new governing decree as an immutable fossil (requires the founder key). Agents cannot add, soften, or exempt themselves from a decree — calls without the key are denied and fossiled. |
| seed_decreesB | FOUNDER ONLY. Seed the standing decrees (Senthar runtime, Claude build-wide, fossil-grounded, governance-is-code, embodiment-enforced, irreversible-human-signoff) if not already present. Requires the founder key. |
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 12 tools
Most tools have clearly distinct roles: identity creation (birth), memory (remember/recall/verify), governance (govern, list_decrees, add_decree, seed_decrees), and action gating (request_action, check_conformance, validate_token). However, 'govern' could be confused with 'check_conformance' as both involve rule checking, though descriptions clarify the difference (generic may-I vs dry-run artifact evaluation).
All tool names use snake_case and imperative verbs, which is consistent. Some are single verbs (birth, remember, recall, verify, upgrade, govern) while others are verb_noun (request_action, check_conformance, validate_token, list_decrees, add_decree, seed_decrees). The pattern is not strictly uniform, but the style is cohesive and readable.
The 12 tools are well-scoped for the server's purpose of governing actions with memory and identity. Each tool serves a distinct function without redundancy, fitting comfortably within the typical 3-15 range for a focused domain.
The tool set covers the core lifecycle: identity creation, memory operations, governance inspection and creation, and action authorization with token validation. Minor gaps exist, such as no explicit way to revoke an identity or update decrees (though decrees are intentionally immutable), but these are not critical for the stated purpose.