arifOS — Constitutional AI Kernel

Name: arifOS — Constitutional AI Kernel
Author: ariffazil

by io.github.ariffazil

Overview Discussions Admin

Server Details

Constitutional AI kernel with 13 MCP tools, 888_JUDGE verdict pipeline, and VAULT999 ledger.

Ownership verified

Status: Healthy
Uptime: 92.5% over 76 days
Last Tested: 2026-11-01 14:22
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: ariffazil/APEX
GitHub Stars: 0

TDQS

A3.8/5.0

Scored 2026-10-29 12:10 across 9 tools

Disambiguation5/5

Each tool occupies a distinct lane: session lifecycle (arif_init), external evidence (arif_observe), internal reasoning (arif_think), routing (arif_route), policy adjudication (arif_judge), authorized mutation (arif_forge), irreversible audit append (arif_seal), memory (arif_memory), and agent messaging (arif_report). The write-oriented tools are clearly separated by purpose and authorization flow, so an agent can select among them without confusion.

Naming Consistency5/5

All nine tools use the same arif_ prefix followed by a single concise verb or noun, producing a highly predictable namespace. There is no mixing of camelCase, snake_case, or inconsistent verb styles.

Tool Count5/5

Nine tools is well within the ideal 3–15 range and each corresponds to a meaningful part of the governed execution loop. No tool appears redundant or purely decorative.

Completeness4/5

The core lifecycle is covered: init, observe, think, route, judge, forge, seal, plus memory and reporting. Minor gaps remain, such as no explicit session termination/revocation, no memory forget operation, and no direct read access to the audit ledger beyond implicit inspection.

Available Tools

9 tools

arif_forge777 Forge · Execute GateB

Destructive

Inspect

Apply an authorized system modification. Requires a valid seal_verdict_id obtained from arif_judge. Mode: dry_run (preview impact without execution), apply (execute authorized change). Outputs: execution receipt.

Name	Required	Description	Default
`mode`	No	'engineer' (default) — plan and apply the work; 'dry_run' — preview what would happen, nothing is applied; 'query' — read-only questions about the workspace; 'write' — write files; 'generate' — generate code or content; 'commit' — commit prepared work; 'recall' — retrieve past forge artifacts.	engineer
`query`	No	The task in plain language when no manifest is supplied, e.g. 'restart the gateway service'.
`plan_id`	No	Plan id from arif_think's plan mode, when executing an approved plan.
`actor_id`	No	Your agent identity, e.g. 'kimi-code/FI-008' — recorded in the audit log.
`manifest`	No	Required for engineer (the default mode), write, and generate: the work order (usually JSON or markdown) describing exactly what to build or change — the more specific, the tighter the gate. mode=dry_run accepts the manifest or a plain-language query; mode=query uses query instead.
`session_id`	No	Session id returned by arif_init; scopes this execution to your governed session.
`arif_ack_id`	No	Acknowledgment id from a prior step, for multi-step execution chains.
`artifact_id`	No	Id of an existing artifact (from an earlier forge or judge response) that this call operates on.
`session_token`	No	Session Continuity Token (SCT) returned by arif_init — proves the session is yours.
`vault_entry_id`	No	Id of the permanent-ledger entry linked to this execution, when one already exists.
`seal_verdict_id`	No	The SEAL verdict id arif_judge returned — without it, nothing is executed.
`ack_irreversible`	No	Set true to confirm you accept this execution cannot be undone, when the judged action was irreversible.
`judge_state_hash`	No	Hash string from the arif_judge SEAL response — proves the verdict has not been tampered with.
`approved_action_hash`	No	Hash of the exact action that was judged — execution is refused if what you submit differs from it.
`constitutional_chain_id`	No	Id of the evidence chain (observe→think→judge) that led to the SEAL — copy it from the judge response.

Output Schema

Name	Required	Description
`meta`	Yes
`tool`	Yes
`result`	Yes
`status`	Yes
`delta_S`	No
`reasons`	Yes
`actor_id`	No
`timestamp`	Yes
`session_id`	No
`nine_signal`	Yes
`output_policy`	No
`stage_progression`	No
`philosophical_anchor`	No

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds real context beyond that — the authorization gate and the dry_run preview path — but says nothing about what happens on refusal, what 'impact' a preview returns, or the irreversibility acknowledgment flow.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short, front-loaded sentences with no filler: purpose, precondition, modes, output. Efficient, though the mode sentence is where the inaccuracy was introduced — brevity at the cost of correctness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-parameter destructive tool the description is thin, but the schema is fully documented and an output schema exists, so the agent can recover most missing detail. What it cannot recover is the tamper-hash / constitutional-chain requirement, which the prose never mentions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so a baseline of 3 would apply, but the description actively misinforms: it lists 'apply' as a mode when the enum contains engineer/query/write/generate/commit/recall/dry_run and no 'apply'. An agent following the prose would submit an invalid mode. It adds no meaning for the hash, session, or chain parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Apply an authorized system modification' — and distinguishes itself from arif_judge by requiring the verdict that judge produces. The addition of the two modes and the receipt output confirms what kind of operation this is, though the mode list it names is wrong.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives one strong prerequisite: a valid seal_verdict_id from arif_judge, which implies the judge→forge sequence. But it only explains 2 of the 7 modes the schema actually allows, and gives no guidance on when to prefer this over siblings like arif_delegate or arif_seal.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

arif_init000 Init · Kernel SessionAInspect

