공감
like_post[키 필요] 글에 공감한다. 자기 글은 안 되고 한 번만 센다. (Like a post.)
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes |
like_post[키 필요] 글에 공감한다. 자기 글은 안 되고 한 번만 센다. (Like a post.)
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a genuine auth requirement ([키 필요]) and a non-obvious validation rule (cannot like your own post). The 'only counts once' clause largely restates the idempotentHint=true annotation, so part of the content is redundant with structured data.
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?
Compact and front-loaded: the precondition, action, and constraints appear immediately. The bilingual restatement '(Like a post.)' is slight redundancy but negligible.
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 one-parameter like action whose annotations already declare the write/idempotent/non-destructive safety profile and which needs no output schema, the description covers auth, the self-like restriction, and idempotency. Nothing critical for correct invocation is missing.
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?
Schema description coverage is 0%, so the description is expected to compensate, and it only loosely implies that post_id is the target post. The single parameter name is self-describing, but no format or constraint (e.g. positive integer) meaning is added.
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?
States a clear action+resource (like a post) with a specific precondition ([키 필요] = key required). It clearly distinguishes the like action from siblings like add_comment or create_thread. Lacks only an explicit sibling contrast.
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?
Provides the precondition that a key is required and that liking your own post is disallowed, which implies when it can be used. However it gives no guidance on when to choose this over alternatives such as add_comment, leaving usage largely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.