check_login_status

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

No annotations are supplied, so the description carries the full behavioral burden. It does disclose the return semantics (per-platform status: logged in, missing session, expired), which is valuable given there is no output schema, but it omits auth requirements, rate limits, whether the check has side effects such as refreshing an expired session, or how long cached status remains valid.

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 short sentences, front-loaded with the core action, then the return states, then the usage rule. The final sentence is guidance rather than repetition of the tool's purpose, though 'before applying' slightly restates the first sentence's framing.

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 no-annotation read-only check with no output schema, the description covers purpose, return states, and call timing — enough for an agent to invoke it correctly. Gaps remain around the failure/expiry path (what to do when a session is missing or expired) and any side effects of the check itself.

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 100%, and the sole 'platforms' parameter is fully documented in the schema including the default-all behavior and the valid enum list. The description adds no parameter-level detail beyond what the schema already provides, so the baseline 3 applies.

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 ('Verify whether login sessions are active for job platforms') with clear scope, and the enumeration of result states (logged in, missing session, expired) pins down exactly what is being checked. This is easily distinguished from siblings like login_account or save_session, which create or persist credentials rather than verifying existing sessions.

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 explicit timing guidance: 'Always check login status before attempting real job applications.' That tells the agent both when to call it and how it relates to apply_job/bulk_apply. It stops short of naming sibling alternatives for the reverse case (e.g., what to do when a session is missing — presumably login_account), so no exclusion routing.

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