Ignite or resume a governed session. Returns session_id and session_token required for subsequent operations. Modes: init (default new session), preflight (inspect existing session), resume (continue active session). Outputs: session credentials and allowed next tools.

Name	Required	Description	Default
`mode`	No	What to do: 'init' (default) starts a new governed session; 'preflight' checks an existing session's state without creating one; 'resume' re-attaches to the session in session_id; 'validate' re-checks credentials; 'canary' is a transport probe; 'triage' reads session state; 'epoch_open'/'epoch_seal' bracket a long working window; 'light' is a minimal session; 'opt_out' records a privacy opt-out.	init
`nonce`	No	One-time random string (e.g. a UUID) making this request unique; protects against replay of the same call.
`intent`	Yes	Required. Plain-language statement of what this session is for, e.g. 'repair the failing MCP tests'. A session without a stated purpose is refused (F1 Amanah). Recorded for audit.
`context`	No	JSON object of background facts to bind into the session, e.g. {"repo": "arifOS", "task": "fix-tests"}.
`payload`	No	Extra mode-specific data as a JSON object; the mode's response tells you which fields it expects.
`tooling`	No	JSON list of the tools you can use, e.g. ["Bash", "Read"] — lets the kernel scope what it will permit you. Also accepts an object like {"requested_capabilities": [...]}.
`verbose`	No	Legacy on/off verbosity ('true'/'false'); prefer verbosity.
`actor_id`	No	Your agent identity, e.g. 'kimi-code/FI-008' or 'claude/sonnet'. Recorded in the audit log so this action is attributed to you.
`epoch_id`	No	Optional id grouping related sessions into one long-running epoch, e.g. '2026-H2-ops'.
`evidence`	No	JSON list of facts you have already verified, e.g. [{"fact": "pytest 299 passed", "source": "CI run"}] — carried into the session record. Also accepts a single object.
`trace_id`	No	Correlation id of your choosing (e.g. 'req-8f3a') — lets you find this call later across kernel logs and organ systems.
`verbosity`	No	How detailed responses should be: 'minimal' (default), 'standard', or 'full'.	minimal
`session_id`	No	Session id returned by arif_init (looks like 'sess-…'). Pass it on every call after init so the action is attributed to your governed session.
`agent_policy`	No	JSON constraints on your own behavior, e.g. {"autonomy": "reversible_only", "forbidden": ["git push"]}.
`auth_context`	No	JSON carrying external authentication material, e.g. {"token_class": "bearer", "issuer": "github"} — used for gating.
`counterparty`	No	JSON describing the other party in a two-agent exchange, e.g. {"agent_id": "hermes/1", "role": "verifier"}.
`sovereign_id`	No	Identifier of the human principal you act for, when acting under their explicit delegation.
`session_token`	No	Session Continuity Token (SCT) — the credential string arif_init returned alongside session_id. Pass it back on follow-up calls to prove the session is yours; without it the kernel treats you as unauthenticated.
`actor_signature`	No	Cryptographic signature over the request, if your agent holds a key — proves the call genuinely came from actor_id. Omit if you have no key.
`caller_actor_id`	No	If you are calling on behalf of another agent, that agent's id — builds a delegation chain for the audit log.
`delegation_mode`	No	Contract governing delegated calls, e.g. 'read_only' or 'governed'.
`idempotency_key`	No	Client-chosen key (e.g. 'job-42-attempt-1'). Retrying with the same key will not repeat the effect — safe retries on flaky networks.
`ack_irreversible`	No	Set true to acknowledge that session records are permanent audit artifacts and cannot be deleted afterwards.
`executor_actor_id`	No	Id of the agent that will actually carry out work under this session's permissions, if different from actor_id.
`declared_model_key`	No	The model you run on, e.g. 'zai-coding-plan/glm-5.3'. Informational only — the kernel records but never trusts it.
`client_capabilities`	No	JSON declaring what your client supports, e.g. {"transports": ["http"], "protocol": "2025-11-25"}.
`requested_authority`	No	The highest class of action you may take: 'OBSERVE_ONLY' (read-only, default) or a higher governed class granted by your policy.	OBSERVE_ONLY
`previous_session_hash`	No	Hash string returned when your previous session closed; supplying it chains this session to that one, proving continuity.

Output Schema

Name	Required	Description
`meta`	Yes
`tool`	Yes
`result`	Yes
`status`	Yes
`delta_S`	No
`reasons`	Yes
`actor_id`	No
`timestamp`	Yes
`session_id`	No
`nine_signal`	Yes
`output_policy`	No
`stage_progression`	No
`philosophical_anchor`	No

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate this is a write operation (readOnlyHint=false) that is not destructive and not idempotent. The description adds that it returns session credentials and allowed next tools, but omits key behavioral details like the permanent audit trail (mentioned only in the ack_irreversible parameter) and the refusal behavior when intent is missing. With annotations present, this is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core purpose and mode list. No superfluous text. However, for a tool with 28 parameters, it could be slightly more structured, but it remains efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich schema (100% coverage), output schema, and annotations, the description provides enough context to call the tool: the purpose, required outputs, and mode variants. It could mention the required 'intent' parameter or the permanence of records, but these are in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage, so the parameters are fully documented. The description does not add any new semantic detail beyond the schema, only restating the modes. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States the action (ignite/resume) and the resource (governed session), and clarifies that it returns session_id and session_token required for subsequent operations. This distinguishes it as an entry point, though it doesn't explicitly name sibling tools it replaces or avoids.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the mode options (init, preflight, resume) and indicates that a session is required for subsequent operations. However, it does not explicitly state when to use this tool versus other arif tools, nor does it warn against using it in a wrong context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

