Skip to main content
Glama

Preserve line breaks

runsheet_preserve_line_breaks
Read-only

Inserts an invisible U+2060 WORD JOINER so YouTube stops collapsing blank lines in descriptions, comments, and posts; returns ready-to-paste, idempotent text.

Instructions

Insert the invisible character (U+2060 WORD JOINER) that stops YouTube collapsing blank lines in a description, comment or community post. Returns the text ready to paste. Idempotent: running it on already-processed text does not stack characters. No cost, no allowance used.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesText containing blank lines to preserve.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true and openWorldHint=false, so the description adds real value: it discloses the exact character used (U+2060), states it returns paste-ready text, guarantees idempotency (no stacking), and notes no cost/allowance is consumed. It stops short of describing edge cases such as input with no blank lines, but the behavioral picture is strong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Three tightly packed sentences, each earning its place: what it does, what it returns, and the idempotency/no-cost guarantees. The purpose is front-loaded with no preamble.

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?

For a simple one-parameter transform with no output schema, the description covers purpose, the exact mechanism, the return value ('text ready to paste'), idempotency, and cost. Nothing an agent needs in order to call it correctly is missing.

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?

There is a single parameter at 100% schema description coverage, which already documents 'text'. The description implies the input is text containing blank lines but adds no format or syntax detail beyond the schema, so the baseline of 3 applies.

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 ('Insert the invisible character (U+2060 WORD JOINER)') and names the exact problem it solves for YouTube descriptions, comments and community posts. This is clearly distinguishable from siblings like runsheet_style_text or runsheet_count_characters 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 Guidelines4/5

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

The description gives clear context for when to use it: text destined for YouTube that contains blank lines. It does not explicitly name alternative tools or state when NOT to use it, but the trigger condition is unambiguous.

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