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

Annotations already indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, so the description is not the only source of behavioral info. The description adds specifics: it can install an app, return already_connected when the session works, and force re-auth. It also clarifies that installation does not authorize GetSign. This goes beyond the annotations, providing context about side effects and return behavior. It does not cover all possible behaviors, but it is reasonably transparent.

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 moderately concise, using a brief opening line and then bullet-like indentation for the two actions. It is front-loaded with the main purpose. Some redundancy exists (e.g., 'Open a secure GetSign login' and then 'action=oauth: Monday OAuth URL'), but overall it is structured and readable. It could be tightened by removing unnecessary words.

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 7 parameters and 0% schema coverage, the description is incomplete. It covers only 3 of the parameters and does not describe the output schema or return values beyond a brief mention of 'already_connected'. The tool has multiple modes and side effects (app installation), so an agent needs more detail on parameters like account_id, return_url, and force_install to use it correctly. The description leaves significant gaps.

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 schema has 7 parameters with 0% description coverage, so the description must compensate. It explains action (with default and two values), force (for re-auth), and permitted_workspaces (only for install). However, it does not mention mode, account_id, return_url, or force_install. These parameters remain undocumented in both schema and description, leaving an agent without guidance on their meaning or usage. This is a significant gap.

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 clearly states the tool's purpose: to open a secure GetSign login or install the Monday app and log in. It distinguishes two modes (oauth and install) and provides the default behavior. This differentiates it from sibling tools like getsign_account or getsign_manage_tools, which handle other aspects of account management.

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 gives explicit conditions for each action: action=oauth is default and returns already_connected when the session already works, with force=True to re-auth; action=install is for when the app is not installed. It also clarifies that installing does not authorize GetSign, so OAuth still needs to complete. However, it does not reference alternative tools or exclusions beyond the two actions, so it is not fully explicit about when to use this tool versus others.

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