arif_judge666 Judge · VerdictA

Read-only

Inspect

Evaluate proposed operations against policy and safety constraints. Weighs blast radius, reversibility, and permission level. Returns binding verdict (SEAL for approved, HOLD for blocked, SABAR for awaiting conditions). Approval verdict is required prior to calling arif_forge. Outputs: evaluation verdict and authorization receipt.

Name	Required	Description	Default
`mode`	No	'judge' (default) — render a verdict on candidate; 'intercept' — pre-flight gate before an action runs; 'validate' — re-check a prior verdict; 'hold' — place an action into a cooling period; 'escalate' — refer the decision to the human owner.	judge
`nonce`	No	One-time random string (e.g. a UUID) making this request unique; protects against replay of the same call.
`domain`	No	Subject area for claim evaluation, e.g. 'geoscience' or 'finance'.
`key_id`	No	Which of your registered keys produced actor_signature, e.g. 'key-1'.
`actor_B`	No	Your calibrated confidence for a prediction, 0.0–1.0 (Brier-style score component).
`actor_id`	No	Your agent identity, e.g. 'kimi-code/FI-008' or 'claude/sonnet'. Recorded in the audit log so this action is attributed to you.
`evidence`	No	The facts the verdict should rest on — a JSON list like [{"fact": "tests pass", "source": "CI"}], or an object.
`actor_Phi`	No	JSON map of supporting signals about you, e.g. {"consistency": 0.9, "track_record": 0.7}.
`candidate`	No	The action or claim being judged, stated plainly, e.g. 'delete table users in prod'.
`claim_text`	No	The exact claim sentence under judgment, e.g. 'uptime exceeded 99% in August'.
`session_id`	No	Session id returned by arif_init (looks like 'sess-…'). Pass it on every call after init so the action is attributed to your governed session.
`action_tier`	No	How risky the action is: 'standard', 'high', or 'critical' — higher tiers demand stronger evidence.	standard
`claim_class`	No	Epistemic strength of the claim: 'OBS' (directly observed), 'DER' (derived from observations), 'INT' (interpreted), 'SPEC' (speculative), 'UNKNOWN' (cannot witness — honest null; maps to TruthClass.UNK, weight 0.30, cannot authorize mutation). RULE absence-null: 'not in my knowledge' is NOT evidence a claim is false — label UNKNOWN, never FALSE.
`niat_params`	No	JSON intent-calibration settings, e.g. {"sincerity": 0.8, "stated_goal": "verify the claim"}.
`action_class`	No	Kind of action under judgment: 'OBSERVE' (read-only), 'DRAFT' (compose text), 'MUTATE' (change state), 'IRREVERSIBLE' (permanent).
`blast_radius`	No	Who or what the action can affect: 'self', 'session', 'organ', or 'federation'.
`seal_purpose`	No	One sentence saying why this verdict/record must exist, e.g. 'closing deployment D-17'. Stored permanently alongside the record.
`session_token`	No	Session Continuity Token (SCT) — the credential string arif_init returned alongside session_id. Pass it back on follow-up calls to prove the session is yours; without it the kernel treats you as unauthenticated.
`context_source`	No	Where the candidate came from: 'session', 'file', or 'memory'.
`heart_critique`	No	JSON result of an ethics/dignity check, e.g. {"coercion": false, "dignity": 0.9} — feeds the verdict.
`vault_entry_id`	No	Id of the permanent-ledger entry this verdict should attach to (from an earlier arif_seal response).
`actor_signature`	No	Cryptographic signature over the request, if your agent holds a key — proves the call genuinely came from actor_id. Omit if you have no key.
`authority_token`	No	Authority credential CLAIMED for this proposal (payload field, not proof). The judge records the claim and still verifies identity separately — an unverified token never upgrades an OBSERVE_ONLY session, and verdicts remain binding regardless of what the token asserts.
`entropy_pathway`	No	How the action changes system order: 'reduces', 'neutral', or 'increases' complexity.
`entropy_receipt`	No	JSON receipt from an entropy computation, bound to this judgment.
`authority_effect`	No	What permission a SEAL verdict would grant, e.g. 'execute forge plan P-9'.
`cooldown_entry_id`	No	Id of an existing cooling-period record to consult before this action may proceed.
`sovereign_receipt`	No	Reference to the human owner's explicit approval, for the rare case where they have already decided directly.
`reversibility_level`	No	How hard the action would be to undo: 'reversible', 'hard', or 'irreversible'.
`requested_capability`	No	The specific capability being requested, e.g. 'forge.execute' — checked against the capability registry.
`constitutional_chain_id`	No	Id of the evidence chain this call belongs to (observe→think→judge→seal). Copy it from the earlier step's response to link the steps together.

Output Schema

