Skip to main content
Glama

octave_write

Create, modify, or normalize OCTAVE files with full content or targeted changes, including schema validation and dry-run support.

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?

With no annotations, the description carries full burden and covers behavioral traits thoroughly: it describes file operations (creation, modification, normalization), error types (E_OP_TARGET_MISMATCH, etc.), format styles with deprecation warnings, and consistency checking via base_hash.

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 front-loaded with the main purpose. Every sentence adds value, though some sections (e.g., format_style) are verbose with nested details. Overall, it balances completeness and conciseness for the 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?

Given 13 parameters and no output schema, the description covers all parameters, error conditions, format styles, dry run behavior, and deprecation warnings. It provides enough context for an AI agent to invoke the tool correctly.

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?

Although schema coverage is 100%, the description adds significant meaning beyond the schema. It explains mutual exclusivity of content/changes, details the operation descriptor structure, provides examples for paths, and describes error conditions for each parameter.

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 a unified entry point for writing OCTAVE files, handling both creation and modification. It distinguishes from predecessor tools by mentioning it replaces octave_create and octave_amend, and lists specific use cases: new files, delta updates, and in-place normalization.

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' and when to omit both for normalization. It also mentions the tool replaces previous tools. However, it does not explicitly state when not to use this tool relative to siblings, though siblings have different purposes.

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