x402-tsv-json
Tsv JSON: Convert TSV (tab-separated values) text into JSON. Provide tsv or data; returns an array of objects.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tsv | No | Tsv to process | |
| data | No | Data to process | |
| text | No | Text to process |
Tsv JSON: Convert TSV (tab-separated values) text into JSON. Provide tsv or data; returns an array of objects.
| Name | Required | Description | Default |
|---|---|---|---|
| tsv | No | Tsv to process | |
| data | No | Data to process | |
| text | No | Text to process |
Changes observed during successful MCP inspections.
Input schema / properties / textAdded value: +{
+ "description": "Text to process",
+ "type": "string"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden, but it does disclose the return shape ('an array of objects'), which is genuinely useful given there is no output schema. It says nothing about header-row handling, delimiter expectations, behavior when multiple input fields are supplied, or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the purpose front-loaded and the return value appended; nothing is padded. The 'Tsv JSON:' prefix is mildly redundant with the rest of the sentence but costs little.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description does cover purpose and return type, which is the minimum needed. It still leaves ambiguity about which input field takes effect when several are provided and how headers map to JSON keys, which an agent would need to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters, establishing a baseline of 3. The description's 'Provide tsv or data' hints that the two fields are interchangeable inputs but omits the third parameter ('text') and never explains precedence if more than one is supplied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Convert TSV (tab-separated values) text into JSON') and clarifies the output type ('returns an array of objects'). It does not, however, distinguish itself from nearby siblings such as x402-csv-json or x402-text-to-json, which an agent must infer from the format name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says to 'Provide tsv or data,' which is input selection advice rather than tool selection guidance. It never states when this tool is preferable to x402-csv-json or other conversion tools, and gives no preconditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.