text_summarySummarize a long text (up to 100,000 characters) into a concise Korean summary. 입력 텍스트(최대 10만 자)의 핵심 내용을 간결하고 정확하게 요약합니다. 모델·파라미터는 서버가 고정하며 빠른 응답에 최적화되어 있습니다. 토큰 수와 무관하게 요청당 고정 포인트가 차감됩니다. [호출당 100포인트]
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 요약할 원문 텍스트 (최대 100,000자) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint), the description discloses that model/parameters are server-fixed, optimized for speed, and that a fixed point cost is deducted per request regardless of token count, including the exact cost of 100 points per call. This adds substantial behavioral context not captured elsewhere.
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 mostly concise and front-loaded, but the first two sentences duplicate the same information in English and Korean. It includes useful cost and model-fixed details. The redundancy is minor, so it earns a 4.
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 simple tool with one parameter and no output schema, the description covers the main aspects: purpose, input limit, model behavior, speed, and cost. It could explicitly mention the output format or input language, but these are minor gaps, making it largely complete.
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 already describes the single 'text' parameter with max 100,000 characters (100% coverage). The description adds no additional meaning beyond restating the character limit and does not provide syntax or formatting details, so the baseline of 3 is appropriate.
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 the tool's function: 'Summarize a long text (up to 100,000 characters) into a concise Korean summary.' It uses a specific verb (summarize) and resource (long text), and distinguishes from siblings like text_polish by focusing on summarization rather than polishing.
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 the tool is for summarization but does not explicitly say when to use it versus alternatives like text_polish or llm_chat. It provides context (fixed model, fast response, cost) but no exclusions or alternative references, leaving usage to be inferred.
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.