KG JSON Toolkit Developer

The write-capable sibling of KG_json_toolkit_user, same as the CSV toolkit's developer/user split. Identical schema, identical file-based connection - a JSON file, referenced either by picking one out of the pack's own knowledge-base folder or by pointing absolute_path at a file anywhere else on disk. What's different is the capability handed to the LLM once this is wired up as a tool: going by this pack's naming convention across its knowledge-base pairs, "developer" reads as the version that lets the model add, edit, or restructure entries, not just look them up.

Treat that as a real capability, not a formality. An LLM with write access to your knowledge base can act on an ambiguous instruction in a way you didn't intend - the usual failure mode for any tool that lets a model modify persistent data, not something unique to this node.

The inputs and outputs that matter

• relative_path - a dropdown of JSON files already inside the pack's own knowledge-base folder.
• absolute_path - point this at any JSON file elsewhere on disk instead.
• is_enable - standard bypass toggle.

Output: tools (STRING) - the serialized tool definition, wired into the agent node's tool-list input, not read directly.

How to install it

Via ComfyUI Manager: search comfyui_LLM_party, install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/heshengtao/comfyui_LLM_party.git

Then pip install -r requirements.txt from inside the pack folder using ComfyUI's own Python, and restart. No external database needed - just a JSON file this node can reach, same as its "user" counterpart.

Common issues & troubleshooting

Back up the JSON file before handing this to an agent. If write access is really what this tool grants, you want a way back to a known-good state the first time an edit doesn't match what you expected. Cheap insurance for a file you're letting a model modify.

The knowledge base changed and it's not obvious why. Look at the conversation that led up to it - a write-capable agent acts on instructions in the chat, so the cause is usually traceable there even when the connection between the request and the resulting edit isn't immediately obvious.

Malformed JSON after an edit. If the LLM is writing to this file and something downstream starts failing to parse it, check the file's actual structure - a model generating JSON on the fly can produce syntactically invalid output, especially for deeply nested or unusual structures.

You only need to read, not write. Use KG_json_toolkit_user instead - there's no upside to granting an agent edit access to data it only ever needs to look up.