Skip to main content
Glama

octave_write

Create or modify OCTAVE files with full content, delta updates, or in-place normalization.

Instructions

Unified entry point for writing OCTAVE files. Handles creation (new files) and modification (existing files). Use content for full payload, changes for delta updates. Omit both content and changes to normalize an existing file in-place. Replaces octave_create and octave_amend.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
schemaNoSchema name for validation (I5). Common schemas: META, SKILL, CRS_REVIEW, COGNITION_DEFINITION, DEBATE_TRANSCRIPT. Use 'frozen@<hash>' or 'latest' for hermetic resolution. If an unknown schema is provided, the response includes available_schemas.
changesNoDictionary of field updates for existing files. Each value is either a bare value (full replacement, default) or a $op descriptor: {"$op":"DELETE"} removes the target; {"$op":"APPEND","value":x} pushes x (or each item of list x) onto the end of an array target; {"$op":"PREPEND","value":x} unshifts onto the front of an array; {"$op":"MERGE","value":{...}} deep-merges into a block target, preserving unmentioned children (use inner $op:DELETE to remove). Op/target-type mismatches return E_OP_TARGET_MISMATCH; missing paths return E_UNRESOLVABLE_PATH (no auto-create, I3); malformed descriptors return E_INVALID_OP_DESCRIPTOR. Paths support: top-level KEY, META.FIELD, PARENT.CHILD into a top-level Block, and §N.KEY / §N::NAME.KEY into Sections. (GH#373)
contentNoFull content for new files or overwrites. Accepts raw OCTAVE or a single markdown fenced code block. Mutually exclusive with changes.
dry_runNoAlias for corrections_only. If True, return corrections/diff without writing to disk (default: false).
lenientNoIf True, enable deterministic lenient parsing + optional schema repairs. Default: false (strict parsing).
base_hashNoExpected SHA-256 hash of existing file for consistency check (CAS).
mutationsNoMETA field overrides (applies to both modes).
target_pathYesFile path to write to
format_styleNoOutput formatting style for canonical emission. 'preserve' (Strategy A, GH#377): span-aware preserve mode — clean nodes slice from baseline_bytes, dirty/repaired nodes re-emit canonically. Diff footprint ≤0.5% of file size on single-key edits against representative documents. Subsumes GH#248 mixed annotation form drift. 'expanded': lift inline-map shapes (KEY::[K::V,...]) into Block form before emit. 'compact': collapse atom-only Blocks (no comments, arity-bounded) into inline-list-of-InlineMap form. Comment-bearing subtrees vetoed with W_COMPACT_REFUSED (I3 Mirror Constraint, I4 Auditability). DEPRECATED v1.13.0: Passing format_style=null explicitly emits a DeprecationWarning; the default will change from full canonical re-emit to 'preserve' in v1.14.0. To keep canonical re-emit past the flip, pass 'expanded' explicitly. To opt in to the new default early, pass 'preserve'. Omitting the parameter accepts the future default silently.
grammar_hintNoIf True and validation returns INVALID, include compiled GBNF grammar in response to guide correction.
debug_grammarNoIf True, include compiled regex/grammar in output for debugging constraint evaluation.
corrections_onlyNoIf True, return corrections/diff without writing to disk (dry run).
parse_error_policyNoPolicy when tokenization/parsing fails in lenient mode: "error" (default) or "salvage".
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses behavioral traits such as handling creation and modification, detailed op descriptors for changes, error codes, format_style options with deprecation, dry_run behavior, lenient parsing, and parse_error_policy. This is highly transparent.

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 long but well-structured, starting with a summary and then detailing modes, deprecation, and options. Every sentence adds value, though the op descriptor details could be slightly more concise. Still efficient overall.

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 complexity (13 params, nested objects, no output schema), the description is very complete. It covers use cases, op structure, error handling, formatting, and deprecation. It does not explain return values, but that is acceptable without an output schema.

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 100%, baseline is 3. The description adds significant extra context beyond schema descriptions, explaining the relationship between content and changes, op descriptors, format_style future changes, and the effect of lenient and parse_error_policy. This enhances understanding beyond 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 clearly states it is the unified entry point for writing OCTAVE files, handling both creation and modification. It explicitly distinguishes itself by noting it replaces octave_create and octave_amend, and describes different usage modes (content, changes, normalize).

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?

The description explains when to use content vs changes vs omit both, and that it replaces older tools. However, it does not explicitly contrast with sibling tools like octave_validate or octave_compile_grammar, leaving some ambiguity about when not to use this tool.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/elevanaltd/HestAI-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server