Loading ToolBench
Composite MCP server upgrading Algernon (fan-out orchestration), ArkHive (hosted governed audit/memory), and Humane Intelligence (local covenant/identity gate) into one substrate: two-chamber fail-closed governance, dual-chain tamper-evident memory, covenant-gated identity, cost prediction, and dependency-aware dispatch.
Sentarion exposes 13 tools with moderate to good parameter schemas but uneven description quality and some naming inconsistencies. All tools have input schemas visible in server.py with types and descriptions. Tool descriptions range from clear and specific (e.g., sentarion_birth, dispatch_with_dependencies) to vague or overly technical (e.g., sentarion_pro, cost_estimate). Parameter descriptions are generally present but often terse. The server attempts to address legitimate governance and auditability concerns (two-chamber fail-closed gates, dual-chain memory), but the interface complexity and philosophical/proprietary framing reduce clarity. No explicit output schemas are documented, responses are inferred from code context. Error handling guidance is absent from descriptions.
Rough pre-dispatch cost estimate for k Algernon fan-out tasks. Prices are per-million-tokens.
GOVERNED wave-ordered dispatch: tasks run in waves ordered by depends_on; {{id}} placeholders in prompts are replaced with task results (data flow); passes the two-chamber fail-closed gate BEFORE any dispatch.
Two-chamber fail-closed verdict gate: asks local Humane (zero-LLM rule engine) and hosted ArkHive (tamper-evident audit chain). Blocks unilaterally if either chamber vetoes. Returns BINARY decision (approve/block) or fails closed.
Govern-gated plan + dispatch with automatic logging: governs once before dispatch, then plans via Algernon, dispatches k fan-out tasks, and records the run to both memory chains.
Merged dual-chain read: retrieve and merge records from both local Humane chain and hosted ArkHive chain.
History-primed planning (plan-only, no dispatch): pulls prior records from both chains and lets Algernon plan the next step on top of them.
Two tools violate pattern:tool (single responsibility) by combining actions in names: 'orchestrate_and_record' and 'recall_and_replan'. This forces LLMs to reason about whether to call one tool that does both or separate tools, increasing error risk.
No explicit output schemas documented for any of the 13 tools. Descriptions do not specify what fields, types, or structures are returned. LLMs must infer output format from context, leading to wrong field lookups and chaining failures.
Several tools use non-verb_noun naming (sentarion_pro, recall, remember, worktree, sentarion_doctor, sentarion_quickstart), which makes intent ambiguous for LLMs. Names should start with action verbs: 'describe_', 'retrieve_', 'record_', 'check_', 'get_examples_'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
Dual-chain write: tamper-evident record to both the local Humane chain and hosted ArkHive chain at once.
Earn a soul_id (covenant-gated identity) before any governed action, honoring Humane's Law 5 (born, not configured). Writes to both local Humane chain and hosted ArkHive chain.
Read-only health check for all Sentarion dependencies: git, Algernon, local covenant chamber, hosted ArkHive, fleet provider, Ollama, and API keys. Reports what to fix if not ready.
Describes the paid v2 control plane features and never changes free behavior.
Canonical, runnable examples for every Sentarion capability. Returns start-here tools or specific example by topic.
Prove both chains (local Humane and hosted ArkHive) are intact and tamper-evident.
Governed git-worktree sandbox: create, list, or remove isolated git worktrees so dispatched work never touches the live checkout. Create and remove pass the two-chamber gate; list is read-only.
Error handling guidance is absent. None of the tool descriptions explain what errors can occur, how to distinguish user-fixable errors from retryable ones, or what the agent should do on failure (retry, ask user, escalate). Reduces robustness.
Input parameter enums are not formally declared in schemas. E.g., worktree.action should be enum: ['create', 'list', 'remove']; sentarion_quickstart.topic should list valid values. Free-form strings invite hallucinated values.
Parameter descriptions are often terse or missing context on expected format. E.g., 'tasks_json' in dispatch_with_dependencies says 'JSON array' but does not specify required fields (id, prompt, depends_on) or placeholder syntax ({{id}}).
Dependencies between tools are not documented. E.g., remember/recall/verify/dispatch_with_dependencies all require 'actor' from sentarion_birth, but no description says 'call sentarion_birth first' or 'actor is the soul_id returned by sentarion_birth'.
No guidance on tool selection. Descriptions do not explain when to call (e.g.) recall vs recall_and_replan, or when to use dispatch_with_dependencies vs orchestrate_and_record. LLMs waste reasoning cycles on selection.
Idempotency is not declared. Destructive or state-mutating tools (sentarion_birth, remember, orchestrate_and_record, dispatch_with_dependencies, worktree create/remove) do not state whether they are idempotent or what happens on retry. Agents may retry and cause unintended duplicates.