Single tool with critical definition gaps. Tool name is acceptable but descriptions lack depth and crucial parameter documentation is absent. Input schema is present but minimal. No output schema documentation. Error handling is present but non-actionable. This server falls well below baseline standards for production use.
Retrieve package information from PyPI
Parameter 'name' lacks description. The schema shows type 'string' but provides no guidance on format, constraints (e.g., 'must match PyPI package name exactly'), or what happens on invalid input (typos, non-existent packages).
No output schema documented. The tool returns a dict with keys 'latest_version', 'name', 'requirements', 'license', 'summary', but the LLM has no structured definition of these fields, types (string, array, null), whether fields are always present, or how to handle missing license/requirements. This forces the LLM to infer and risks parsing errors.
Tool description (58 chars) is below the baseline (p10=34, p90=392) and lacks actionable context. It does not explain: WHEN to use this tool (vs. other package lookup sources), WHAT the agent should do if the package is not found, or that this tool returns None on failure. The description should guide the LLM toward correct tool selection and error recovery.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 26 | - | v1 |
Error handling returns None (Python) or falsy values on failure, but the response is printed to stderr and not returned to the LLM. The LLM sees None but receives no actionable error message like 'Package not found, try a different name' or 'PyPI API timeout, retry in 30 seconds'. Per pattern:recovery-guide, errors must guide next steps.
No error classification. The tool treats HTTP 404 (package not found), network timeouts, and malformed API responses identically (return None). LLM cannot distinguish 'user should try a different name' (user-fixable) from 'API is down, retry later' (retryable) from 'invalid input format' (agent-fixable).
Parameter accepts any string without validation. No constraint on package name format, length, or allowed characters. PyPI has naming rules (lowercase, hyphens/underscores, no spaces), but the tool does not document or enforce them. Invalid input returns None without clarity on why.
Tool response may include None values (e.g., if 'requires_dist' or 'license' is null in the API response). No documentation of which fields are optional vs. required, or how the LLM should handle nulls. This causes downstream reasoning errors.