Packages whose own publisher has withdrawn them and which are still being installed heavily, with the download figure and the publisher’s notice. Requires a key; see https://sighttrue.com/pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the need for an API key and mentions the output includes download figures and the publisher's notice, which adds some context. However, with no annotations, it does not state whether the operation is read-only, how results are ordered, what 'heavily installed' means, or any rate limits or error 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?
The description is compact: two sentences conveying the core purpose and the key requirement. It is front-loaded with the main concept, though a verb would make the first sentence more actionable; still, it wastes no words.
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 query tool with one optional parameter, the description gives enough to understand the basic output (download figure and publisher's notice) and the auth prerequisite. However, it omits explanation of the 'limit' parameter, the threshold for 'heavily installed,' and result ordering, leaving notable gaps.
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 includes an optional 'limit' parameter with no schema description, and the tool description does not mention or explain it. Since schema_description_coverage is 0%, the description provides no semantic support for the one parameter, leaving the agent to guess at its meaning and typical values.
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 identifies the subject matter—packages withdrawn by their publisher but still heavily installed—and implies a query operation, but it lacks an explicit verb like 'list' or 'get.' The unique scope distinguishes it from sibling tools, but the missing action makes it less direct than ideal.
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?
No explicit guidance is given for when to use this tool versus alternatives such as 'model_withdrawn' or 'check_package.' The context signals imply it is for a specific kind of package audit, but there is no direct comparison or prerequisite statement beyond the key requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct query type: package status, stack review, provider incidents, model pricing, watchlist changes, etc. Even similar-sounding tools like check_package and check_stack are clearly differentiated by granularity (single package vs. whole manifest). The descriptions further remove ambiguity.
All names use lowercase snake_case, but the pattern is mixed: some are imperative verb_noun (check_package, find_model, watch_add) while many are noun phrases (advisory_severity, provider_incidents, runtime_deadlines). This is readable but not a consistent verb_noun style, so there is noticeable inconsistency.
At 31 tools, the count exceeds the 'too many' threshold (25+). While the domain is broad, the agent must navigate a large surface with many similarly scoped utilities, making selection harder. A more consolidated set (e.g., grouping related readings) would improve appropriateness.
The tool surface covers a wide range of supply-chain intelligence: package advisories, provider status, model pricing, runtime EOL, and watchlist changes. The only notable gap is lifecycle management for the private watchlist (e.g., no watch_remove or watch_list), but the overall coverage is strong.