Skip to main content
Glama
sixees
by sixees

Query JSON File

jq_query
Read-onlyIdempotent

Query a saved JSON file using jq-like filters to extract specific data without making a new HTTP request.

Instructions

Query an existing JSON file with a jq-like filter expression.

This tool allows you to extract data from saved JSON files without making new HTTP requests. Useful for:

  • Extracting different fields from a large saved response

  • Applying multiple queries to the same data

  • Processing any local JSON file within allowed directories

Args:

  • filepath (string, required): Path to a JSON file to query

  • jq_filter (string, required): JSON path filter expression

  • max_result_size (number): Max bytes inline (default: 500KB, max: 1MB)

  • save_to_file (boolean): Force save result to file

  • output_dir (string): Custom directory to save result files

Filter Syntax:

  • .key - Get object property

  • .[n] - Get array element at index n (non-negative only, also .n with dot notation)

  • .[n:m] - Array slice from n to m

  • .["key"] - Bracket notation for keys with special chars

  • .name,.email - Multiple comma-separated paths (returns array of values, max 20)

  • Note: Negative indices not supported (unlike real jq)

Security:

  • Only files in these directories can be read:

    1. Our temp directory (files saved by curl_execute)

    2. MCP_CURL_OUTPUT_DIR environment variable path

    3. Current working directory and ALL subdirectories (broad - ensure cwd is safe)

  • Maximum file size: 10MB

Examples:

  • Extract name: { "filepath": "/path/to/response.txt", "jq_filter": ".name" }

  • Multiple fields: { "filepath": "/path/to/data.json", "jq_filter": ".name,.email,.id" }

  • Array slice: { "filepath": "/path/to/list.json", "jq_filter": ".items[0:5]" }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filepathYesPath to a JSON file to query. Must be in temp directory, MCP_CURL_OUTPUT_DIR, or current working directory.
jq_filterYesJSON path filter expression. Supports: .key, .[n] or .n (non-negative array index), .[n:m] (slice), .["key"] (bracket notation), .a,.b (multiple comma-separated paths return array, max 20). Negative indices not supported.
max_result_sizeNoMax bytes to return inline (default: 500KB, max: 1MB). Larger results auto-save to file
save_to_fileNoForce save result to file. Returns filepath instead of content
output_dirNoDirectory to save result files (must exist and be writable)
Behavior5/5

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

Annotations declare read-only, non-destructive, idempotent, closed world. Description adds security path restrictions, max file size (10MB), auto-save behavior for large results, and filter limitations (no negative indices). No contradictions.

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?

Well-structured with sections: purpose, use cases, args, filter syntax, security, examples. Slightly long but all content is relevant. Front-loaded with purpose.

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?

Covers all 5 parameters, filter syntax, security constraints, size limits, examples, and behavioral details. No output schema, but return behavior (inline vs file) is explained.

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

Parameters4/5

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

Schema coverage is 100%, baseline 3. Description adds detailed filter syntax with examples, security path rules, and default behaviors for max_result_size and save_to_file. This goes beyond schema descriptions.

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 'Query an existing JSON file with a jq-like filter expression.' It distinguishes from sibling tool curl_execute by noting it avoids new HTTP requests. The verb 'query' and resource 'JSON file' are specific.

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 lists use cases: extracting fields from saved responses, multiple queries, processing local files. It implicitly suggests use after HTTP fetch but lacks explicit 'when not to use' or direct alternative comparison beyond the sibling name.

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/sixees/mcp-curl'

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