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

The annotation readOnlyHint: true already signals that this is a safe read operation. The description adds context beyond that by stating exactly what data is reported (connected apps and tool availability), which helps the agent understand the output even without an output schema. No contradiction exists between description and annotations.

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 with no filler. The first sentence states the core function, and the second provides actionable usage context. Information is front-loaded, and every word contributes. This is an exemplary level of conciseness.

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 zero-parameter, no-output-schema tool, the description covers both purpose and usage scenario adequately. It tells the agent what to expect from the report (connected apps, tool counts) and when to use it. There are no hidden requirements or side effects implied, so the description is complete for safe invocation.

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?

There are zero parameters, so the baseline is 4. The description adds value by indicating what the tool reports, which is effectively the result of no inputs. Since there is no schema to describe, the description compensates by explaining the tool's behavior, which is helpful for the agent.

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 uses a specific verb ('Reports') and resource ('Elgato apps connected to the bridge') and immediately clarifies the output ('how many of their tools are available'). It also gives an example app (Stream Deck), making the purpose unambiguous. With no sibling tools, differentiation is not needed, but the description still fully describes what the tool does.

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 second sentence provides a clear use case: 'Use this to check whether the Stream Deck app is reachable when expected tools are missing.' This tells the agent when to invoke the tool. Since there are no sibling tools, there is no need to specify exclusions or alternatives, so only a slight deduction for not covering broader conditions (e.g., what to do if the bridge itself is down).

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