Skip to main content
Glama

JSON to CSV: turn records into a spreadsheet-ready file

submit_json_to_csv_rows
Idempotent

Convert a JSON document into a CSV file. Accepts an array of objects, a single object, or an API envelope such as {"data": [...]}. The header is the sorted union of every record's keys, nested values are kept as compact JSON, and records with missing keys are padded and reported. Choose this when you have JSON records and need a CSV file: an array of objects, a single object, or an API envelope such as {"data": [...]}. The header is the sorted union of every record's keys, so a record with an extra field still contributes a column. Do not choose this when you need the opposite direction (use csv-to-json-rows), when the JSON must be validated against a schema (use json-schema-validation), or when the records need cleaning first (run csv-clean on the output). Example requests: Turn this API response into a CSV I can open in Excel. | Convert this JSON export into CSV for a bulk database import. | Flatten this list of JSON records into a spreadsheet.

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": {
      "inputs": "<inputs>",
      "authorized_by": "<authorized_by>"
    },
    "name": "submit_json_to_csv_rows"
  }
}

Input Schema

NameRequiredDescriptionDefault
inputsYes
quote_idNoThe quote_id returned by POST /v1/jobs. Required to authorize a priced capability; the service rejects a priced job that does not name the quote it issued.
authorized_byYesIdentifier of the human or agent authorizing this job.
accepted_priceNoThe amount accepted, exactly as quoted (for example "5.00" or 5). Checked against the stored quote, so a price that moved between quote and authorize is refused rather than silently absorbed. Optional, but sent to make the acceptance explicit.

Output Schema

NameRequiredDescriptionDefault
quoteNo
stateYes
job_idYes
artifactsNo
access_tokenNoPer-job credential. Present it as the X-Job-Token header to read the job or list it. Keep it; it is the only credential for this job.
verificationNoIndependent verification. verification.ok = false means the job failed, not a partial success.
capability_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare idempotent=true, destructiveHint=false, openWorld=false, so safety is covered; the description still adds real behavioral content — the header is the sorted union of all keys, nested values are emitted as compact JSON, and records with missing keys are padded and reported. It does not mention that this is a priced capability requiring a quote_id, which is the one notable omission.

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?

Substantial duplication: "an array of objects, a single object, or an API envelope such as {"data": [...]}" appears twice verbatim, and the "header is the sorted union of every record's keys" rule is stated twice. Roughly a third of the text could be deleted with no loss, which hurts front-loading.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the transformation rules are covered. But for a priced, authorization-gated capability the description never explains the quote/authorize flow implied by quote_id and accepted_price, leaving the most consequential part of invocation to the schema.

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?

Schema coverage is 75%, so the schema largely documents itself; the description only clarifies the accepted shapes of the nested `content` field. It says nothing about quote_id, accepted_price, or authorized_by, which are the non-obvious invocation parameters an agent must supply for a priced job.

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?

States a specific verb and resource ("Convert a JSON document into a CSV file") and enumerates the accepted input shapes. It also names the sibling it is not (csv-to-json-rows, json-schema-validation), so an agent can separate it from the crowded submit_* conversion family without opening any schema.

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?

Explicit routing in both directions: "Choose this when you have JSON records and need a CSV file" plus a "Do not choose this when..." clause that names three alternatives (csv-to-json-rows, json-schema-validation, csv-clean) and the condition selecting each. Example requests reinforce the fit.

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