sqo_sdk_radar

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

No annotations are supplied, so the description must carry the behavioral burden. 'Reads installed package versions' implies a read-only scan and it discloses the manifest files it inspects, but it does not state whether anything is written, whether network/registry access is needed, or what the scan scope is; the 'v10.0' tag is noise, not behavior.

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?

It is one front-loaded sentence that states detection and remediation outcomes efficiently. The 'Context7-Class ... (v10.0)' branding and 'Idioms' phrasing are low-value filler that could be removed without losing meaning.

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 one-parameter tool with no output schema, the description covers the inputs read and the class of findings, but it does not describe the shape of returned results (e.g., per-package findings, severity, or suggested version pins) beyond the phrase 'with modern fixes'. That leaves a real gap an agent must discover at call time.

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 is a single parameter (workspace) with 100% schema description coverage ('Workspace root directory'), so the schema already documents it fully. The description hints that manifests are resolved relative to the workspace but adds no further semantics such as monorepo or multi-manifest handling, leaving the baseline 3 appropriate.

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 names a concrete verb ('reads installed package versions') and resource ('package.json, pubspec.yaml, pyproject.toml') and states the outcome ('detects deprecated 2023/2024 API hallucinations with modern fixes'). It is distinguishable from generic siblings like sqo_dead_code or sqo_api_contracts, though the leading marketing phrase 'Context7-Class Live Version-Pinned SDK Idioms' adds noise rather than precision.

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?

Usage is implied by the described scenario (checking for deprecated/hallucinated SDK APIs), but there is no explicit when-to-use versus when-not, and no named sibling alternative such as sqo_api_contracts or sqo_dead_code. An agent can infer the context but must guess where this tool fits in the broader catalog.

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