Global Executables

Resolve installations in batch

resolve_installations

Read-onlyIdempotent

Resolve advisory install and invocation argv for several commands sharing one target environment, preserving input order and returning per-result status without executing them.

Instructions

Resolve advisory install and invocation argv for several commands on one target.

    Use this when all commands share an environment and preferences; use resolve_installation
    for one, and do not use it for availability—use check_executables. The shared environment
    selects an ecosystem before preferences.package narrows each command independently; results,
    including duplicates, preserve input order. The tool never executes argv or probes package
    availability, and each result reports its own status, required_context, and verification.

Input Schema

Name	Required	Description
`names`	Yes	Executable command names to process in one request. Each value follows the same exact, case-sensitive rules as name, and results preserve input order.
`environment`	Yes	Target installation context. Set package_manager to apt, brew, npm, or pip. Depending on the manager, also provide os, distribution, distribution_release, architecture, runtime_version, install_scope (user or project), virtualenv_bin, and has_admin as requested by the result.
`preferences`	No	Optional provider-selection preferences. Use package to select an exact package when more than one indexed provider exposes the command.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.1.2Oct 20, 2026

addedInput schema / properties / environment / description

Added value: +"Target installation context. Set package_manager to apt, brew, npm, or pip. Depending on the manager, also provide os, distribution, distribution_release, architecture, runtime_version, install_scope (user or project), virtualenv_bin, and has_admin as requested by the result."

addedInput schema / properties / names / description

Added value: +"Executable command names to process in one request. Each value follows the same exact, case-sensitive rules as name, and results preserve input order."

addedInput schema / properties / preferences / description

Added value: +"Optional provider-selection preferences. Use package to select an exact package when more than one indexed provider exposes the command."

First observedv0.1.0Oct 20, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds substantive behavior: it never executes argv or probes package availability, duplicates are preserved, and input order is retained. Each result carries its own status, required_context, and verification—context the annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose before routing guidance, and every sentence carries information (scope, alternatives, resolution order, no-execution guarantee). Slightly dense, but no filler sentences to cut.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a batch tool with an output schema present, the description covers what an agent needs: scope, sibling routing, resolution mechanics, order guarantees, and the non-execution contract. Return-value detail is correctly delegated to the output schema, and the mention of per-result fields is a bonus.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: the shared environment selects the ecosystem first, then preferences.package narrows each command independently, and names/environment are explicitly tied to per-command resolution. This relationship is not spelled out in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('resolve advisory install and invocation argv for several commands on one target') and immediately distinguishes itself from siblings resolve_installation (single) and check_executables (availability). An agent can select this without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit positive condition ('when all commands share an environment and preferences'), names the single-item alternative (resolve_installation), and an explicit negative exclusion ('do not use it for availability—use check_executables'). Nothing is left to inference.

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

Deploy Server