Name	Required	Description
`meta`	Yes
`tool`	Yes
`result`	Yes
`status`	Yes
`delta_S`	No
`reasons`	Yes
`actor_id`	No
`timestamp`	Yes
`session_id`	No
`nine_signal`	Yes
`output_policy`	No
`stage_progression`	No
`philosophical_anchor`	No

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds useful behavioral context beyond the annotations: it explains the factors weighed, the binding nature of the verdict, the verdict labels, and that it produces an authorization receipt. It does not detail authentication/session requirements, but the annotations and schema already cover safety and parameter-level behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four compact sentences, front-loads the core purpose, then states the verdict semantics and the key workflow prerequisite. Every sentence contributes useful information without repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich schema and output schema, the description covers the tool's purpose, verdict model, key prerequisite, and outputs adequately. It could say more about the mode parameter and session/auth expectations, but those are already heavily documented in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents all 31 parameters in detail. The description adds only a high-level reference to blast radius, reversibility, and permission level, which are already represented in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: evaluate proposed operations against policy and safety constraints. It also names the concrete verdict outputs and links the tool to the workflow by saying approval is required before arif_forge.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly indicates when the tool is needed: prior to calling arif_forge. It does not explicitly describe when not to use it or name alternative sibling tools beyond the forge prerequisite, so it falls short of full when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

arif_memoryMemory Governor · KernelB

Destructive

Inspect

Access and maintain persistent institutional knowledge across sessions. Modes: recall (retrieve relevant context), inspect (audit stored decisions), remember (store verified lesson). Mutations to permanent tiers require explicit approval. Outputs: scoped memory entries.

Name	Required	Description	Default
`mode`	No	'recall' (default) — semantic search of stored memories; 'inspect' — read one memory in full; 'attest' — vouch for a memory's accuracy; 'remember' — store new text; 'promote' — move a memory up a tier; 'revise' — replace a memory's text; 'forget' — remove a memory (gated); 'audit' — integrity scan; 'metabolize' — compact and consolidate tiers.	recall
`tier`	No	Which memory tier to target, 'L1'–'L6' (L1 = hot working memory, L6 = sealed canon).
`query`	No	What to search for, in plain language (mode=recall/audit), e.g. 'past deploy rollback steps'.
`content`	No	The text to store (mode=remember) — write it as a self-contained lesson or fact.
`payload`	No	Extra mode-specific fields as JSON — e.g. {"truth_class": "DERIVED", "provenance": "CI log"} for remember.
`to_tier`	No	Destination tier when promoting, e.g. 'L4'.
`actor_id`	No	Your agent identity, e.g. 'kimi-code/FI-008' — recorded in the audit log.
`lease_id`	No	Id of a short-lived permission grant (lease) authorizing this write, when one was issued to you.
`trace_id`	No	Correlation id of your choosing (e.g. 'req-8f3a') to find this call later in the logs.
`memory_id`	No	UUID of the memory entry to inspect/revise/forget — it was returned when the memory was created or last listed.
`session_id`	No	Session id returned by arif_init; attributes this call to your governed session.
`new_content`	No	Replacement text for the memory (mode=revise) — must refer to the same memory_id.
`session_token`	No	Session Continuity Token (SCT) returned by arif_init — proves the session is yours.
`human_approval`	No	Set true ONLY when the human owner explicitly approved this promote/forget — the gate refuses without it.
`idempotency_key`	No	Client-chosen key (e.g. 'memo-42'); retries with the same key will not store duplicates.

Output Schema

Name	Required	Description
`meta`	Yes
`tool`	Yes
`result`	Yes
`status`	Yes
`delta_S`	No
`reasons`	Yes
`actor_id`	No
`timestamp`	Yes
`session_id`	No
`nine_signal`	Yes
`output_policy`	No
`stage_progression`	No
`philosophical_anchor`	No

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds useful behavioral context beyond annotations by stating that mutations to permanent tiers require explicit approval and that outputs are scoped memory entries. But it only describes three of nine modes and does not explain the destructive effects of forget or revise beyond what the annotations and schema already imply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded with the core purpose, followed by modes, approval requirements, and outputs. It is efficient, though the partial mode list is an under-specification rather than a conciseness strength.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 15-parameter, nine-mode tool with destructive capabilities, the description is only minimally adequate. It omits six modes, does not clarify sibling alternatives such as arif_recall, and does not explain the approval or lease mechanics, though the schema and output schema carry much of that detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all 15 parameters are already documented in the input schema. The description adds little parameter-level meaning, listing only three modes and not explaining tier, query, content, or approval parameters beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: access and maintain persistent institutional knowledge across sessions. It lists three modes, making the tool's broad purpose clear, but it does not differentiate this tool from the sibling arif_recall, which likely overlaps with the recall mode.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through the listed modes and the note that mutations to permanent tiers require explicit approval. However, it gives no explicit guidance on when to choose this tool versus arif_recall or other siblings, and it does not mention when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

arif_observe111 Observe · Sense RealityB

Read-onlyIdempotent

Inspect

Collect evidence, reality observations, and operational facts with provenance. Modes: search (web literature queries), fetch (targeted URL retrieval), vitals (system metrics). Requires valid session credentials. Outputs: structured facts, source attribution, and epistemic tags.

