Skip to main content
Glama

aoci_overview

Deliver the complete formal Whole-Index, optionally scoped to all, project, meta, code, or database, and manage chunked continuation until the full cognition context is verified.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
probeNocheck_only only: request a two-question cognition probe sampled from the current formal Entry sequence; answer from memory to prove retained cognition instead of re-requesting the Whole-Index
scopeNoOptional cognition scope: all, project, meta, code, or database; Volumes v1 defaults to all and Legacy no-argument behavior is unchanged
cursorNoExact deterministic Overview continuation cursor returned by the preceding chunk
check_onlyNoReturn only the compact checkpoint assessment; when false or absent, deliver the complete requested scope if a coherent snapshot is available
probe_answersNo
scope_coveredNoWhether the current task remains within the cognition scope already established
refresh_reasonsNoOptional host-declared refresh reasons: context_compaction and/or phase_transition; semantic_threshold is machine-derived
refresh_event_idNoHost event idempotency key required when refresh_reasons are declared
cognition_receiptNoOptional receipt from a previous complete delivery or checkpoint
stable_checkpointNoWhether current edits, formatting, lint, and required tests have reached the nearest stable checkpoint
model_cognition_stateNoHost assessment of current complete cognition: valid, uncertain, or invalid
cognition_state_versionNoOptional additive cognition-state projection version; use cognition-state/v2 to request independent delivery, model-usability, strict-Attestation, governance, and current-system reliability fields; omit it for the exact legacy response shape
host_delivery_confirmationNo
model_cognition_attestationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so extensively: chunking against overview_delivery.chunk_tokens, cursor continuation, stop conditions (Host truncation, duplicate/reordered Chunks, cursor failure), Attestation identity rules, cognition-state/v2 projection, check_only non-start behavior, and the exact body composition. This is unusually rich behavioral disclosure for a tool with zero annotation coverage.

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

Conciseness3/5

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

The purpose is front-loaded in the first sentence, and most content is substantive rather than filler. However, it is a very long block of dense, jargon-heavy run-on sentences that merge many distinct rules, making it hard to parse at a glance.

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?

For a 14-parameter, nested, no-output-schema, no-annotation tool, the description covers the delivery protocol, return shape, and failure semantics thoroughly. Given there is no output schema, some return-field detail (checkpoint/receipt contents) is left to the schema, but the core operational contract is well addressed.

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

Parameters4/5

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

Schema coverage is 79% (near the 80% baseline of 3), but the description adds genuine meaning for key params: check_only semantics, the cognition_state_version=v2 projection, system_mastery_percent's scope, and the continuation/next_cursor interaction. It goes beyond restating the schema for the highest-stakes parameters, so a 4 over the baseline is warranted.

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 first sentence states a specific verb and resource: 'Deliver the complete formal Whole-Index... in a Volumes v1 repository,' with scope options enumerated. It later distinguishes itself from siblings by warning not to substitute scope, aoci_search, or aoci_get_entries for missing Chunks. The heavy domain jargon ('Whole-Index,' 'Volumes v1,' 'cognition') keeps it from being instantly clear, but the action is identifiable.

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 delineates the ordinary call vs check_only paths, mandates automatic continuation on continuation_required, and names aoci_maintain as the governance route for Dirty/Stale cognition. Alternatives (aoci_search, aoci_get_entries) are mentioned as things NOT to use for repair, giving real when/when-not framing, though the primary-vs-alternative routing is implied rather than cleanly stated.

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