Skip to main content
Glama

absorb_document

Destructive

Convert a markdown agent-instruction file into typed vault nodes, classifying sections as policy, architecture suggestions, or injection risks. Dry-run returns a plan; confirm writes nodes.

Instructions

Slice 0 (PRODUCT-PLAN-2026-07.md §4/§9) — the "absorption tool". Converts a CLAUDE.md/AGENTS.md-style markdown file into typed vault nodes so a tech lead's existing agent-instruction file stops needing dual maintenance. Splits the file by ## sections and classifies each:

  • rule/policy/decision sections → kind: document nodes with a role: policy frontmatter extra.

  • architecture/component sections → element/capability SUGGESTIONS only — never auto-written; review and land with add_concept if useful.

  • sections matching an injection-suspect pattern (Tier 1 — imperative instruction-hijack phrasing, shell/SQL fragments) are excluded from absorption regardless of category and reported for human review. The file body is always treated as untrusted data; parsing never executes or evaluates its content. Two-stage safety, same shape as delete_concept:

  1. Without confirm: true the call is a dry-run — returns the classification plan per section, no writes.

  2. With confirm: true, absorbed sections are written as document nodes, the source file is backed up to <file>.pre-absorb.bak, then rewritten into a "slim pointer" that reproduces every non-absorbed section (suggested, unclassified, or injection-suspect) verbatim — content is never destroyed. Throws instead of overwriting an existing backup file. The canonical source path must be inside repoRoot; outside paths (including symlink escapes) require an reviewed dry-run plus explicit allowOutsideRepo:true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
confirmNoActually write when true. Omit or false for a dry-run (plan only, no writes).
filePathYesPath to the CLAUDE.md/AGENTS.md-style markdown file to absorb (absolute, or relative to the MCP server cwd).
allowOutsideRepoNoExplicit destructive opt-in required only when filePath resolves outside repoRoot. Dry-run reports outsideRepo and keeps canConfirm:false without it.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
titleNo
dryRunYes
changedNo
messageYes
summaryYes
writtenNo
filePathYes
sectionsYes
backupPathNo
canConfirmYesTrue only when repeating the call with confirm:true can perform the previewed change without another explicit safety opt-in.
outsideRepoYes
sourceLabelYes
wouldChangeYesTrue only when the dry-run predicts a disk or Git change.
previewReadyYesTrue only when this response is a complete dry-run preview that an agent can review.
blockedReasonsYesMachine-readable human explanations for every condition currently blocking confirmation.
postWriteMaintenanceNoCompact maintenance_plan summary for post-write follow-up. Bucket maps describe the remaining queue after the write.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.13.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark it destructive, but the description goes well beyond that by disclosing the two-stage confirm/dry-run flow, backup creation, slim-pointer rewrite, throw-on-existing-backup behavior, never-destroys-content guarantee, and outside-repo restrictions. There is no contradiction with the annotations.

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

Conciseness5/5

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

The description is long but densely packed: the primary purpose is front-loaded, and each subsequent sentence covers a distinct safety or classification rule essential to correct invocation. No filler or repetition of schema boilerplate.

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 complex mutation tool with an output schema and annotations, the description covers the full decision surface: classification, dry-run vs confirmed execution, backup/replacement behavior, injection-suspect handling, and path-safety constraints. An agent has enough to invoke it correctly and predict side effects.

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 the schema documents the three parameters at 100% coverage, the description adds substantive semantics: confirm's dry-run vs write behavior, the review requirement and allowOutsideRepo for outside paths, and the canonical-path-inside-repoRoot constraint. This meaningfully helps an agent set parameters correctly.

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 opening sentence identifies a specific verb ('converts') and resource ('CLAUDE.md/AGENTS.md-style markdown file') with a concrete output ('typed vault nodes'), and the classification rules further distinguish it from related tools like add_concept. It is not a tautology and gives an agent a precise job description.

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 intended input is explicit and the description tells the agent how to route suggestions ('review and land with add_concept if useful') and which sections to exclude. It falls short of a 5 because it does not explicitly state when to prefer this over other conversion/indexing tools or list negative conditions beyond injection-suspect sections.

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