Skip to main content
Glama
malamutemayhem

UnClick MCP Server

by malamutemayhem
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

xpass_aggregated_verdict

Aggregates XPass receipts into a single verdict for a target PR or change at a specific commit SHA; stale, unscoped, missing, or blocker receipts cannot produce a green result.

Instructions

Return one XPass conductor verdict for a target PR/change at a specific commit SHA. Selected PASS receipts must name the same head SHA; stale, unscoped, missing, or blocker receipts cannot produce a green verdict.

Input Schema

NameRequiredDescriptionDefault
nowNoAlias for generated_at.
bodyNoOptional body text used for check selection.
tagsNoOptional tags used for check selection.
filesNoAlias for changed_files.
titleNoOptional PR/change title used for check selection.
targetYesTarget change to inspect. target.sha or target.head_sha is required for anti-stale proof binding.
contextNoOptional extra context used for check selection.
resultsNoMap form of pass_results keyed by check name.
summaryNoOptional summary text used for check selection.
ownedFilesNoAlias for owned_files.
descriptionNoOptional PR/change description used for check selection.
owned_filesNoOwned file paths for check selection.
changedFilesNoAlias for changed_files.
generated_atNoOptional deterministic timestamp for tests or replay.
pass_resultsNoUnderlying Pass receipts or summarized results. Green results must include target_sha/head_sha matching target.sha.
changed_filesNoChanged file paths for check selection.
force_councilNoAlias for require_council.
enabled_checksNoOptional suite restriction. When supplied, XPass only gates the selected checks that are enabled here.
require_councilNoForce the Crews Council recommendation on this XPass receipt.
selected_checksNoOptional explicit XPass product checks to require for this verdict.
available_checksNoOptional worker availability list. Selected checks outside this list are NOT RUN and cannot make the verdict green.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.11

TDQS

B3.4/5.0
Behavior3/5

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

No annotations, so description carries full burden. It discloses key validation logic ('stale, unscoped, missing, or blocker receipts cannot produce a green verdict') and proof binding to head SHA, but omits auth needs, side effects, rate limits, and what a non-green verdict looks like.

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?

Two sentences, front-loaded with the core purpose, followed by a constraint. No wasted words, though slightly dense with jargon.

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

Completeness3/5

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

Given 21 parameters, nested objects, and no output schema, the description should ideally describe the return value and more of the parameter interactions. It covers the anti-stale requirement but leaves output format and most parameter semantics to the schema.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 21 parameters. The description adds minimal parameter meaning beyond what is in the schema, only hinting at target SHA and receipt head SHA matching.

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

Purpose4/5

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

States a specific verb ('Return') and resource ('one XPass conductor verdict') with scope ('for a target PR/change at a specific commit SHA'). It distinguishes from individual pass tools by implying aggregation, but does not name a specific sibling tool for contrast.

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

Usage Guidelines3/5

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

Implies usage when an aggregated conductor verdict is needed from PASS receipts, but does not state when to use it versus calling individual pass tools or list/get run tools. No explicit when-not or alternatives provided.

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

Deploy Server

Other Tools