Name	Required	Description	Default
`uri`	No	Registered resource URI to read when mode=resource_read, e.g. 'arifos://vitals' or 'arifos://carry-forward'.
`url`	No	Exact URL to retrieve when mode=fetch, e.g. 'https://example.com/report.pdf'.
`mode`	No	'search' (default) — web/literature query; 'fetch' — retrieve one URL with provenance; 'hybrid_discovery' — combine sources; 'ingest' — absorb a document; 'compass'/'atlas' — guided navigation; 'entropy_dS' — measure system change; 'vitals' — kernel machine telemetry; 'resource_read' — read a registered arifos:// resource by uri; 'resource_search' — search/list registered resources.	search
`query`	No	What to look for, in plain language, e.g. 'TDQS scoring rubric MCP'.
`layers`	No	Restrict where to look, e.g. ["web"] or ["canon", "memory"]; omit to search everything available.
`actor_id`	No	Your agent identity, e.g. 'kimi-code/FI-008' or 'claude/sonnet'. Recorded in the audit log so this action is attributed to you.
`session_id`	No	Session id returned by arif_init (looks like 'sess-…'). Pass it on every call after init so the action is attributed to your governed session.
`result_limit`	No	Maximum number of results to return in search modes; default 10.
`session_token`	No	Session Continuity Token (SCT) — the credential string arif_init returned alongside session_id. Pass it back on follow-up calls to prove the session is yours; without it the kernel treats you as unauthenticated.

Output Schema

Name	Required	Description
`meta`	Yes
`tool`	Yes
`result`	Yes
`status`	Yes
`delta_S`	No
`reasons`	Yes
`actor_id`	No
`timestamp`	Yes
`session_id`	No
`nine_signal`	Yes
`output_policy`	No
`stage_progression`	No
`philosophical_anchor`	No

TDQS

B3.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds real value beyond them: an authentication requirement and the shape of what is returned (structured facts, source attribution, epistemic tags). It does not disclose rate limits, side effects of the 'ingest' mode, or failure behavior, keeping it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences with the purpose front-loaded and no filler. It is efficient, but the mode list is selective (3 of 10) rather than signaled as partial, which mildly misleads about scope.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values needn't be explained, and credential requirements are covered. However, for a 10-parameter, 10-mode tool, seven modes (hybrid_discovery, ingest, compass, atlas, entropy_dS, resource_read, resource_search) go unmentioned, leaving a significant capability gap for correct mode selection.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including a fully documented mode enum, so the schema already carries parameter meaning and baseline 3 applies. The description reinforces the provenance/credentials framing but adds no syntax or format detail beyond what the schema states, and it omits any mention of actor_id, session_id, session_token, or layers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a clear verb+resource ("collect evidence, reality observations, and operational facts with provenance") and enumerates three concrete modes (search, fetch, vitals), so the agent knows the tool is a sensing/retrieval surface. It stops short of distinguishing itself from siblings like arif_memory or arif_think, so an agent must infer whether memory lookup belongs here or there.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only usage guidance is the prerequisite "Requires valid session credentials"; there is no statement of when to choose arif_observe over arif_memory, arif_route, or arif_think, and no exclusions. The mode list is a taxonomy of capabilities, not a decision rule for selecting among them, so the agent must reverse-engineer intent from the schema.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

arif_reportArif ReportAInspect

AGENT REPORT LANE · File or read reports between agents without involving the human. Use when your work is done, when you are blocked by another agent, or when you need to tell peers a fact. modes: report (file), inbox (read peers), ack, flush, stats. kind=fyi|peer|done|claim stay in the peer lane; ONLY kind=decision or kind=blocked reach the sovereign, and only in one coalesced message. Reports are SELF_REPORTED — probe before relying on one.

Name	Required	Default
`body`	No
`kind`	No	fyi
`mode`	No	report
`force`	No
`limit`	No
`since`	No
`sender`	No
`dry_run`	No
`subject`	No
`actor_id`	No
`evidence`	No
`platform`	No
`_envelope`	No
`mark_read`	No
`report_id`	No
`thread_id`	No
`session_id`	No
`needs_human`	No
`session_token`	No

TDQS

A3.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=false and destructiveHint=false, so write capability is already known; the description adds genuinely new behavior: coalescing into a single sovereign message, per-kind routing lanes, and the caution that reports are SELF_REPORTED and should be probed before being trusted. That last point is real operational context beyond the annotations. No contradiction with the declared hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the lane identity and trigger conditions, then mode and kind semantics, then the self-reported caveat. It is dense and telegraphic but every clause carries routing or safety information; nothing reads as filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex multi-mode tool with 19 undocumented parameters and no output schema. The description covers the filing/escalation story well but says nothing about how to actually drive inbox mode (pagination via limit/since, thread_id, mark_read) or what any mode returns, so an agent could misfire on the read paths.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 19 parameters, so the description carries the full burden. It documents only `mode` (report/inbox/ack/flush/stats) and `kind` (fyi/peer/done/claim/decision/blocked) enumerations; the remaining 17 parameters — limit, since, report_id, thread_id, mark_read, body, force, dry_run, and others — are explained nowhere, leaving read-side invocation guesswork.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb+resource — file or read reports between agents — and scopes it with 'without involving the human', which establishes a distinct lane. It does not explicitly contrast itself with siblings like arif_route or arif_memory, so an agent must infer the boundary from the 'peer lane vs sovereign' framing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit trigger conditions ('when your work is done', 'when you are blocked by another agent', 'when you need to tell peers a fact') and a routing rule for which kinds escalate to the sovereign. It never names an alternative arif_* tool to use instead, so the when-not-this-tool side is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

arif_route444 Route · Intent→OrganB

Read-onlyIdempotent

Inspect

Classify intent and route tasks to domain organs (GEOX for Earth science, WEALTH for capital markets, WELL for human vitality, A-FORGE for execution). Requires valid session credentials. Outputs: organ dispatch envelope.

