Opens a browser window to log in to Velog and saves the session under a chosen alias, eliminating manual token entry on subsequent runs. Use on first login or when the session expires.
브라우저 창을 띄워 velog 로그인을 진행합니다. 최초 1회 또는 세션 만료 시 실행하세요. 로그인 완료되면 세션이 프로필로 저장되어 이후 토큰을 수동으로 넣을 필요가 없습니다.
| Name | Required | Description | Default |
|---|---|---|---|
| account | Yes | 이 로그인 세션에 붙일 별칭 (예: main) |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that a browser window is opened, the session is saved as a profile, and manual token insertion is avoided. However, it does not mention interaction expectations, potential for existing session overwrite, or what the call returns when completed.
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?
Three sentences each add distinct value: what, when, and outcome. No filler words, and the most important action appears first.
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 login tool with no annotations or output schema, the description covers the essential context: why, when, and the persistent effect. It could mention what the tool returns or how the agent confirms login success, but the side effect of saving a profile is stated.
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 only parameter 'account' is already documented in the schema with an alias example, and schema coverage is 100%. The description doesn't add additional meaning about the parameter, but also doesn't need to because the schema does the job.
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 specific verb and resource: opens a browser window to proceed with velog login. This clearly distinguishes from sibling tools like velog_create_post or velog_list_posts, which handle content operations. The action is not a tautology of the tool name.
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?
Explicitly says when to run: on initial use or when session expires. It doesn't name alternatives or exclusion conditions, but the context is enough for an agent to decide. Sibling tools are for other purposes, so no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.