text_polishPolish a text (up to 100,000 characters) by fixing grammar, spelling, and awkward phrasing. 입력 텍스트(최대 10만 자)의 문법 오류, 맞춤법·오타, 어색한 표현, 문장 순서를 의미를 유지한 채 자연스럽게 다듬습니다. 모델·파라미터는 서버가 고정하며 빠른 응답에 최적화되어 있습니다. 토큰 수와 무관하게 요청당 고정 포인트가 차감됩니다. [호출당 100포인트]
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 다듬을 원문 텍스트 (최대 100,000자) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the description does not need to repeat safety. It adds valuable behavioral context: fixed model/parameters, optimized for fast response, fixed point deduction regardless of token count, and meaning preservation. This goes beyond the annotations, though it omits output shape and failure behavior. No contradiction.
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 description is front-loaded with the core purpose in English, followed by a Korean translation that adds minor detail (sentence order) and cost/performance notes. The bilingual repetition is slightly redundant, but the overall length is appropriate and each sentence contributes to understanding. It is well-structured but not maximally concise.
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?
Given the tool's simplicity (one parameter, no output schema, strong safety annotations), the description provides sufficient context: purpose, size limit, cost, and performance traits. It does not explicitly state the return value, but that is obvious for a polishing operation. Minor gaps like language support or error cases are not critical for this scope.
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?
The input schema fully covers the single 'text' parameter with a description including the 100,000-character limit. The tool description repeats this limit but adds no new semantic detail (e.g., formatting, language, or examples). Since schema coverage is 100%, the baseline of 3 applies, and the description does not elevate it.
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 clearly states a specific verb ('Polish'), a resource ('a text'), and the scope (up to 100,000 characters). It also enumerates the types of fixes (grammar, spelling, awkward phrasing), which distinguishes it from sibling tools like text_summary (summarization) and llm_chat (conversation). The title '텍스트 다듬기 AI' reinforces the purpose.
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 implies usage through its purpose and constraints (max length, fixed server parameters, fast response, cost), but it does not explicitly state when to prefer this tool over alternatives or provide exclusions (e.g., 'for large texts use X'). No alternative tools are mentioned. The guidance is implicit rather than explicit.
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.
llm_chat and llm_models form a clear pair (generic chat vs model catalog), while text_polish and text_summary are narrowly scoped fixed-purpose utilities. Their descriptions make the boundaries obvious, so an agent should not misroute a request between them.
All names are lowercase snake_case and follow a readable domain_prefix pattern (llm_* and text_*). The conventions are not perfectly uniform, though: text_summary is a noun where text_polish uses a verb, and llm_models is a catalog noun rather than an action.
Four tools is a compact, well-scoped set with no redundant entries: model discovery, general chat, and two specialized text operations. Each tool earns its place for this server's apparent purpose.
The tool surface covers the core LLM workflow (model lookup plus chat) and the advertised text-polish/summary operations without obvious dead ends. The stateless chat design is intentional, and pricing information is provided through llm_models.