socials_check_access

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only says 'Check connection status' and gives a recovery flow, but does not state whether the check is read-only, what it returns, or any side effects. The recovery flow hints that the tool can fail, but does not explain the tool's own behavior or what the success/failure indication looks like.

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 description is two sentences, the first stating the purpose and the second providing a structured recovery flow. It is front-loaded and every sentence earns its place. The numbered recovery steps are concise and easy to follow without unnecessary elaboration.

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?

Given the tool's simplicity (zero parameters, no output schema, no annotations), the description covers the core purpose, the expected next action (use socials_open_tab), and a detailed recovery flow. It lacks an explicit description of what the tool returns or how status is reported, but for a simple check, the provided context is mostly sufficient.

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 tool has zero parameters and the input schema is empty, so the schema coverage is vacuously high. The baseline for 0 params is 4, and the description adds no parameter information because none is needed. The description's focus on usage and recovery is sufficient.

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 states 'Check connection status' with a clear verb and resource. It distinguishes itself by framing this as a preflight check before using socials_open_tab, and the recovery flow ties it to access-related siblings. However, it does not explicitly differentiate from socials_health_check or socials_diagnostics, which could have overlapping purposes.

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?

The description explicitly states 'After confirming access, use socials_open_tab...' and provides a numbered RECOVERY FLOW with alternative tools (socials_refresh_auth, socials_restart_bridge) and a user action. This gives clear when-to-use and what-to-do-on-failure guidance, going beyond a simple statement of purpose.

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