Skip to main content
Glama

data

DestructiveIdempotent

Read, modify, or delete data in JSON, YAML, or TOML files using get, set, and delete operations.

Instructions

Get, set, or delete data in JSON, YAML, or TOML files.

Use when you need to get, set, or delete specific values or entire sections in a structured data file.

Output contract: Returns {"success": bool, "result": Any, "file": str, ...}. Side effects: Modifies file on disk if operation is 'set' or 'delete'. Failure modes: FileNotFoundError if file missing. ToolError if format disabled or invalid JSON.

Operations:

  • get: Retrieve data, schema, or structure

  • set: Update/create value at key_path (always writes to file)

  • delete: Remove key/element at key_path (always writes to file)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
valueNoValue to set as JSON string (required for operation='set')
cursorNoPagination cursor
key_pathNoDot-separated key path (required for set/delete, optional for get)
data_typeNoType for get: 'data', 'schema', or 'meta' (server info)data
file_pathYesPath to file
operationYesOperation: 'get', 'set', or 'delete'
value_typeNoHow to interpret the value parameter for SET operations. 'string': treat value as literal string (no JSON parsing). 'number': parse value as JSON number. 'boolean': parse value as JSON boolean. 'null': set to null/None (value parameter ignored). 'json' or None (default): parse value as JSON (current behavior, maintains backward compatibility).
return_typeNoReturn type for get: 'keys' (structure) or 'all' (full data)all
output_formatNoOutput format
document_indexNoOptional YAML document index for multi-document files (0-based)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds valuable behavioral details: side effects ('Modifies file on disk if operation is 'set' or 'delete''), failure modes ('FileNotFoundError if file missing'), and output contract. This goes beyond the annotations without contradicting them.

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 well-structured and concise: a one-line summary, usage guidance, then structured sections for output contract, side effects, failure modes, and operation bullets. Every sentence adds value without redundancy.

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 tool's complexity (10 parameters) and the presence of an output schema, the description covers output contract, side effects, failure modes, and operations. It is comprehensive, though it could briefly mention parameter interactions (e.g., required parameters per operation) to reach full completeness.

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

Parameters3/5

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

The input schema has 100% description coverage, so the baseline is 3. The description does not add additional meaning beyond the schema; it only reiterates operation semantics. No parameter-specific clarification is provided that isn't already in 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 the tool's purpose: 'Get, set, or delete data in JSON, YAML, or TOML files.' It uses specific verbs and resource types, and the bullet list of operations further clarifies. The description distinguishes this tool from siblings like data_query and data_convert by focusing on basic file CRUD operations.

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 includes a direct usage statement: 'Use when you need to get, set, or delete specific values or entire sections in a structured data file.' This provides clear context. However, it does not explicitly exclude alternative tools or specify when not to use it, so it lacks full comparative guidance.

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/bitflight-devops/mcp-json-yaml-toml'

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