wrapguard-mcp

Suggest a safe wrapping fix

suggest_wrap_fix

Read-only

Generates a minimal CSS rule to prevent Korean and English words from splitting across lines, fixing mid-word wraps and hard newlines in web content.

Instructions

Generate a minimal CSS rule for Korean, English, mixed prose, raw evidence, or code/URL content.

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": {
      "selector": "<selector>"
    },
    "name": "suggest_wrap_fix"
  }
}

Input Schema

Name	Required	Default
`locale`	No	auto
`selector`	Yes
`contentKind`	No	prose

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 2, 2026

TDQS

B3.3/5.0

Behavior3/5

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

The description discloses that the tool generates a minimal CSS rule rather than mutating anything, which aligns with readOnlyHint=true. It adds the 'minimal' qualifier, but does not elaborate on what 'safe' means, whether the returned rule is guaranteed valid, or any constraints on the selector. No contradiction with annotations.

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?

One sentence, front-loaded with the action and object, with no filler or repeated annotation information. The list of content types is compact and the description earns its place.

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?

For a simple generation tool this description covers the core output, but it omits selector semantics, the meaning of 'safe', and how this tool relates to the apply/inspect siblings. Since there is no output schema, a bit more guidance would materially improve call correctness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description had to compensate, but it only paraphrases the values already present in the locale and contentKind enums. The required selector parameter is not described or even hinted at, leaving its purpose and format to inference.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a clear verb ('Generate') and resource ('a minimal CSS rule') and enumerates the content types it covers, so an agent can tell what the tool produces. It does not explicitly differentiate from siblings such as apply_wrap_fix or inspect_wrap_css, though the title 'Suggest' hints at the distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The content-type list ('Korean, English, mixed prose, raw evidence, or code/URL') gives a sense of when the fix applies. There are no when-not-to-use instructions or references to alternatives, so the agent must infer when to prefer this over apply_wrap_fix or verify_wrap_regression.

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

Deploy Server