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

Annotations only declare readOnlyHint=false and destructiveHint=false, so the description carries real weight here: it discloses that a server-side session is created and persisted for later query tools, that re-authentication is required after expiry, and that each call costs a token ('호출마다 토큰 1소진'). The idempotency paragraph adds recovery semantics, though parts ('anonymous taste calls', 'provider-specific idempotency_key') are boilerplate that do not map to anything on this tool.

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 first two sentences are front-loaded and waste-free, but the trailing idempotency block is long relative to this tool and includes irrelevant or ambiguous clauses ('not available to anonymous taste calls', 'Keep any provider-specific idempotency_key unchanged' — no such field exists here). That padding dilutes an otherwise tight login definition.

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?

With no output schema, the description covers what an agent needs to call it: ordering, credential fields (documented in schema), session reuse, expiry handling, and cost. It stops short of describing failure behavior (bad certificate, wrong business registration number) or how a caller learns the login succeeded, which would complete the picture.

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 coverage is 100%, so the baseline is 3, and the description earns an increment by fully explaining request_idempotency_key, which the schema explicitly defers to the tool description ('see the tool description'). It clarifies when to reuse versus regenerate the key, which is meaning the schema cannot convey on its own.

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 specific verb and resource ('Signs in with the corporate certificate') and names the scope ('stores the session the efine query tools reuse'), which separates it from the efine query siblings that depend on it as well as from the other providers' session logins. An agent can tell exactly what state this tool creates without opening the schema.

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?

It states explicit ordering ('Call this FIRST before any other tool for this provider') and an explicit re-entry condition ('call it again if a tool reports the session expired'). Both the when and the when-again are spelled out with no inference required.

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