Skip to main content
Glama
Sign In
maximilianfeix

hexvero

by maximilianfeix
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Check release policy

hexvero_check
Read-onlyIdempotent

Applies a release policy to two Electron builds or audits one target against security rules, returning pass, fail, or incomplete status with paged findings.

Instructions

Apply a release policy (inline JSON or file) to two builds, as hexvero check; omit targetB to audit targetA alone against the Electron security rules, as hexvero audit (policy optional). Status pass, fail or incomplete, findings paged by offset. Reads a baseline, never writes one.

Input Schema

NameRequiredDescriptionDefault
limitNoFindings (default 100)
formatNoDefault json; markdown for two builds only
offsetNoFirst finding (default 0)
policyNoPolicy JSON object
targetAYesTarget id returned by hexvero_open
targetBNoTarget id returned by hexvero_open
unknownNoAudit only: how undecidable rules count (default: policy, else fail)
policyPathNoOr: absolute path of a policy file
baselinePathNoAbsolute path of a baseline file

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.12.0
    • changedInput schema / properties / format / description
      Previous value: -"Default json"New value: +"Default json; markdown for two builds only"
    • addedInput schema / properties / unknown
      Added value: +{
+  "description": "Audit only: how undecidable rules count (default: policy, else fail)",
+  "enum": [
+    "fail",
+    "warn",
+    "allow"
+  ],
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "targetA",
-  "targetB"
-]New value: +[
+  "targetA"
+]
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/no-destructive, but the description adds useful non-obvious behavior: status is pass/fail/incomplete, findings are paged by offset, and it 'reads a baseline, never writes one.' It does not clarify how the baseline is produced or whether a missing baseline file is an error, which keeps it short of a 5.

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-loaded with the primary action and mode distinction, with no filler sentences. It is dense—one long sentence carrying two modes plus status/paging facts—which slightly hurts scannability but every clause carries information.

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

Completeness4/5

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

For a 9-parameter, nested-object tool with no output schema, it covers mode selection, output status values, and pagination, which is most of what an agent needs. Remaining gaps (baseline file preconditions, policy vs policyPath resolution, format restriction rationale) are modest but real.

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 earns extra credit by explaining the mode-switching role of targetB and the audit-only nature of single-target checks, which the schema text alone does not frame as a distinct mode. It still does not clarify policy vs policyPath precedence when both are supplied.

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 ('apply a release policy ... to two builds') and explicitly names the two operating modes, including the CLI equivalents (`hexvero check` vs `hexvero audit`). This clearly distinguishes it from siblings like hexvero_compare or hexvero_analyze, which have no policy application concept.

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 conditional: omit targetB to audit a single target against Electron security rules, with policy optional in that mode. This is a concrete when-to-use rule that directly maps to the optional targetB parameter, leaving little 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

Other Tools