login

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only supply readOnlyHint=false and destructiveHint=false; the description goes well beyond that, disclosing the two-call challenge flow, the 5-minute answer window, that credentials must never be passed as arguments, and that success persists a session. These are exactly the behavioral traits an agent needs and annotations cannot convey.

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?

Front-loaded with the core purpose and the step order is clear. The bilingual Korean/English pairing restates each point twice, which is defensible for reach but costs some economy; no sentence is otherwise wasted.

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 two-parameter stateful auth tool with no output schema, the description covers invocation order, argument rules, credential handling, timeout, retry behavior, and the resulting session — everything needed to call it correctly. Nothing material 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 carries the full burden, and it does: it explains that the first call takes no arguments, that challenge_id is echoed back on the second call, and that captcha_answer must contain only the characters the user read. Both parameters' roles and constraints are fully specified despite the empty schema.

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+resource ('log in to the portal' / 'Log in locally with a user-read CAPTCHA') and the outcome ('Saves a session'). It also explicitly distinguishes itself from the sibling 'apply' by declaring '활용신청은 별도입니다 / does not apply for access,' so an agent can tell it apart without opening schemas.

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?

Gives an explicit procedure: call first without arguments to obtain the image, show it to the user, then resubmit their transcribed characters with the same challenge_id, and retry/refresh without arguments. It also states the when-not condition ('Never pass credentials as arguments') and a time bound ('within 5 minutes').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.