manual

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

Annotations already declare a safe read (readOnlyHint=true, destructiveHint=false), and the description adds real context beyond that: the tool needs no session, the corpus spans every target so results may not apply to the user's target, and it names the verification path (PRACTICE.CoMmanD.AVAILable / PRACTICE.FUNCtion.AVAILable). It doesn't mention result size or pagination, so one notch below top.

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?

Front-loaded with purpose, then examples, then the session and target caveats. Dense but nearly every clause carries information; the telegraphic fragments ('Needs no session.') are slightly terse but never wasteful.

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 one-parameter documentation lookup with no output schema, the description covers what goes in (four query shapes), what comes out (syntax, options, subcommands, candidate lists), prerequisites (no session), and the main failure mode (a name may not exist on the user's target, with the check to confirm).

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 coverage is 100% and the parameter description already covers name-or-words, so the baseline is 3. The description adds genuine meaning the schema lacks: how to combine a name with a target qualifier, and that an RTOS name alone yields its commands and setup.

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: 'Look something up in the TRACE32 manuals installed here.' It also enumerates what a lookup returns (syntax, options, subcommands, candidate matches), which separates it cleanly from execution-oriented siblings such as command, evaluate, and script.

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 concrete invocation patterns — exact command name (Break.Set, Data.Long), keyword search (flash programming), target-qualified names (SYStem.MemAccess cortexm), and RTOS-only names (freertos) — plus 'Needs no session,' which tells the agent it can call this before/without session_open. It stops short of naming an explicit alternative or exclusion, so not a full 5.

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