x402-normalize-whitespace
Normalize Whitespace: Normalize Whitespace
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Text to process | |
| input | No | Input to process |
Normalize Whitespace: Normalize Whitespace
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Text to process | |
| input | No | Input to process |
Changes observed during successful MCP inspections.
Input schema / properties / inputAdded value: +{
+ "description": "Input to process",
+ "type": "string"
+}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 are provided, so the description carries the full burden, and it discloses nothing: not whether collapsible runs of spaces/tabs/newlines are all normalized, whether leading/trailing whitespace is trimmed, whether the operation is pure or mutating, or what the response contains. The tool name implies a deterministic text transform, but no behavioral detail is stated.
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?
The text is short but the brevity is hollow: the same four words are repeated with a colon separator, providing zero information. Shortness without substance is not conciseness.
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?
For a low-complexity tool this could pass, but with two indistinguishable optional parameters, no annotations, no output schema, and a swarm of similar whitespace siblings, the definition leaves the agent unable to confidently pick the param or the tool. Material context is missing.
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 coverage is 100%, which would normally justify a baseline of 3, but the schema itself is ambiguous: two optional string parameters, "text" and "input", documented only as "Text to process" and "Input to process". The description does nothing to disambiguate which one to supply, so it fails to compensate for a genuine schema weakness.
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 is literally the tool name repeated twice ("Normalize Whitespace: Normalize Whitespace"), a tautology that restates rather than explains. It hints at verb+resource but adds nothing an agent couldn't infer from the name, and gives no differentiation from siblings like x402-collapse-spaces, x402-remove-whitespace, or x402-dedent.
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?
No when-to-use, when-not-to-use, or alternative is mentioned. With dozens of near-neighbor whitespace/text tools in the sibling list (collapse-spaces, remove-whitespace, dedent, trim-lines, normalize), the absence of any routing guidance is actively harmful.
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.