Name	Required	Description	Default
`mode`	No	'route' (default) — classify intent and recommend the target organ; 'triage' — rank a batch of intents; 'delegate' — prepare an A2A handoff; 'status' — surface organ state; 'kernel' — kernel-level status; 'metabolize' — feed routing outcomes to arifFlow. Routing only recommends — execution is arif_forge after a SEAL verdict.	route
`task`	No	Alias for intent (backward compat).
`organ`	No	Optional explicit organ override. If provided, intent matching is skipped and this organ is used directly.
`intent`	No	Natural-language description of what the user wants. e.g. "interpret this seismic section", "assess portfolio risk"
`actor_id`	No	Your agent identity, e.g. 'kimi-code/FI-008' or 'claude/sonnet'. Recorded in the audit log so this action is attributed to you.
`arguments`	No	Arguments to pass to organ_tool.
`mission_id`	No	Explicit human-cockpit mission binding (investigate\|interpret\| decide\|build\|monitor\|remember). When set, skips keyword classification and binds the six-mission plan. Preferred over free-text when the agent already knows the mission.
`organ_tool`	No	The tool name on the target organ to call. If absent, returns routing decision only (no bridge call).
`session_id`	No	Session id returned by arif_init (looks like 'sess-…'). Pass it on every call after init so the action is attributed to your governed session.
`session_token`	No	Session Continuity Token (SCT) — the credential string arif_init returned alongside session_id. Pass it back on follow-up calls to prove the session is yours; without it the kernel treats you as unauthenticated.
`contract_c_kwargs`	No	Extra keyword arguments passed through to the organ tool call, as a JSON object.

Output Schema

Name	Required	Description
`meta`	Yes
`tool`	Yes
`result`	Yes
`status`	Yes
`delta_S`	No
`reasons`	Yes
`actor_id`	No
`timestamp`	Yes
`session_id`	No
`nine_signal`	Yes
`output_policy`	No
`stage_progression`	No
`philosophical_anchor`	No

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that — 'Requires valid session credentials' and the dispatch-envelope output — but says nothing about failure modes when credentials are missing or what happens if organ_tool is absent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the action and organ list front-loaded and the credential prerequisite following. Nothing is wasted, though the organ acronyms are packed inline without explanation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 11 parameters, six modes, and an output schema, the description covers only the surface. Since an output schema exists it needn't explain return values, but the mode taxonomy and the recommend-vs-execute boundary are essential context that only the schema supplies.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all 11 parameters, including the six routing modes, are fully documented in the schema. The description adds no parameter-level meaning beyond what the schema already provides, which is the baseline-3 case.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Classify intent and route tasks') and resource (domain organs: GEOX, WEALTH, WELL, A-FORGE), so the core action is unambiguous. It does not, however, distinguish this from close siblings such as arif_delegate (handoff) or arif_forge (execution), leaving that routing logic to the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by naming the organs and the credential requirement, but it never says when to pick this over arif_delegate, arif_think, or arif_forge. The critical 'routing only recommends — execution is arif_forge after a SEAL verdict' guidance lives in the schema's mode parameter, not in the description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

arif_seal999 Seal · VAULT999B

Destructive

Inspect

Append verified outcome or lesson to the immutable audit ledger. Requires ack_irreversible=true to confirm permanent commit. Outputs: immutable ledger entry receipt.

Name	Required	Description	Default
`mode`	No	'seal' (default) — append a permanent entry; 'verify' — check one entry; 'ledger' — read the ledger head; 'changelog' — recent appends; 'audit' — integrity check; 'session_close' — close out a session into the ledger.	seal
`nonce`	No	One-time random string (e.g. a UUID) making this request unique; protects against replay of the same call.
`payload`	No	The content to store forever, as a string (usually JSON-serialized) — the outcome, lesson, or record itself. Required for the write modes (seal, session_close); pure reads (verify, ledger, changelog, audit) may omit it.
`actor_id`	No	Your agent identity, e.g. 'kimi-code/FI-008' or 'claude/sonnet'. Recorded in the audit log so this action is attributed to you.
`session_id`	No	Session id returned by arif_init (looks like 'sess-…'). Pass it on every call after init so the action is attributed to your governed session.
`drift_events`	No	JSON list of deviations observed, e.g. [{"what": "schema drift", "where": "tools/list"}] — stored with the record.
`seal_purpose`	No	One sentence saying why this verdict/record must exist, e.g. 'closing deployment D-17'. Stored permanently alongside the record.
`witness_type`	No	Who witnessed the sealed fact: 'ai', 'human', or 'external' system.	ai
`session_token`	No	Session Continuity Token (SCT) — the credential string arif_init returned alongside session_id. Pass it back on follow-up calls to prove the session is yours; without it the kernel treats you as unauthenticated.
`constitutional`	No	JSON block of governance metadata (floors consulted, chain references) — normally built by the kernel, not by callers.
`actor_signature`	No	Cryptographic signature over the request, if your agent holds a key — proves the call genuinely came from actor_id. Omit if you have no key.
`ack_irreversible`	No	Set true to confirm you understand sealed entries are PERMANENT — they can never be edited or removed.
`judge_state_hash`	No	Hash string from the arif_judge SEAL response — ties this entry to the verdict that authorized it.
`constitutional_chain_id`	No	Id of the evidence chain this call belongs to (observe→think→judge→seal). Copy it from the earlier step's response to link the steps together.

Output Schema

