Skip to main content
Glama

octave_write

Create, modify, or normalize OCTAVE files with full content or delta updates for structured AI artifacts.

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
target_pathYesFile path to write to
contentNoFull content for new files or overwrites. Accepts raw OCTAVE or a single markdown fenced code block. Mutually exclusive with changes.
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)
mutationsNoMETA field overrides (applies to both modes).
base_hashNoExpected SHA-256 hash of existing file for consistency check (CAS).
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.
debug_grammarNoIf True, include compiled regex/grammar in output for debugging constraint evaluation.
grammar_hintNoIf True and validation returns INVALID, include compiled GBNF grammar in response to guide correction.
lenientNoIf True, enable deterministic lenient parsing + optional schema repairs. Default: false (strict parsing).
corrections_onlyNoIf True, return corrections/diff without writing to disk (dry run).
dry_runNoAlias for corrections_only. If True, return corrections/diff without writing to disk (default: false).
parse_error_policyNoPolicy when tokenization/parsing fails in lenient mode: "error" (default) or "salvage".
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.
Behavior5/5

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

Without annotations, description fully explains behavioral traits: error conditions (E_OP_TARGET_MISMATCH, E_UNRESOLVABLE_PATH, E_INVALID_OP_DESCRIPTOR), format options with deprecation warnings, and normalization behavior. Exceeds minimal transparency.

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?

Long but every sentence earns its place. Could be slightly restructured for readability (e.g., bullet points for changes ops), but front-loads key info. Not overly verbose given complexity.

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

Completeness5/5

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

For a tool with 13 parameters, no output schema, and nested objects, the description covers all aspects: purpose, usage modes, parameter details, error handling, validation, format options, and deprecation. Leaves no critical gaps.

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

Parameters5/5

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

Schema coverage is 100%, but description adds substantial meaning: details about $op descriptors for changes, deprecation for format_style=null, explanation of schema validation, and dry run aliasing. Goes far beyond schema alone.

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?

Clearly states 'Unified entry point for writing OCTAVE files' and covers creation/modification. Distinguishes from legacy tools (octave_create, octave_amend). Specific verb 'write' and resource 'OCTAVE files'.

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?

Explicitly explains when to use content vs changes vs omit both for normalization. Also mentions it replaces other tools. However, no explicit guidance on when not to use or when to use sibling tools like octave_validate.

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/octave-mcp'

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