aoci-code
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AOCI_DB_PRIMARY_DSN | No | Optional read-only database connection string (DSN) reference for Database Cognition. The variable name is derived from the database source ID (e.g. source 'primary' maps to AOCI_DB_PRIMARY_DSN); the value is supplied outside the conversation by a database administrator and is never stored by AOCI-CODE. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| aoci_get_entriesA | Read specified Entries. Legacy and Code use repository paths or a directory; Volumes v1 also accepts volume_id and canonical object_refs, including database:// table identities, and returns volume identity with each result. Legacy live drift behavior is unchanged. Use only for local uncertainty, an incomplete Overview, or an explicit Entry request; do not substitute a few Entries for complete Overview. This does not modify formal cognition or Baseline, but may append a local audit record. |
| aoci_headerC | Read the shared object rules, tag dictionaries, and calibration examples. Legacy returns its Header; Volumes v1 returns Meta with Root identity and never presents Root project overview as the dictionary. Call only when these rules are not already reliable or need a separate check. This does not modify formal cognition or Baseline, but may append a local audit record. |
| aoci_maintainA | After managed content reaches its final stable state, obtain the next complete machine-issued authoring batch. Legacy behavior remains compatible: provable format-only drift may advance the Baseline, and local Ledger audit records may be appended. Resolve repair_required or stopped completely. Do not call again for a purely read-only task, an unstable intermediate state, or an already aligned repository. When refresh is pending, Verify, Check, and Guide must prove aligned first. A new repository or incomplete index must use the current Guide; this tool cannot replace that workflow. In Volumes v1, omit scope on the ordinary path: shared governance facts determine aligned, authoring_required, evidence_required, or blocked. For a large logical plan, Maintain deterministically returns at most max_entries candidates, cut by the team transport budget maintain_transport_budget_bytes (default 24 KiB) under the team cap code_cognition_batch_entries (default 50, ceiling 200), with logical_plan, batch_identity, total_targets, included, remaining, continuation_required, Composite/Scope identity, per-target source or Evidence bindings, and the exact Guide action. For Code, copy code_plan.batch_id to aoci_update_entry.code_batch_id; it equals every returned Code candidate.batch_id. authoring_batch.batch_identity identifies the cross-domain authoring envelope and is not a Code or Database write batch id. This is the complete candidate set for the current batch, not an arbitrary prefix the Host may change and not a Whole-Index limit. Apply it atomically; if remaining is nonzero, call Maintain again against the new preimage. Whole-Index aligned is allowed only when remaining, missing, stale, unbaselined, orphan, Scope debt, and Recovery are all clear. Maintain may write only machine candidate receipts and local Ledger audit records; it never authors tag or F/R/A/S, connects to a database, changes Scope, or reduces Index coverage for transport limits. Orphans remain explicit remove candidates, Root and Meta remain guards, and explicit scope=database only reads saved Canonical Evidence, contains no program-generated tag or FRAS field, returns database_volume_absent when the Database Volume is absent, and creates no Root, Meta, or Database Volume. An explicit Cognition Optimization request is the sole aligned-Entry exception: only for Volumes v1 Code, set intent=cognition_optimization and optionally object_refs to obtain bound review candidates. For every candidate, the Host reviews the current complete Entry, source, and necessary relations, then submits either a complete replacement Entry or the unchanged complete Entry through the existing aoci_update_entry batch; field patches are forbidden. AOCI selects and binds candidates only: it never generates semantics or S, compresses Entry text, or lowers C. This mode never applies to Legacy or Database cognition. |
| aoci_overviewA | Deliver the complete formal Whole-Index, optionally scoped to all, project, meta, code, or database in a Volumes v1 repository. An ordinary call returns the exact formal body inline when it fits overview_delivery.chunk_tokens, otherwise it immediately returns Chunk 1 using overview-chunk-receipt/v1. When continuation_required=true, submit the exact next_cursor automatically until completed=true; do not ask the user, start the business task, state a partial conclusion, or replace missing Chunks with scope, aoci_search, or aoci_get_entries. Stop the cognition chain on Host truncation, a missing, duplicate, or reordered Chunk, cursor failure, or Index/configuration change. The formal Entry ordinal is the 1-based position in one canonical sequence: Header, comments, blank lines, Section/Overview/Chunk Marker, Receipt, and Metadata are excluded, and Chunk Receipts and Challenge answers consume that same sequence. After the complete chain, submit host_delivery_confirmation and the existing model-cognition-attestation/v1 once; the Attestation must echo the final Challenge's exact current index_sha256, entry_sequence_sha256, and entry_count, and a prior identity is invalid. One same-response schema-only correction is allowed, but semantic mismatch means fail/uncertain with no Memory, source, Spec, aoci.txt, Search, Get Entries, Scope, or historical-session repair. A failed or partial Attestation disables an unqualified complete-system claim; it does not prohibit honest answers or source-bound investigation and engineering. An ordinal, object identity, Tag, or core F mismatch is strict proof failure, not by itself proof that the model did not understand the system. A Host may set cognition_state_version=cognition-state/v2 to receive an additive read-only projection that separates delivery_verified, model_cognition_usable, strict_attestation_verified, governance_aligned, and current_system_cognition_reliable; omitting it preserves the exact legacy response shape. A complete, host-confirmed, governance-aligned context-compaction refresh consumes its generation even when Attestation is partial or failed, so the Host continues the existing source-bound task without another automatic Overview. Initial failure additionally blocks unbound Root/Meta, Migration, layout-wide, and other system decisions. system_mastery_percent self-assesses the system framework—architecture, responsibilities, strong relationships, stable external contracts, and high-entropy safety and maintenance constraints—not complete source or runtime knowledge. Normally expose only one concise user sentence separating actual Index coverage from framework mastery. check_only=true returns only compact checkpoint facts and never starts a Chunk chain. Dirty or Stale cognition is delivered but unreliable; aoci_maintain remains the governance path, while pending Recovery or an incoherent snapshot fails closed. The body is start marker, exact aoci.txt bytes, and end marker with no generated directory inventory. Legacy no-argument and Volumes scope behavior remain compatible. This does not modify formal cognition or Baseline, but may append a local audit record. |
| aoci_remove_entryA | Use only for an explicit orphan Entry candidate returned by governance. Legacy accepts a repository-relative path whose disk object no longer exists. Volumes v1 accepts code: or a canonical database:// object identity and reproves the orphan from shared governance facts. R references from other Entries never block removal: a dangling annotation left behind is model-authored semantics, handled by the model on its next Whole-Index read, never by the machine. An exact machine ownership-conflict finding with different expected and actual owners and an existing expected formal owner removes only the misplaced Domain Entry while preserving that owner. The transaction guards Root, Meta, every declared object Volume, saved Evidence, and the existing Baseline/Database Binding. It removes no source file, database object, Evidence, Root, Meta, or Volume. Recovery, changed, unproven, or third-party state is rejected. Removing a non-orphan requires a maintainer decision recorded with aoci_report; never delete a workspace or database object merely to manufacture an orphan. |
| aoci_reportA | Record follow-up work when evidence is insufficient to generate or decide Legacy Entry semantics reliably. This writes a local report and audit record but does not modify the formal index or Baseline. Volumes v1 returns volume_read_only. It does not replace Curation, orphan decisions, or failure recovery. |
| aoci_rulesA | Read the current AOCI session-level runtime contract. Call when a new Agent Run lacks a reliable contract, when the contract has left usable context, or when the AOCI service identity changes. Do not repeat it within the same cognition cycle. This does not modify the formal index or Baseline, but may append a local audit record. |
| aoci_searchA | Search Entry content by keyword and/or tag. Volumes v1 can restrict search to all, project, meta, code, or database and returns volume_id plus canonical object identity; Legacy behavior is unchanged. Use when the target is unknown, for local uncertainty, or on explicit request. Do not substitute search results for complete Overview. This does not modify formal cognition or Baseline, but may append a local audit record. |
| aoci_update_entryA | Write one complete current machine-issued model-authored Entry batch through the existing Impact, projected validation, Diff, CAS, AtomicWrite, Baseline/Database Binding, Receipt, Ledger, and Recovery pipeline. For Volumes Code authoring, preserve the exact code_batch_id, every candidate_id, path, and source_sha256 returned by no-argument aoci_maintain: aoci_update_entry.code_batch_id must equal code_plan.batch_id and every returned Code candidate.batch_id; authoring_batch.batch_identity is a different cross-domain envelope identity and must never be used in code_batch_id. Database candidates preserve the exact top-level batch_id and every candidate_id; never copy Database Volume or Table Evidence hashes into source_sha256. max_entries limits this request and atomic transaction only, not the logical plan, Whole-Index, or Managed Scope. The submitted entries must be the complete candidate set for the current machine-issued batch; the Host must not slice Maintain output. AOCI validates all candidates and source/Evidence, Scope, Composite, tag, FRAS, R/S form, and projected budget bindings before writing Code at most once, Database at most once, and Baseline/Binding at most once. R is model-authored semantics: AOCI never checks one Entry's relations against another Entry, so a relation naming an unwritten, unmanaged, or ambiguous target is accepted and persisted exactly as written and never causes a replan; author R freely and never delete or rewrite it to satisfy the machine. A successful batch with remaining nonzero is not Whole-Index aligned: call Maintain again against the new preimage and continue. A repair_required response returns every deterministic Finding with candidate_index, canonical_object_identity, rule_code, and safe_repair_action; repair only retry_scope and resubmit the same complete current batch. Existing direct single-object, Legacy, and compatible Code source_sha256 inputs remain supported. Root and Meta are Guard-only. Never guess, reduce Scope for transport limits, or submit a partial machine-issued batch. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
The tools cover distinct actions, but the read surface has meaningful overlap: aoci_overview, aoci_get_entries, and aoci_search all retrieve cognition content, and aoci_header versus aoci_rules both expose governing rules. The very elaborate descriptions repeatedly try to prevent misuse, which helps but also signals that the boundaries are not naturally obvious.
All tools share the aoci_ prefix and are readable in snake_case. The suffix pattern is mostly action-oriented, but aoci_header, aoci_overview, and aoci_rules are noun-style rather than verb_noun, so it is not perfectly consistent.
Nine tools is well within a reasonable range for a cognition/index governance server. Each tool maps to a recognizable operation: read overview, search, get entries, read rules/header, maintain, update, remove, and report.
The surface covers the core lifecycle: orientation via header/rules, reading via overview/search/get_entries, authoring via maintain/update_entry, orphan removal, and reporting. Some referenced workflow concepts such as Verify, Check, and Guide are not exposed as first-class tools, but the main governance path appears workable.