Global Executables

Resolve installation for one executable

resolve_installation

Read-onlyIdempotent

Resolve the install and invocation argv for one indexed command provider using a command name and target environment, returning required context instead of guessing.

Instructions

Resolve advisory install and invocation argv for one indexed command provider.

    Use this after lookup for one known target; use resolve_installations for several commands,
    and do not use it for name availability—use check_executable. environment maps its package
    manager to a provider ecosystem before preferences.package narrows candidates; omitted target
    facts are returned in required_context rather than guessed. The tool never executes argv or
    probes package availability; status and verification distinguish ready, ambiguous,
    unsupported, unverified, missing-index, and incomplete-context outcomes.

Input Schema

Name	Required	Description
`name`	Yes	Exact, case-sensitive executable command name, not a package name or filesystem path; must be 1-255 characters without path separators or control characters.
`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 / name / description

Added value: +"Exact, case-sensitive executable command name, not a package name or filesystem path; must be 1-255 characters without path separators or control characters."

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 declare readOnly/idempotent/non-destructive/closed-world, and the description adds substantial context beyond them: it never executes argv or probes package availability, and it enumerates outcome states (ready, ambiguous, unsupported, unverified, missing-index, incomplete-context) plus the fact that omitted target facts surface in required_context rather than being guessed.

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?

Core purpose is front-loaded, then routing, then behavioral guarantees. Dense but every sentence carries information; slightly run-on with the nested clause about required_context, keeping it out of the top band.

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?

With an output schema present, return-value detail is unnecessary, and annotations cover the safety profile. The description fills the remaining gaps: execution guarantees, failure-state vocabulary, and parameter interaction, leaving nothing an agent needs missing.

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; the description nonetheless clarifies interaction semantics the schema does not: 'environment maps its package manager to a provider ecosystem before preferences.package narrows candidates.' That sequencing between environment and preferences adds real meaning.

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+resource+scope: 'Resolve advisory install and invocation argv for one indexed command provider.' This clearly delineates it from resolve_installations (several) and check_executable (availability), so an agent can distinguish it from siblings 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?

Explicit routing: 'Use this after lookup for one known target; use resolve_installations for several commands, and do not use it for name availability—use check_executable.' Names both alternatives and the conditions that select them.

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

Deploy Server