Single tool 'install_package' has a clear, action-oriented name and a well-written description (158 chars) that explains WHAT it does, WHEN to use it, and what the output means. Input schema is present with two parameters, both typed as strings with descriptions. However, the schema lacks critical constraints: no enum for the 'level' field in the verdict output, no documented output schema structure, and no error handling guidance. The description mentions 'ok/warn/block' verdicts but these are not formalized as enums in the input or output. Parameter descriptions are adequate but could specify format expectations (e.g., semver for version). No pagination, no batch operations, and no recovery guidance for 'block' verdicts.

• Document the complete output schema with all fields, types, and examples. Include the structure of 'signals' (e.g., signal_type, severity, description, remediation).
• Formalize verdict levels as an enum in the output schema: 'ok' | 'warn' | 'block'. Update description to reference this enum.
• Add error handling guidance: 'If the package is not found, try searching with a partial name. If the registry is unreachable, retry after 30 seconds. If the version does not exist, call with version omitted to check the latest.'
• Clarify version parameter format: 'Accepts semver ranges (^1.0.0, ~2.1.x), pinned versions (1.2.3), or omit for latest. Scoped packages like @scope/name are supported.'
• Document signal types and severity levels in the description or as a separate discovery tool. E.g., 'Signals include: typosquat (high), unmaintained (medium), known_vulnerability (critical), etc.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry