View a summary of your Korean writing style; analysis runs automatically when posts are added or removed, so you do not need to call it separately.
내 문체 요약을 본다(분석은 글을 넣고 뺄 때 저절로 되니 따로 부르지 않아도 됨).
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | 문체 묶음 이름. 보통은 비워 두세요(「기본」). 회사용 · 개인 블로그용처럼 따로 둘 때만 씁니다. 글 종류(블로그 · 공지 …)는 style 이 아니라 kind 로 나눕니다. | 기본 |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare openWorldHint=false and idempotentHint=true, so the agent already knows this is a bounded, repeatable operation. The description adds genuinely new behavior: analysis is auto-triggered on add/remove of writing. It does not state the operation is read-only, but with an output schema present, return-format disclosure is unnecessary.
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?
A single compact sentence with the primary action front-loaded and the caveat about auto-analysis parenthetically attached. Nothing is redundant, though the parenthetical slightly muddies the main statement.
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 one-parameter, idempotent tool with a documented schema and an existing output schema, the description covers the essentials: what it returns and the fact that analysis happens elsewhere. The only gap is lack of explicit differentiation from sibling style tools.
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?
There is a single optional parameter with 100% schema description coverage, and the schema already explains the '기본' default, when to leave it blank, and the style-vs-kind distinction in detail. The description adds nothing about the parameter, 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 gives a clear verb+resource ('내 문체 요약을 본다' – view my style summary) and importantly reconciles the misleading tool name by clarifying that the analysis itself is automatic, so this tool only retrieves the summary. It does not, however, differentiate itself from close siblings such as get_my_style_guide or list_styles, leaving the agent to guess which summary/guide tool to pick.
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?
There is a partial when-not-to-use signal ('분석은 … 저절로 되니 따로 부르지 않아도 됨'), telling the agent it need not trigger analysis separately. However, no alternative tool is named and no positive condition ('call this when you want to display the user's style summary') is stated, so the routing guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.