SwishrJobs

CSV to JSON transform script with pytest tests

submit_csv_json_transformation

Idempotent

Produce a standard-library Python module that transforms CSV text into a JSON array of objects, plus pytest tests. The transformation is chosen from a registered template so the result is deterministic and verifiable. Choose this when you need a tested, standard-library function that parses CSV text into a JSON array of objects, one per row. Do not choose this for per-column type coercion or bespoke rules, or if you need the file converted for you rather than a module that does it: this delivers code, not converted data. Example requests: Give me a Python module that turns CSV text into a JSON array of objects, with tests. | I have CSV and need JSON objects, one per row, produced by a tested function. | Convert CSV to JSON and prove it with a pytest suite.

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_csv_json_transformation"
  }
}

Input Schema

Name	Required	Description
`inputs`	Yes
`quote_id`	No	The 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_by`	Yes	Identifier of the human or agent authorizing this job.
`accepted_price`	No	The 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

Name	Required	Description
`quote`	No
`state`	Yes
`job_id`	Yes
`artifacts`	No
`access_token`	No	Per-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.
`verification`	No	Independent verification. verification.ok = false means the job failed, not a partial success.
`capability_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 31, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the description need not restate safety. It adds meaningful context beyond annotations: the result is template-driven and deterministic, includes pytest tests, and returns code rather than converted data. It does not mention the quote/pricing authorization flow, which is a minor gap.

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?

The essential purpose and the code-vs-data distinction are front-loaded. The definition is somewhat repetitive: the first sentence and the 'Choose this when...' sentence restate the same deliverable, and three example requests add length. Still, no sentence is actively misleading and the structure is navigable.

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 not be described. However, this is a priced, authorization-gated job submission with quote_id and accepted_price parameters, and the description does not explain the quote/authorize workflow or that a quote_id from POST /v1/jobs is required. For a tool of this complexity, the description is adequate but leaves important operational context 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 description coverage is high at 75%, so the schema already documents module_name, function_name, template, quote_id, authorized_by, and accepted_price. The description explains the template concept ('chosen from a registered template so the result is deterministic and verifiable'), which adds meaning, but it says nothing about the authorization/pricing parameters (quote_id, accepted_price) that are operationally important. Baseline 3 is appropriate.

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 uses a specific verb and resource ('Produce a standard-library Python module that transforms CSV text into a JSON array of objects, plus pytest tests') and clearly distinguishes the deliverable from data-conversion siblings by stating 'this delivers code, not converted data.' An agent can tell it apart from submit_csv_to_json_rows or submit_json_csv_conversion without opening the 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?

It gives explicit inclusion criteria ('Choose this when you need a tested, standard-library function...') and exclusion criteria ('Do not choose this for per-column type coercion or bespoke rules, or if you need the file converted for you'). The example requests reinforce the selection context, leaving little to inference.

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

All SwishrJobs tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?