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

The readOnlyHint, idempotentHint, and destructiveHint annotations already establish the safety profile. The description adds value beyond that by disclosing conditional behavior: it returns different fields depending on connection state, including the presence of pending[] and connect_url. This helps the agent interpret responses, though it could be more thorough by covering partial connection states.

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 exceptionally concise — two sentences. The first sentence front-loads the core purpose ('Returns connection status and URLs'), and the second adds necessary conditional detail. Every word earns its place, with no redundancy or fluff.

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 tool with no parameters and no output schema, the description adequately conveys the two main outcomes: fully connected and missing credentials. However, it does not describe what happens when only some providers are connected (e.g., whether pending[] is populated). Since the description is otherwise clear and the tool is simple, this is a minor gap rather than a serious deficiency.

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, so the schema provides complete coverage (100%). The description does not need to elaborate on parameters. According to the rubric, a zero-parameter tool gets a baseline of 4 because there is nothing to contextualize beyond the 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?

The description clearly states the tool's function: 'Returns connection status and URLs.' It specifies the output in different conditions (authenticated:true with empty pending[] vs connect_url when credentials are missing), distinguishing it from siblings like 'authenticate' which likely performs the actual connection. The verb 'returns' and resource 'connection status' are specific and unambiguous.

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 implies when to use this tool: to check connection status and retrieve URLs. It describes result variations ('When all providers are connected... When credentials are missing...'), giving context on expected outcomes. However, it does not explicitly state when not to use it (e.g., 'use authenticate to connect') or name alternative tools, though the sibling list makes the distinction relatively clear.

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