Skip to main content
Glama

Process JSON with jq

process_json
Read-onlyIdempotent

Optional per-query x402 payment costs 0.005 native USDC on Base: tools/call params._meta["com.thejqapi/payment"]={mode:"query",idempotency_key:"fresh UUID"}; add signed _meta["x402/payment"] on retry. Keep the identical arguments and key. Active passes never incur this charge. Payment precedes execution; runtime/URL errors are chargeable. A settled payment permits three identical delivery attempts within 15 minutes, including the first; results are re-executed, never cached. Pending settlement is a tool error without execution: inspect GET /access/purchases/{idempotency_key} using the same bearer UUID without a second payment. Changed requests/retry exhaustion return 409 and expired delivery 410. Per-query privacy excludes payload logs and free counters but retains one billing receipt per logical query and temporary keyed retry data; it is not the pass’s zero-query-record mode. Requires an x402 client and explicit 0.005-USDC spending policy. Never put payment/credentials in arguments. Apply a jq filter and return JSON results; this does not create or modify uploads. Choose exactly one source: input for an available JSON value, url for a public HTTPS document, or upload_id to reuse stored JSON. For a single query, pass input or url directly; use upload_json first only when several queries should reuse one document. For example, filter .name extracts a field, keys inspects structure, and . reads the complete document, including an upload. To check upload availability or remaining quota without running jq, use get_upload or get_quota. Document limit 5 MiB; URL fetches allow three redirects and ten seconds, without caller credentials or private networks. Upload IDs expire 15 minutes after creation. Anyone holding an ID can query, inspect, or delete that upload. Runs real jq in isolated WebAssembly memory. Supply modules as options.modules filenames mapped to source on each call; they disappear afterward and need no separate management. Returns success, result, rawResult, results (every emitted jq value), stdout, jqVersion, executionTime, and optional stderr. Free-tier processing uses one shared daily REST/MCP quota call: 100 per IP or 1,000 per client-configured UUID bearer token, resetting at midnight UTC. Both free and paid keep JSON, filters, results, and source URLs out of application logs. Active 30-day passes additionally skip IP/UUID daily counters, query counts, and source analytics, with unlimited queries and zero application query logs. Expired paid UUIDs reject ordinary queries until renewed or explicitly paid per query, without free-tier tracking. Use get_quota to inspect active access. Minimal billing records, explicit uploads, public payments, and Cloudflare infrastructure boundaries are disclosed at https://thejqapi.com/privacy. jq failures return success:false and error; input failures may include status 400 (invalid), 404 (missing upload), 410 (expired), 413 (too large), 415 (unsupported data), 502/504 (URL failure/timeout), or 503 (storage unavailable). Quota exhaustion returns a tool error with remaining:0, reset_at, a structured upgrade offer linking pricing and browser checkout, and reset details in _meta.rateLimit. Use purchase_access only under an authorized spending policy; otherwise wait for reset.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "filter": "<filter>"
    },
    "name": "process_json"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlNoPublic HTTPS URL to fetch as input, up to 5 MiB. No credentials, private addresses, or custom headers.
inputNoJSON value; use a string with raw_input or input_stream for text input.
filterYesjq expression, e.g. .name, keys, or .items | length. Use . to read the complete input or uploaded document. Modules are supplied per call in options.modules.
optionsNoOptional jq input modes, named variables, per-call modules, and stdout formatting. Omitted boolean flags are false. Text modes read inline strings or remote document text; raw_input and input_stream are mutually exclusive.
upload_idNoSecret ID returned by upload_json; reusable until its 15-minute expiration. Do not share.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already mark this as read-only and non-destructive, but the description adds substantial behavioral context beyond them: per-query payment mechanics, retry and settlement behavior (three identical delivery attempts within 15 minutes, re-executed not cached), HTTP failure codes (400/404/410/413/415/502/504/503), quota exhaustion behavior, upload-ID expiration, and privacy/logging characteristics. It also warns that anyone holding an upload ID can query, inspect, or delete it, which is important security context not present in annotations. Nothing here contradicts 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.

Conciseness2/5

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

The content is a single massive paragraph in which payment, privacy, quota, upload, and error details all run together. The core purpose and source-selection guidance appear only after a long block of x402 payment mechanics, so the definition is poorly front-loaded. Much of the payment material is relevant, but the lack of structure and ordering makes the definition harder to scan than necessary.

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 the tool's complexity, the definition is unusually complete: it covers payment costs, retry semantics, error codes, quota behavior, upload expiration, privacy distinctions, and return fields (success, result, rawResult, results, stdout, jqVersion, executionTime, stderr). No output schema exists, so the description appropriately explains what the tool returns. An agent has enough information to invoke the tool correctly and interpret common failures.

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%, so the baseline is 3, but the description adds meaning beyond the schema by clarifying the mutually exclusive source-selection rule ("Choose exactly one source") and the intended workflow for input, url, and upload_id. It also gives practical filter examples (.name, keys, .) and explains per-call module behavior. The additional guidance is useful but largely repeats concepts already well described in the schema, so it does not reach a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: "Apply a jq filter and return JSON results," and explicitly distinguishes itself from upload creation ("this does not create or modify uploads"). It also names sibling alternatives (upload_json, get_upload, get_quota), so an agent can route correctly. The only deduction is that the purpose sentence is buried after several hundred words of payment boilerplate, so an agent scanning the first lines may not immediately see what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit source-selection rules: "Choose exactly one source: input for an available JSON value, url for a public HTTPS document, or upload_id to reuse stored JSON." It also states when to prefer upload_json for reuse across several queries, when to call get_upload or get_quota instead of running jq, and when purchase_access is appropriate versus waiting for quota reset. These are concrete when-to-use and when-not-to-use conditions with named alternatives.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources