Global Executables

Assess executable names in batch

assess_executables

Read-onlyIdempotent

Compare multiple command-name candidates at once for freshness, activity, popularity, and collision risk before choosing a CLI executable name.

Instructions

Assess freshness, activity, popularity, and collision risk for several command names.

    Use this to compare candidates; use assess_executable for one, and do not use it instead of
    check_executables. One scope filters every name before per-name signal aggregation; release
    age uses request time and results, including duplicates, preserve input order. The tool makes
    no live registry call; unknown or insufficient_evidence means missing snapshot evidence, not
    safety, so retain each result's existence and coverage context.

Input Schema

Name	Required	Description	Default
`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.
`scope`	No	Optional provider filters: source_type, package_system, distribution_family, distribution, distribution_release, language, registry, or ecosystem. All supplied key-value pairs must match; scoped negative results remain non-exhaustive.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.1.2Oct 20, 2026

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 / scope / description

Added value: +"Optional provider filters: source_type, package_system, distribution_family, distribution, distribution_release, language, registry, or ecosystem. All supplied key-value pairs must match; scoped negative results remain non-exhaustive."

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?

Goes well past the annotations (which only cover read-only/idempotent/openWorld): it discloses that no live registry call is made, that unknown/insufficient_evidence denotes missing snapshot evidence rather than safety, that a single scope filters all names before aggregation, and that duplicates/order are preserved. These are exactly the behavioral facts an agent needs to interpret results correctly.

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?

Purpose and routing are front-loaded in the first two sentences, and the remaining text is dense with non-redundant behavior. It is slightly run-on and mixes instruction with description ('so retain each result's existence and coverage context'), costing a point.

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 values need not be described, yet the description still explains how to interpret ambiguous result states and ordering. For a two-parameter batch read tool, nothing an agent needs to call or interpret it is 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 baseline is 3. The description adds genuine meaning beyond the schema for scope ('One scope filters every name before per-name signal aggregation') and for names (release age uses request time, results preserve input order, duplicates retained).

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 (assess) plus the exact signals computed (freshness, activity, popularity, collision risk) and the batch scope (several command names). This distinguishes it immediately from the singular sibling assess_executable and from the check_* family.

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?

Explicitly routes the agent: 'use assess_executable for one' and 'do not use it instead of check_executables'. That is a positive selection rule plus an exclusion, which is the strongest form of usage guidance.

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

Deploy Server