Skip to main content
Glama
zzmmgg654321-dev

mcp-han

by zzmmgg654321-dev
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

fix_text

Fixes formatting issues in Chinese text and returns the corrected version, preserving code and URLs while listing changes and items needing manual review.

Instructions

自动修复中文文案的排版问题，返回修复后的全文。

默认只套用「安全」规则（不会动代码块、行内代码、URL），
并会告诉你改了哪些地方、还有哪些需要人工确认。

Args:
    text: 要修复的文本。
    rules: 只跑指定规则，逗号分隔；用 "-" 前缀排除。点名某条平时不自动跑的
        规则（例如 "dup-punct"）时它也会被套用。
    quote_style: 引号风格——curly（默认，“”）/ corner（「」）/ keep（不动）。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYes
rulesNo
quote_styleNocurly

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the transparency burden and does so well: it states the default safe rule scope, what is explicitly left untouched (code blocks, inline code, URLs), that it will report changes, and that some items need manual confirmation. This is strong for a pure text transformation tool.

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 description is compact and structurally clear, starting with purpose and then behavior, followed by parameter explanations. Every sentence carries information; no fluff. Slight density from the in-description argument block is the only reason it doesn't reach 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a pure text-processing tool with 3 simple parameters and an output schema, the transparency is mostly complete. It explains default behavior, rules selection, and quote style. It fails to point at sibling tools like list_rules for available rule names, but that is not required for a correct invocation.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must fully compensate. It does: text is explained, rules details comma-separated exclusion and forced inclusion with an example, and quote_style enumerates all three modes with symbols. No meaningful parameter definition is left 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?

The description states a specific action (自动修复) and resource (中文文案的排版问题) and says it returns the full fixed text. This clearly marks the tool as a fixer rather than a checker/counter, but it doesn't name sibling tools, so differentiation is implicit rather than explicit.

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

Usage Guidelines2/5

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

The description gives no guidance on when to use this tool instead of its siblings (check_text, count_text, list_rules). It provides parameter-level usage details, but not when-to-use/exclusion guidance, which is the key here.

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

Install Server

Other Tools