Name	Required	Description
`meta`	Yes
`tool`	Yes
`result`	Yes
`status`	Yes
`delta_S`	No
`reasons`	Yes
`actor_id`	No
`timestamp`	Yes
`session_id`	No
`nine_signal`	Yes
`output_policy`	No
`stage_progression`	No
`philosophical_anchor`	No

TDQS

B3.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and non-idempotent, and the description reinforces this with the immutability framing and the mandatory ack flag, plus it names the receipt output. It stops short of noting that the read modes on this same tool are non-destructive, so the safety picture is only partly drawn.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the action and immediately followed by the hard prerequisite. Nothing is padded, though the brevity comes at the cost of omitting the mode-selection surface entirely.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema and 100%-documented param schema cover return values and per-parameter meaning, so little is owed there. But for a 14-parameter, six-mode tool the description describes only the seal path, leaving the read/verify/audit behaviors and the judge-to-seal chaining (judge_state_hash, constitutional_chain_id) undisclosed at the description level.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and each of the 14 parameters already carries a detailed description, so the schema does the heavy lifting. The description adds only the ack_irreversible requirement, which the schema itself also explains — baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Append verified outcome or lesson to the immutable audit ledger' — clear what gets written and where it goes. It does not differentiate this tool from siblings such as arif_judge or arif_report, which also produce verdict/evidence artifacts, so the agent cannot easily tell which to pick.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only usage instruction is the ack_irreversible=true prerequisite for the permanent-commit path. Nothing says when to seal versus judge, report, or remember, and the description never mentions the mode enum ('verify', 'ledger', 'changelog', 'audit', 'session_close'), so an agent would reasonably assume this is write-only and miss five of its six behaviors.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

arif_think333 Think · MindB

Read-onlyIdempotent

Inspect

Execute structured reasoning and plan formulation. Decomposes inquiries into verified derivations. Modes: reason (inquiry breakdown), plan (drafting multi-step execution steps), verify (logical proof check). Requires valid session credentials. Outputs: structured reasoning record.

Name	Required	Description	Default
`mode`	No	'reason' (default) — decompose a question; 'reflect' — self-review of prior reasoning; 'verify' — check a derivation; 'axioms' — surface hidden assumptions; 'plan'/'plan_review'/'plan_approve'/'refactor_plan' — execution-plan lifecycle; 'metabolize' — consolidate past reasoning; 'simulate' — what-if; 'wonder' — open exploration; 'atlas' — map the problem space.	reason
`query`	No	The question, claim, or problem to reason about, in plain language.
`context`	No
`plan_id`	No	Plan reference from an earlier plan-mode response — needed for the review/approve/refactor steps.
`actor_id`	No	Your agent identity, e.g. 'kimi-code/FI-008' or 'claude/sonnet'. Recorded in the audit log so this action is attributed to you.
`evidence`	No
`session_id`	No	Session id returned by arif_init (looks like 'sess-…'). Pass it on every call after init so the action is attributed to your governed session.
`witness_type`	No	Who vouches for the reasoning record: 'ai' (default), 'human', or 'external' system.	ai
`session_token`	No	Session Continuity Token (SCT) — the credential string arif_init returned alongside session_id. Pass it back on follow-up calls to prove the session is yours; without it the kernel treats you as unauthenticated.

Output Schema

Name	Required	Description
`meta`	Yes
`tool`	Yes
`result`	Yes
`status`	Yes
`delta_S`	No
`reasons`	Yes
`actor_id`	No
`timestamp`	Yes
`session_id`	No
`nine_signal`	Yes
`output_policy`	No
`stage_progression`	No
`philosophical_anchor`	No

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered elsewhere. The description adds that valid session credentials are required and that a 'structured reasoning record' comes back, but it does not disclose mode-specific side effects — notably whether 'plan_approve' or 'metabolize' alter stored state, which reads in tension with readOnlyHint=true, or that actions are attributed/audited.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short, front-loaded sentences with no filler: purpose, mechanism, modes, credential requirement, output. The partial mode list ('reason, plan, verify') is compact but slightly hazardous, since it implies a three-mode tool when the schema exposes twelve.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output contract is covered by an existing output schema, so return values need no prose. However, a twelve-mode reasoning tool with a multi-step plan lifecycle (plan → plan_review → plan_approve → refactor_plan) needs sequencing guidance and a note that arif_init must precede these calls; the description gives neither, leaving the agent to reverse-engineer workflow from parameter descriptions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 78%, so the schema already documents mode, query, plan_id, actor_id, session_id and session_token thoroughly. The description merely repeats three mode names that the schema enum already expands on, and adds nothing about context, evidence, witness_type, or the init-to-session_token ordering the schema hints at.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource ('Execute structured reasoning and plan formulation', 'Decomposes inquiries into verified derivations') and names three modes, so the agent knows this is a reasoning/planning kernel rather than a search or retrieval tool. It stops short of distinguishing itself from siblings like arif_judge or arif_delegate, which plausibly overlap with verify/plan work.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Mode names imply usage ('reason' for inquiry breakdown, 'plan' for drafting steps, 'verify' for proof check), but there is no explicit when-to-use vs when-not, and no routing to arif_judge, arif_route, or arif_memory for overlapping needs. The remaining nine modes are never mentioned, so an agent cannot infer when to pick 'atlas' or 'metabolize' from the description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 29, 2026

Changedarif_observe3 fields changed

changedInput schema / properties / mode / description

