dart_language_ref

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

No annotations are provided, so the description must carry the behavioral disclosure burden. The description reveals the tool is a read/reference tool covering records, patterns, sealed classes 'and more', which signals it's non-destructive. However, it doesn't clarify what 'and more' includes, whether output is structured or freeform, or how the response is formatted.

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 a single sentence that instantly conveys the tool's purpose and scope. It is front-loaded with the core purpose and then provides concrete examples of covered features. There is minimal waste, though it could potentially mention the response format.

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 simple read-only reference tool with one well-documented parameter, the description is reasonably complete. It names the covers topics and clarifies it provides syntax, examples, and tips. However, it doesn't enumerate the full feature list ('and more' is vague), and there's no indication of how to handle unknown features or what the lookup behavior is for unsupported inputs.

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 single 'feature' parameter has a clear description listing example values. The description reinforces the parameter by naming the same features (records, patterns, sealed classes), which is consistent with the schema. Baseline 3 is appropriate since the schema already handles parameter documentation adequately, though the description adds some reinforcement.

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 the tool provides Dart language feature reference with syntax, examples, and tips, and names specific features (records, patterns, sealed classes). This clearly distinguishes it from siblings like flutter_docs and dart_docs by focusing specifically on language features. However, it doesn't explicitly call out that it covers only language constructs as opposed to broader Dart/Flutter APIs.

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 usage is for looking up Dart language feature details (syntax, examples, tips). It lists covered features which gives some context, but it doesn't state when NOT to use it vs siblings like dart_docs (which could cover language features too) or flutter_docs. No explicit exclusions or alternatives are mentioned.

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