Skip to main content
Glama
Sign In
SkillTotal

SkillTotal

by pezhik
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Compare two versions of a component

diff_components
Read-only

Compare two component versions to see what changed and whether a new release is riskier than the vetted version, with verdict, risk-score and finding deltas.

Instructions

Compare two versions of a component and report what changed. Use for upgrade reviews (is the new version riskier than the one already vetted?). Both sides accept the same sources as scan_component. The default summary gives each side's verdict, the verdict change, the risk-score delta, new and removed risk findings (in scan_component's why shape) and capability changes; detail="full" returns the complete diff with every new/resolved/changed finding. Decide on the verdict (level, headline, has_malicious_indicators), not on the number of findings: a finding whose threat_class is "capability" is something the component can do (run commands, read files, reach the network) and adds no risk; malicious_indicator and risky_construct findings are what the verdict and score rest on. Not checked: the code of the component's dependencies, known vulnerabilities (CVEs), and runtime behaviour.

Input Schema

NameRequiredDescriptionDefault
newYesNew side. What to scan: an absolute path to a local folder, file or archive, a git URL (a subfolder as https://github.com/<owner>/<repo>/tree/<ref>/<path>), npm:<name>[@version], pypi:<name>[==version], or an editor extension as vscode:<publisher>.<name>[@version] (Visual Studio Marketplace) or openvsx:<namespace>.<name>[@version] (Open VSX).
oldYesOld side. What to scan: an absolute path to a local folder, file or archive, a git URL (a subfolder as https://github.com/<owner>/<repo>/tree/<ref>/<path>), npm:<name>[@version], pypi:<name>[==version], or an editor extension as vscode:<publisher>.<name>[@version] (Visual Studio Marketplace) or openvsx:<namespace>.<name>[@version] (Open VSX).
detailNosummary (default): the verdict, why (findings with up to 3 locations each), capabilities, counts, what to check by hand and what was not checked. full: the complete SkillTotal report JSON (every finding, all evidence, traits, needs_review).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.90.0
    • changedInput schema / properties / new / description
      Previous value: -"New side. What to scan: an absolute path to a local folder, file or archive, a git URL (a subfolder as https://github.com/<owner>/<repo>/tree/<ref>/<path>), npm:<name>[@version], or pypi:<name>[==version]."New value: +"New side. What to scan: an absolute path to a local folder, file or archive, a git URL (a subfolder as https://github.com/<owner>/<repo>/tree/<ref>/<path>), npm:<name>[@version], pypi:<name>[==version], or an editor extension as vscode:<publisher>.<name>[@version] (Visual Studio Marketplace) or openvsx:<namespace>.<name>[@version] (Open VSX)."
    • changedInput schema / properties / old / description
      Previous value: -"Old side. What to scan: an absolute path to a local folder, file or archive, a git URL (a subfolder as https://github.com/<owner>/<repo>/tree/<ref>/<path>), npm:<name>[@version], or pypi:<name>[==version]."New value: +"Old side. What to scan: an absolute path to a local folder, file or archive, a git URL (a subfolder as https://github.com/<owner>/<repo>/tree/<ref>/<path>), npm:<name>[@version], pypi:<name>[==version], or an editor extension as vscode:<publisher>.<name>[@version] (Visual Studio Marketplace) or openvsx:<namespace>.<name>[@version] (Open VSX)."
  2. Changed7 schema fields changedv0.75.0
    • addedInput schema / properties / detail
      Added value: +{
+  "description": "summary (default): the verdict, why (findings with up to 3 locations each), capabilities, counts, what to check by hand and what was not checked. full: the complete SkillTotal report JSON (every finding, all evidence, traits, needs_review).",
+  "enum": [
+    "summary",
+    "full"
+  ],
+  "examples": [
+    "summary"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / new / description
      Previous value: -"New side. What to scan: a local directory/file/archive path, a git URL, npm:<name>[@version], or pypi:<name>[==version]."New value: +"New side. What to scan: an absolute path to a local folder, file or archive, a git URL (a subfolder as https://github.com/<owner>/<repo>/tree/<ref>/<path>), npm:<name>[@version], or pypi:<name>[==version]."
    • addedInput schema / properties / new / examples
      Added value: +[
+  "npm:mcp-remote@0.1.1"
+]
    • addedInput schema / properties / new / minLength
      Added value: +1
    • changedInput schema / properties / old / description
      Previous value: -"Old side. What to scan: a local directory/file/archive path, a git URL, npm:<name>[@version], or pypi:<name>[==version]."New value: +"Old side. What to scan: an absolute path to a local folder, file or archive, a git URL (a subfolder as https://github.com/<owner>/<repo>/tree/<ref>/<path>), npm:<name>[@version], or pypi:<name>[==version]."
    • addedInput schema / properties / old / examples
      Added value: +[
+  "npm:mcp-remote@0.1.0"
+]
    • addedInput schema / properties / old / minLength
      Added value: +1
  3. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations declare readOnly/openWorld/non-destructive, and the description goes well beyond them: it specifies the default summary payload, what detail="full" returns, and cautions that dependency code, CVEs, and runtime behaviour are excluded. It also explains an interpretation rule (capability threat_class findings add no risk; the verdict rests on malicious_indicator and risky_construct) that an agent could not infer from any structured field.

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 purpose, then sources, then return shape, then interpretation guidance — a sensible order. It is dense but long, and the detail= explanation partially duplicates the schema's enum description; the verdict-semantics sentence earns its length by preventing a common misreading.

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?

There is no output schema, and the description compensates by describing both return modes and their contents, plus the systematic exclusions. For a three-parameter comparison tool backed by rich annotations, nothing an agent needs to call or interpret it correctly is missing.

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 coverage is 100%, and the schema already enumerates every accepted source format for old and new and fully describes the detail enum, so the description adds little. Its only semantic contribution is restating that both sides take the same sources as scan_component and that detail="full" yields every new/resolved/changed finding, which the schema largely covers. Baseline 3 applies.

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 ('Compare two versions of a component and report what changed'), which cleanly distinguishes it from the sibling scan_component, which inspects a single version. The title and description agree, and the frame 'is the new version riskier than the one already vetted?' pins the intent.

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

Usage Guidelines4/5

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

Gives an explicit use case (upgrade reviews) and an explicit scope boundary ('Not checked: dependencies, CVEs, runtime behaviour'). It names scan_component as the reference for accepted sources, which implicitly routes single-version scanning there, but never states plainly 'for a single component use scan_component'.

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