arifOS — Constitutional AI Governance
Server Details
Constitutional AI governance: 11 mega-tools, 13 floors, VAULT999 ledger. Human-in-loop by design.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- ariffazil/arifosmcp
- GitHub Stars
- 39
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 1.9/5 across 18 of 18 tools scored. Lowest: 1/5.
Most tools have clearly distinct purposes, but there is overlap between arif_ops_measure (health telemetry) and get_constitutional_health (F1-F13 floor status), as well as between arif_judge_deliberate (history mode) and list_recent_verdicts. These overlaps could cause misselection.
The majority follow an 'arif_verb_noun' pattern, but several tools lack the 'arif_' prefix (command_center, get_constitutional_health, list_recent_verdicts, render_vault_seal, vault_seal_card), breaking consistency. The mix of verb+noun and compound names (vault_seal_card) adds to the inconsistency.
With 18 tools, the surface is slightly above the ideal 3-15 range but remains justified given the complex governance domain. Each tool serves a distinct function, and the count does not feel excessive.
The tool set covers the full lifecycle of constitutional AI governance: session bootstrap, observation, reasoning, critique, orchestration, execution, gateway, memory, ops, reply, judging, evidence, vault, and UI. No obvious gaps exist for the intended purpose.
Available Tools
18 toolsarif_evidence_fetchCInspect
222_FETCH: Evidence-preserving web ingestion with sequential thinking.
Sequential thinking parameters (civilization intelligence):
thinking_depth: Max reasoning steps (0-10). 0 = disabled.
thinking_budget: Token/time budget for thinking (0.0-10.0).
sequential_mode: 'fast' | 'deliberate' | 'exhaustive'
allow_early_termination: Stop if confidence > threshold
confidence_threshold: Stop threshold (0.0-1.0)
When thinking_depth > 0, output includes ThinkingSequence + ResourceMetrics.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| mode | No | fetch | |
| query | No | ||
| actor_id | No | ||
| session_id | No | ||
| thinking_depth | No | ||
| sequential_mode | No | deliberate | |
| thinking_budget | No | ||
| confidence_threshold | No | ||
| allow_early_termination | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions thinking parameters and output when depth > 0, but fails to disclose basic behaviors such as read-only nature, side effects, authentication requirements, or error states. The 'evidence-preserving' claim is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with an awkward prefix '222_FETCH' and uses bullet points for thinking parameters. While structured, it wastes space on minor details and could be more succinct. It is moderately concise but not optimally front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no schema descriptions, and an output schema (content not shown), the description is incomplete. It explains only the thinking parameters and does not address the primary parameters for fetching content. The overall behavior remains under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must provide parameter meaning. It covers thinking parameters (depth, budget, mode, etc.) but omits five core parameters (url, mode, query, actor_id, session_id). This leaves a significant gap in understanding how to invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Evidence-preserving web ingestion with sequential thinking,' which clearly indicates a web fetch tool with evidence preservation. However, it does not differentiate from sibling tools, as many have overlapping domains (e.g., arif_memory_recall, arif_sense_observe). The purpose is clear but not uniquely distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or context, leaving the agent to infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
arif_forge_executeDInspect
010_FORGE: Metabolic execution, build orchestration, and artifact forging.
Executes system modifications, builds, deployments, and code changes under constitutional supervision. All forge operations run in dry_run mode by default. Permanent changes require a prior 888_JUDGE SEAL verdict and explicit human ack (F1 Amanah).
Artifact-producing modes (engineer, write, generate) require an approved plan_id from arif_mind_reason(mode='plan') per H2 ratification.
Modes: engineer — Execute a manifest (build, deploy, or system change). query — Inspect current system state without mutation. write — Write or modify files under constitutional supervision. generate — Generate code or artifacts under constitutional supervision. commit — Seal a forge operation to the vault. recall — Recall a prior forge artifact or execution trace. dry_run — Simulate a forge operation without mutation.
Parameters: mode — engineer | query | write | generate | commit | recall | dry_run manifest — JSON manifest describing the operation query — State inspection query (query mode) artifact_id — Target artifact for rollback/status ack_irreversible — Explicit human ack for permanent changes constitutional_chain_id — Chain hash for audit continuity judge_state_hash — Authorizing 888_JUDGE verdict hash vault_entry_id — VAULT999 entry to link this forge to plan_id — Approved plan_id (required for engineer/write/generate) session_id — Governed session ID actor_id — Sovereign actor identifier ctx — FastMCP Context for progress reporting and elicitation
Returns: ForgeOutput with status, execution_trace, artifact_id, and irreversibility_level.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | engineer | |
| query | No | ||
| plan_id | No | ||
| actor_id | No | ||
| manifest | No | ||
| session_id | No | ||
| artifact_id | No | ||
| vault_entry_id | No | ||
| ack_irreversible | No | ||
| judge_state_hash | No | ||
| constitutional_chain_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
arif_gateway_connectDInspect
666_GATEWAY: Federated cross-agent bridge and A2A mesh protocol.
Connects the sovereign session to other constitutional agents (Kimi, Claude, Gemini, etc.) via the Agent-to-Agent (A2A) mesh. All handshakes include constitution hash verification to prevent rogue agent injection.
Modes: route — Forward intent to a specific target agent. discover — List available agents in the federation mesh. handshake — Initiate a verified constitutional handshake. relay — Pass a sealed message through the gateway without mutation.
Parameters: mode — route | discover | handshake | relay target_agent — Canonical agent name (e.g., kimi, claude, gemini) session_id — Governed session ID actor_id — Sovereign actor identifier
Returns: Gateway status with protocol, routing path, and agent capability map.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | route | |
| actor_id | No | ||
| session_id | No | ||
| target_agent | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
arif_heart_critiqueDInspect
666_HEART: Ethical critique, risk assessment, and empathy scan.
Tier 1: SEA-LION LLM inference Tier 2: Ollama local fallback Tier 3: Deterministic keyword-based fallback
Evaluates proposed actions against 8 risk categories (privacy, bias, harm, irreversibility, deception, autonomy, dignity, sustainability). Forces human_decision_required for high/critical/irreversible risk tiers.
F-WEB External Instruction Scan (Blueprint §10): When evidence_receipt is provided, the target content is scanned for indirect prompt injection patterns before LLM critique runs. This prevents "External content is evidence, not authority" violations.
Modes: critique — Full risk analysis of a target action or content. simulate — Run a what-if scenario and project risk outcomes. empathize — Assess human impact load (Ω) on weakest stakeholders. redteam — Attack surface analysis. maruah — Dignity score (F05 Peace). deescalate — Risk reduction strategy. summary — Return a condensed risk scorecard.
Parameters: mode — critique | simulate | empathize | redteam | maruah | deescalate | summary target — Action, content, or scenario to critique session_id — Governed session ID actor_id — Sovereign actor identifier evidence_receipt — F-WEB receipt; if present, triggers external instruction scan
Returns: RiskReport with risks_found, risk_tier, human_decision_required, and empathy_score (κᵣ).
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | critique | |
| target | No | ||
| actor_id | No | ||
| session_id | No | ||
| evidence_receipt | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
arif_judge_deliberateDInspect
888_JUDGE: Final constitutional arbitration and verdict sealing.
The apex adjudication organ. Evaluates a candidate action against all 13 constitutional floors (F1–F13) and returns a binding verdict: SEAL (approved), SABAR (conditional), HOLD (paused), or VOID (rejected). Irreversible actions require explicit human confirmation via ctx elicitation.
Modes: judge — Full constitutional review of a candidate. compare — Side-by-side comparison of two candidate actions. history — Retrieve prior verdicts from the constitutional chain. explain — Generate a human-readable rationale for a verdict.
Parameters: mode — judge | compare | history | explain candidate — Action or proposal to adjudicate constitutional_chain_id — Immutable chain hash for audit continuity session_id — Governed session ID actor_id — Sovereign actor identifier ctx — FastMCP Context for progress reporting and elicitation evidence_receipt — F-WEB receipt; triggers deterministic evidence gate claimed_evidence_level — LLM's claimed level; tested against receipt max
Returns: VerdictOutput with code, floor compliance proof, epistemic_snapshot, and required_next_tool (if any).
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | judge | |
| actor_id | No | ||
| candidate | No | ||
| session_id | No | ||
| evidence_receipt | No | ||
| claimed_evidence_level | No | ||
| constitutional_chain_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
arif_kernel_routeDInspect
444_KERNEL: Central orchestration, intent routing, and stage dispatch.
Routes sovereign intent to the correct constitutional stage and tool sequence. Acts as the traffic controller for the 13-tool surface, ensuring every call flows through the proper floor checks.
Modes: route — Full orchestration: depth, risk, budget, workflow, authority. stage — Query or advance the session stage (000–999). lane — Switch cognitive lane (AGI | ASI | APEX). list — Enumerate available tools for the current session. status — Kernel health + orchestration maturity metrics.
Governance gating modes (standalone diagnostics): depth_select, risk_gate, budget_gate, authority_gate, reversibility_gate, workflow_select
Parameters: mode — route | stage | lane | list | status | depth_select | ... target — Target tool or endpoint name task — Task description for routing resolution stage — Explicit stage override (000–999) session_id — Governed session ID actor_id — Sovereign actor identifier
Returns: Routing decision with path, hops, stage, workflow, budget, and authority boundary.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | route | |
| task | No | ||
| stage | No | ||
| target | No | ||
| actor_id | No | ||
| session_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
arif_memory_recallDInspect
555_MEMORY: Live associative memory via MemoryEngine (Postgres + Qdrant dual-write, BGE-M3 embeddings).
Modes: recall — Semantic search across stored memories. store — Persist a new memory entry. get — Exact retrieval by memory_id. list — List memories scoped to current session. prune — Soft-delete (sacred tier requires 888_HOLD). search — Alias for recall. context — Session context window. dry_run — Ephemeral write/recall/cleanup cycle.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | recall | |
| query | No | ||
| actor_id | No | ||
| metadata | No | ||
| memory_id | No | ||
| session_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
arif_mind_reasonDInspect
333_MIND async tool — routes cognitive modes through LLM inference.
Structural modes (plan, plan_review, plan_approve, axioms) are deterministic and go directly to _arif_mind_reason. Cognitive modes (reason, reflect, verify, critique, debate, socratic) route through runtime.mind_reason which provides SEA-LION → Ollama → rule fallback.
F13 SOVEREIGN: plan_approve remains deterministic — LLM must never adjudicate sovereign approval.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | reason | |
| query | No | ||
| plan_id | No | ||
| actor_id | No | ||
| session_id | No | ||
| witness_type | No | ai |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
arif_ops_measureDInspect
777_OPS: Resource thermodynamics, health telemetry, and metabolic monitoring.
Measures the operational health of the constitutional kernel using thermodynamic analogies: entropy (ΔS), genius score (G ≥ 0.80), human impact load (Ω), and paradox tension (Ψ).
Modes: health — Lightweight liveness check (CPU, mem, disk). vitals — Full thermodynamic state (G, ΔS, Ω, Ψ). cost — Estimate computational and token cost of a planned action. predict — Project resource trajectory based on current load.
Parameters: mode — health | vitals | cost | predict estimate — Cost estimate input for cost/predict modes session_id — Governed session ID actor_id — Sovereign actor identifier
Returns: Health payload with status, metrics, and thermodynamic bands.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | health | |
| actor_id | No | ||
| estimate | No | ||
| session_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
arif_reply_composeDInspect
444r_REPLY async tool — routes all modes through LLM-aware reply_compose module.
SEA-LION → Ollama → deterministic fallback (same pattern as 333_MIND / 666_HEART). The LLM actually composes/rewrites the message rather than echoing it back.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | compose | |
| style | No | ||
| message | No | ||
| actor_id | No | ||
| citations | No | ||
| session_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
arif_sense_observeDInspect
111_SENSE: Multimodal reality observation and environmental sensing.
Gathers raw observational data across multiple sensory layers: web search, URL ingestion, geospatial compass, structured atlas maps, entropy monitoring (ΔS), and system vitals.
Modes: search — Free-text query against configured search backends. ingest — Fetch and parse a specific URL. compass — Directional / geospatial heading query. atlas — Structured map/layer retrieval. entropy_dS — Measure thermodynamic entropy delta of the session. vitals — CPU, memory, and I/O telemetry.
Parameters: mode — search | ingest | compass | atlas | entropy_dS | vitals query — Free-text search query url — Target URL for ingest mode layers — Layer identifiers for atlas mode session_id — Governed session ID actor_id — Sovereign actor identifier
Returns: Observation payload with results, source tag, and omega_0 (uncertainty).
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| mode | No | search | |
| query | No | ||
| layers | No | ||
| actor_id | No | ||
| session_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
arif_session_initDInspect
000_INIT: Constitutional session bootstrap and identity binding.
Anchors a new governed session to the 13-floor constitution (F1–F13). Every session receives a unique ID, actor binding, and a constitutional fingerprint (constitution_hash + invariants_hash). This is the entry gate for all subsequent tool calls.
Modes: init — Create a new session with full constitutional binding. resume — Reattach to an existing session by session_id. validate — Check session health and constitutional alignment. epoch_open — Open a new epoch, binding epoch_id to session_id. epoch_seal — Seal the current epoch, writing Epoch Seal JSON to vault.
Parameters: mode — init | resume | validate | epoch_open | epoch_seal actor_id — Sovereign actor identifier (required for init) ack_irreversible — Explicit human ack for irreversible operations (F1 Amanah) session_id — Existing session UUID (required for resume/validate/epoch_*) epoch_id — Epoch identifier (optional for init; required for epoch_seal) declared_model_key — Optional model key (provider/family/variant) for registry binding. actor_signature — Ed25519/ES256 signature over (session_id + constitution_hash + nonce) nonce — Unique nonce to prevent replay attacks (recommended; required for high-security)
Returns: SessionState with constitution_id, constitution_hash, public_surface, authority level, next_allowed_tools, and epoch binding. Includes signature_verified and constitution_bound flags for F1/F11 compliance.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | init | |
| nonce | No | ||
| actor_id | No | ||
| epoch_id | No | ||
| session_id | No | ||
| actor_signature | No | ||
| ack_irreversible | No | ||
| declared_model_key | No | ||
| previous_session_hash | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
arif_vault_sealDInspect
999_VAULT: Immutable ledger anchoring and cryptographic seal.
Writes terminal verdicts, session artifacts, and audit events to VAULT999 — the append-only constitutional ledger. Every entry is hashed, chained, and witnessed. Irreversible writes require explicit human ack (F1 Amanah). Dry-run mode is default for safety.
Modes: seal — Anchor a payload to the immutable ledger. verify — Cryptographically verify a prior vault entry. chain — Retrieve the Merkle chain tip and lineage. list — Enumerate entries scoped to the current session.
Parameters: mode — seal | verify | chain | list payload — JSON string to anchor (seal mode) ack_irreversible — Explicit human ack for permanent writes constitutional_chain_id — Chain hash for lineage verification judge_state_hash — Judge verdict hash that authorized this seal session_id — Governed session ID actor_id — Sovereign actor identifier ctx — FastMCP Context for progress reporting and elicitation
Returns: SealOutput with entry_id, chain_hash, timestamp, and permanence flag.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | seal | |
| payload | No | ||
| actor_id | No | ||
| session_id | No | ||
| ack_irreversible | No | ||
| judge_state_hash | No | ||
| constitutional_chain_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
command_centerAInspect
Use this when the user wants to open the arifOS Command Center.
This is the governed cockpit for constitutional AI operations across the arifOS federation (arifOS, A-FORGE, GEOX, WEALTH). It provides tabs for session status, thermodynamic vitals, constitutional judgment (888 Judge), forge dry-run simulation (010 Forge), cross-agent gateway handshake (666 Gateway), and vault audit (999 Vault).
Do not use for direct tool execution — use the specific canonical tool (e.g., arif_judge_deliberate, arif_ops_measure) when the user asks for a single action outside the cockpit context.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are limited, but description adds behavioral context: it opens a governed cockpit with multiple tabs for monitoring and governance, which is beyond what annotations convey. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with key info front-loaded. Every sentence adds value: usage, what the cockpit is, and exclusions. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema and no parameters, the description fully explains the tool's purpose and its role in the arifOS ecosystem, making it complete for an agent to decide when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. Description adds no parameter information, but baseline for zero-param tool is high. The description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Use this when the user wants to open the arifOS Command Center' and explains what the cockpit provides, clearly distinguishing it from sibling action tools by explicitly saying 'Do not use for direct tool execution — use the specific canonical tool'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use (to open the Command Center) and when not to use (direct tool execution), and lists alternatives by naming sibling tools like arif_judge_deliberate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_constitutional_healthGet Constitutional HealthARead-onlyInspect
Read-only constitutional health snapshot. Returns F1-F13 floor status, telemetry, and widget URI.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | No | global |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds value by specifying the exact output contents (F1-F13, telemetry, widget URI), which annotations do not cover. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences that front-load the purpose ('Read-only constitutional health snapshot') and immediately list output components. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are covered. However, the lack of parameter explanation and usage context makes the description incomplete for a tool with one optional parameter. Minimum viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has one parameter (session_id) with 0% description coverage. Description does not explain what session_id does or how it affects results, forcing the agent to infer its meaning from the default value alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies the tool returns a 'constitutional health snapshot' with specific components (F1-F13 floor status, telemetry, widget URI), which is both a specific verb and resource, distinguishing it from siblings like 'arif_heart_critique'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for obtaining health data but provides no guidance on when to use this tool versus alternatives (e.g., arif_sense_observe) or when not to use it. No explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_recent_verdictsList Recent VerdictsARead-onlyInspect
Read-only summary of the most recent constitutional verdicts. Phase 1: no write path exposed.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true. Description adds 'Phase 1: no write path exposed' which provides future context but doesn't contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with key information. No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one parameter and output schema. Description covers purpose and read-only nature but lacks parameter details and usage context relative to siblings. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter (limit) with no descriptions. Description does not explain its meaning or default behavior, despite low schema coverage (0%). Agent may not know how limit controls the result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it's a read-only summary of recent constitutional verdicts, distinguishing it from write operations and sibling tools like arif_judge_deliberate. Verb+resource description is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for reading recent verdicts, but no explicit when-to-use or when-not-to-use guidance. No comparison with siblings like get_constitutional_health.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
render_vault_sealRender Vault Seal WidgetBRead-onlyInspect
Render the arifOS constitutional health check widget from structured seal data. Sets _meta.ui.domain for ChatGPT sandbox rendering under domain.web-sandbox.oaiusercontent.com
| Name | Required | Description | Default |
|---|---|---|---|
| seal_data | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark readOnlyHint=true, and the description adds that it sets '_meta.ui.domain' for sandbox rendering, providing some behavioral context beyond annotations. However, it does not disclose potential errors from invalid seal_data or whether the function triggers any side effects beyond UI metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences: first states the primary purpose, second adds a key technical detail. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple (1 param, has output schema) and read-only, the description lacks details on the expected structure of seal_data or what the rendered widget presents, leaving room for ambiguity given similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the only parameter, 'seal_data'. The description only vaguely mentions 'structured seal data' without specifying format or required properties, failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Render') and the resource ('arifOS constitutional health check widget'), explicitly distinguishing it from siblings like 'arif_vault_seal' (data retrieval) and 'vault_seal_card' (likely another UI component).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'vault_seal_card' or 'get_constitutional_health'. Lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vault_seal_cardVault Seal Card DataARead-onlyInspect
Build structured constitutional seal data for ChatGPT widgets. Uses existing arifOS telemetry and optional floor overrides; no irreversible sealing occurs.
| Name | Required | Description | Default |
|---|---|---|---|
| floors | No | Floor scores F1-F13 as dict of float values. | |
| verdict | No | Constitutional verdict: SEAL, PARTIAL, VOID, or HOLD. | SEAL |
| witness | No | Tri-witness scores: human, ai, earth. | |
| trace_root | No | Trace root hash for audit trail. | |
| policy_digest | No | Policy digest for constitutional verification. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description reinforces 'no irreversible sealing occurs.' Additionally, it adds context about using telemetry and optional overrides, enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. Every phrase is meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 optional parameters, output schema present, annotations for read-only), the description is complete. It clearly states what the tool produces, its inputs (telemetry, optional overrides), and its safe nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description mentions 'optional floor overrides' which maps to the floors parameter, but adds no significant meaning beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool builds structured constitutional seal data for ChatGPT widgets, using telemetry and optional overrides, and explicitly notes that no irreversible sealing occurs. This distinguishes it from sibling tools like arif_vault_seal (actual sealing) and render_vault_seal (rendering).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies safe usage by stating 'no irreversible sealing occurs' and 'uses existing arifOS telemetry and optional floor overrides,' but does not explicitly mention when to use this tool over alternatives or provide exclusion criteria. The context is clear but lacks explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!