get_package_prompt

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

The description adds numerous behavioral details beyond the annotations: it outputs plain text (~300 tokens), is 75% cheaper than JSON, includes a verdict and specific fields, and is tailored for LLM reasoning. This fully discloses what the agent can expect without contradicting the read-only and idempotent hints.

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 extremely concise, using only three sentences to convey purpose, usage guidance, and return type. It front-loads the key benefit (LLM-optimised, cheaper, verdict) and avoids any redundant or filler sentences. Every phrase adds value.

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?

The description adequately covers output and usage for a tool with two simple parameters, but it lacks any parameter documentation. Given the high number of siblings and the tool's specific niche, the missing input guidance leaves a gap that could cause misuse. An output schema is absent, but the description describes return fields sufficiently.

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 input schema has 0% description coverage and the description provides no guidance on the parameters ('ecosystem' and 'package'). Despite two required parameters with an enum, the description focuses solely on output, leaving the agent to infer parameter meaning from the schema alone.

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 it produces an 'LLM-optimised package brief' with specific verdict types (SAFE/AVOID/URGENT/MALICIOUS) plus health, vulnerabilities, alternatives, and alerts. It distinguishes itself from the sibling 'check_package' by noting it is text-based and cheaper, making its unique purpose unmistakable.

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?

Explicit instructions: 'USE WHEN: you want to reason over a package and drop the output directly in context; 'is X safe'. PREFER THIS over check_package in 95% of LLM cases.' This clearly defines when to use this tool versus the sibling, leaving no ambiguity.

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