Previous value: -"'search' (default) — web/literature query; 'fetch' — retrieve one URL with provenance; 'hybrid_discovery' — combine sources; 'ingest' — absorb a document; 'compass'/'atlas' — guided navigation; 'entropy_dS' — measure system change; 'vitals' — kernel machine telemetry."New value: +"'search' (default) — web/literature query; 'fetch' — retrieve one URL with provenance; 'hybrid_discovery' — combine sources; 'ingest' — absorb a document; 'compass'/'atlas' — guided navigation; 'entropy_dS' — measure system change; 'vitals' — kernel machine telemetry; 'resource_read' — read a registered arifos:// resource by uri; 'resource_search' — search/list registered resources."

changedInput schema / properties / mode / enum

Previous value: -[
-  "search",
-  "fetch",
-  "hybrid_discovery",
-  "ingest",
-  "compass",
-  "atlas",
-  "entropy_dS",
-  "vitals"
-]New value: +[
+  "search",
+  "fetch",
+  "hybrid_discovery",
+  "ingest",
+  "compass",
+  "atlas",
+  "entropy_dS",
+  "vitals",
+  "resource_read",
+  "resource_search"
+]

addedInput schema / properties / uri

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Registered resource URI to read when mode=resource_read, e.g. 'arifos://vitals' or 'arifos://carry-forward'."
+}

5 tool updatesOct 29, 2026
- Removedarif_delegate
- Removedarif_recall
- Removedarif_research
- Removedread_resource
- Removedsearch_resources

5 tool updatesOct 28, 2026

Changedarif_delegate3 fields changed

addedInput schema / properties / _envelope

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedInput schema / properties / actor_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedInput schema / properties / session_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Changedarif_recall3 fields changed

addedInput schema / properties / _envelope

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedInput schema / properties / actor_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedInput schema / properties / session_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Changedarif_research3 fields changed

addedInput schema / properties / _envelope

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedInput schema / properties / actor_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedInput schema / properties / session_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Changedread_resource3 fields changed

addedInput schema / properties / _envelope

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedInput schema / properties / actor_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedInput schema / properties / session_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Changedsearch_resources3 fields changed

addedInput schema / properties / _envelope

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedInput schema / properties / actor_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedInput schema / properties / session_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

5 tool updatesOct 28, 2026
- Addedarif_delegate
- Addedarif_recall
- Addedarif_research
- Addedread_resource
- Addedsearch_resources

Publisher details

Operator: ARIF FAZIL · Publisher source
Operator website: https://arif-fazil.com
Vendor relationship: First-party
Documentation: Unknown
Trust center: Unknown
Restrictions: Unknown

Related MCP Connectors

arifOS — Constitutional AI Governance A
io.github.ariffazil
arifOS — a constitutional kernel for AI agents. 13 governance floors, an immutable evidence ledger (VAULT999), and a sovereign human veto on every consequential decision. Forged, not given.
AI & Machine Learning Autonomous Agents
9454
https://arifosmcp.arif-fazil.com/mcp
Atomadic MCP C
tech.atomadic
Atomadic MCP: 68 deterministic tools for agent identity, escrow, SLA, EU AI Act compliance.
Security Legal & Compliance Payments & Billing
681
https://mcp.atomadic.tech/mcp
Reasoning Commons
io.github.chenyuan35
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
AI & Machine Learning Knowledge & Memory Autonomous Agents
2
https://aineedhelpfromotherai.com/api/mcp
Diogenes Autonomous Microservice Gateway A
io.github.stand-out-of-my-sun
Autonomous AI microservices: 55 dynamic guardrails, contract audits & oracles via L402/x402/MPP.
Autonomous Agents Blockchain Payments & Billing
10712
https://diogenes-micro-gateway.corinth.workers.dev/mcp

Related MCP Servers

arifOS
Agent Orchestration Autonomous Agents
ariffazil
A
license
C
quality
A
maintenance
Provides a constitutional governance framework for AI agents, offering MCP tools for session initiation, reasoning, evidence fetching, judgment, and execution, all governed by hard invariant laws and a hierarchical set of constitutional floors.
Updated 18 hours ago (2026-10-31 20:50 UTC)
6
162 PyPI
54
AGPL 3.0
arifosmcp
Agent Orchestration Knowledge & Memory
ariffazil
A
license
Not graded
quality
F
maintenance
Constitutional MCP server enforcing 13 Floors of governance for AI agents, providing tools for session anchoring, reasoning, safety critique, and audit logging.
Updated 7 months ago (2026-04-03 08:31 UTC)
AGPL 3.0
warden
Security Developer Tools
Marciommc
A
license
Not graded
quality
D
maintenance
A constitutional MCP server that enforces external authority, loud rejections, and an unforgeable hash-chained ledger, preventing AI agents from minting their own identity, approving themselves, or rewriting history.
Updated 3 months ago (2026-07-19 14:48 UTC)
5 npm
Apache 2.0
Glass Box Framework
AI & Machine Learning Testing & QA Tools Observability
TheBarmaEffect
A
license
Not graded
quality
C
maintenance
Runtime constitutional verification for AI answers — claim extraction with reasoning chains, Epistemic Confidence Score (ECS), 7-angle Glassbox Court red team, constitution compilation, Trust Card assembly, and deterministic SHA-256 audit logs.
Updated a day ago (2026-10-31 02:58 UTC)
11
Apache 2.0

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Publisher details

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources